1. 27 Jun, 2016 1 commit
  2. 27 Jan, 2016 2 commits
  3. 25 Jan, 2016 2 commits
    • Richard Guy Briggs's avatar
      audit: log failed attempts to change audit_pid configuration · 935c9e7f
      Richard Guy Briggs authored
      Failed attempts to change the audit_pid configuration are not presently
      logged.  One case is an attempt to starve an old auditd by starting up
      a new auditd when the old one is still alive and active.  The other
      case is an attempt to orphan a new auditd when an old auditd shuts
      Log both as AUDIT_CONFIG_CHANGE messages with failure result.
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
    • Richard Guy Briggs's avatar
      audit: stop an old auditd being starved out by a new auditd · 133e1e5a
      Richard Guy Briggs authored
      Nothing prevents a new auditd starting up and replacing a valid
      audit_pid when an old auditd is still running, effectively starving out
      the old auditd since audit_pid no longer points to the old valid
      If no message to auditd has been attempted since auditd died
      unnaturally or got killed, audit_pid will still indicate it is alive.
      There isn't an easy way to detect if an old auditd is still running on
      the existing audit_pid other than attempting to send a message to see
      if it fails.  An -ECONNREFUSED almost certainly means it disappeared
      and can be replaced.  Other errors are not so straightforward and may
      indicate transient problems that will resolve themselves and the old
      auditd will recover.  Yet others will likely need manual intervention
      for which a new auditd will not solve the problem.
      Send a new message type (AUDIT_REPLACE) to the old auditd containing a
      u32 with the PID of the new auditd.  If the audit replace message
      succeeds (or doesn't fail with certainty), fail to register the new
      auditd and return an error (-EEXIST).
      This is expected to make the patch preventing an old auditd orphaning a
      new auditd redundant.
      V3: Switch audit message type from 1000 to 1300 block.
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
  4. 13 Jan, 2016 5 commits
  5. 24 Dec, 2015 1 commit
  6. 06 Nov, 2015 1 commit
    • Mel Gorman's avatar
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman authored
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      This patch then converts a number of sites
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 04 Nov, 2015 4 commits
    • Paul Moore's avatar
      audit: make audit_log_common_recv_msg() a void function · 233a6866
      Paul Moore authored
      It always returns zero and no one is checking the return value.
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
    • Saurabh Sengar's avatar
      audit: removing unused variable · c5ea6efd
      Saurabh Sengar authored
      Variable rc in not required as it is just used for unchanged for return,
      and return is always 0 in the function.
      Signed-off-by: default avatarSaurabh Sengar <saurabh.truth@gmail.com>
      [PM: fixed spelling errors in description]
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
    • Yaowei Bai's avatar
      audit: audit_string_contains_control can be boolean · 9fcf836b
      Yaowei Bai authored
      This patch makes audit_string_contains_control return bool to improve
      readability due to this particular function only using either one or
      zero as its return value.
      Signed-off-by: default avatarYaowei Bai <bywxiaobai@163.com>
      [PM: tweaked subject line]
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
    • Richard Guy Briggs's avatar
      audit: try harder to send to auditd upon netlink failure · 32a1dbae
      Richard Guy Briggs authored
      There are several reports of the kernel losing contact with auditd when
      it is, in fact, still running.  When this happens, kernel syslogs show:
      	"audit: *NO* daemon at audit_pid=<pid>"
      although auditd is still running, and is apparently happy, listening on
      the netlink socket. The pid in the "*NO* daemon" message matches the pid
      of the running auditd process.  Restarting auditd solves this.
      The problem appears to happen randomly, and doesn't seem to be strongly
      correlated to the rate of audit events being logged.  The problem
      happens fairly regularly (every few days), but not yet reproduced to
      On production kernels, BUG_ON() is a no-op, so any error will trigger
      Commit 34eab0a7 ("audit: prevent an older auditd shutdown from
      orphaning a newer auditd startup") eliminates one possible cause.  This
      isn't the case here, since the PID in the error message and the PID of
      the running auditd match.
      The primary expected cause of error here is -ECONNREFUSED when the audit
      daemon goes away, when netlink_getsockbyportid() can't find the auditd
      portid entry in the netlink audit table (or there is no receive
      function).  If -EPERM is returned, that situation isn't likely to be
      resolved in a timely fashion without administrator intervention.  In
      both cases, reset the audit_pid.  This does not rule out a race
      condition.  SELinux is expected to return zero since this isn't an INET
      or INET6 socket.  Other LSMs may have other return codes.  Log the error
      code for better diagnosis in the future.
      In the case of -ENOMEM, the situation could be temporary, based on local
      or general availability of buffers.  -EAGAIN should never happen since
      the netlink audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT.
      -ERESTARTSYS and -EINTR are not expected since this kernel thread is not
      expected to receive signals.  In these cases (or any other unexpected
      ones for now), report the error and re-schedule the thread, retrying up
      to 5 times.
      	Removed BUG_ON().
      	Moved comma in pr_*() statements.
      	Removed audit_strerror() text.
      Reported-by: default avatarVipin Rathor <v.rathor@gmail.com>
      Reported-by: <ctcard@hotmail.com>
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      [PM: applied rgb's fixup patch to correct audit_log_lost() format issues]
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
  8. 06 Aug, 2015 1 commit
  9. 29 May, 2015 1 commit
  10. 15 Apr, 2015 1 commit
  11. 13 Mar, 2015 1 commit
    • Pranith Kumar's avatar
      audit: Remove condition which always evaluates to false · 724e7bfc
      Pranith Kumar authored
      After commit 3e1d0bb6 ("audit: Convert int limit
      uses to u32"), by converting an int to u32, few conditions will always evaluate
      to false.
      These warnings were emitted during compilation:
      kernel/audit.c: In function ‘audit_set_enabled’:
      kernel/audit.c:347:2: warning: comparison of unsigned expression < 0 is always
      false [-Wtype-limits]
        if (state < AUDIT_OFF || state > AUDIT_LOCKED)
      	  kernel/audit.c: In function ‘audit_receive_msg’:
      	  kernel/audit.c:880:9: warning: comparison of unsigned expression < 0 is
      	  always false [-Wtype-limits]
      	      if (s.backlog_wait_time < 0 ||
      The following patch removes those unnecessary conditions.
      Signed-off-by: default avatarPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
  12. 23 Feb, 2015 5 commits
  13. 27 Dec, 2014 1 commit
    • Johannes Berg's avatar
      netlink/genetlink: pass network namespace to bind/unbind · 023e2cfa
      Johannes Berg authored
      Netlink families can exist in multiple namespaces, and for the most
      part multicast subscriptions are per network namespace. Thus it only
      makes sense to have bind/unbind notifications per network namespace.
      To achieve this, pass the network namespace of a given client socket
      to the bind/unbind functions.
      Also do this in generic netlink, and there also make sure that any
      bind for multicast groups that only exist in init_net is rejected.
      This isn't really a problem if it is accepted since a client in a
      different namespace will never receive any notifications from such
      a group, but it can confuse the family if not rejected (it's also
      possible to silently (without telling the family) accept it, but it
      would also have to be ignored on unbind so families that take any
      kind of action on bind/unbind won't do unnecessary work for invalid
      clients like that.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  14. 19 Dec, 2014 1 commit
    • Richard Guy Briggs's avatar
      audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb · 54dc77d9
      Richard Guy Briggs authored
      Eric Paris explains: Since kauditd_send_multicast_skb() gets called in
      audit_log_end(), which can come from any context (aka even a sleeping context)
      GFP_KERNEL can't be used.  Since the audit_buffer knows what context it should
      use, pass that down and use that.
      See: https://lkml.org/lkml/2014/12/16/542
      BUG: sleeping function called from invalid context at mm/slab.c:2849
      in_atomic(): 1, irqs_disabled(): 0, pid: 885, name: sulogin
      2 locks held by sulogin/885:
        #0:  (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff91152e30>] prepare_bprm_creds+0x28/0x8b
        #1:  (tty_files_lock){+.+.+.}, at: [<ffffffff9123e787>] selinux_bprm_committing_creds+0x55/0x22b
      CPU: 1 PID: 885 Comm: sulogin Not tainted 3.18.0-next-20141216 #30
      Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
        ffff880223744f10 ffff88022410f9b8 ffffffff916ba529 0000000000000375
        ffff880223744f10 ffff88022410f9e8 ffffffff91063185 0000000000000006
        0000000000000000 0000000000000000 0000000000000000 ffff88022410fa38
      Call Trace:
        [<ffffffff916ba529>] dump_stack+0x50/0xa8
        [<ffffffff91063185>] ___might_sleep+0x1b6/0x1be
        [<ffffffff910632a6>] __might_sleep+0x119/0x128
        [<ffffffff91140720>] cache_alloc_debugcheck_before.isra.45+0x1d/0x1f
        [<ffffffff91141d81>] kmem_cache_alloc+0x43/0x1c9
        [<ffffffff914e148d>] __alloc_skb+0x42/0x1a3
        [<ffffffff914e2b62>] skb_copy+0x3e/0xa3
        [<ffffffff910c263e>] audit_log_end+0x83/0x100
        [<ffffffff9123b8d3>] ? avc_audit_pre_callback+0x103/0x103
        [<ffffffff91252a73>] common_lsm_audit+0x441/0x450
        [<ffffffff9123c163>] slow_avc_audit+0x63/0x67
        [<ffffffff9123c42c>] avc_has_perm+0xca/0xe3
        [<ffffffff9123dc2d>] inode_has_perm+0x5a/0x65
        [<ffffffff9123e7ca>] selinux_bprm_committing_creds+0x98/0x22b
        [<ffffffff91239e64>] security_bprm_committing_creds+0xe/0x10
        [<ffffffff911515e6>] install_exec_creds+0xe/0x79
        [<ffffffff911974cf>] load_elf_binary+0xe36/0x10d7
        [<ffffffff9115198e>] search_binary_handler+0x81/0x18c
        [<ffffffff91153376>] do_execveat_common.isra.31+0x4e3/0x7b7
        [<ffffffff91153669>] do_execve+0x1f/0x21
        [<ffffffff91153967>] SyS_execve+0x25/0x29
        [<ffffffff916c61a9>] stub_execve+0x69/0xa0
      Cc: stable@vger.kernel.org #v3.16-rc1
      Reported-by: default avatarValdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Tested-by: default avatarValdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
  15. 17 Nov, 2014 1 commit
    • Richard Guy Briggs's avatar
      audit: convert status version to a feature bitmap · 0288d718
      Richard Guy Briggs authored
      The version field defined in the audit status structure was found to have
      limitations in terms of its expressibility of features supported.  This is
      distict from the get/set features call to be able to command those features
      that are present.
      Converting this field from a version number to a feature bitmap will allow
      distributions to selectively backport and support certain features and will
      allow upstream to be able to deprecate features in the future.  It will allow
      userspace clients to first query the kernel for which features are actually
      present and supported.  Currently, EINVAL is returned rather than EOPNOTSUP,
      which isn't helpful in determining if there was an error in the command, or if
      it simply isn't supported yet.  Past features are not represented by this
      bitmap, but their use may be converted to EOPNOTSUP if needed in the future.
      Since "version" is too generic to convert with a #define, use a union in the
      struct status, introducing the member "feature_bitmap" unionized with
      Convert existing AUDIT_VERSION_* macros over to AUDIT_FEATURE_BITMAP*
      counterparts, leaving the former for backwards compatibility.
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      [PM: minor whitespace tweaks]
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
  16. 03 Nov, 2014 1 commit
  17. 30 Oct, 2014 1 commit
  18. 23 Sep, 2014 7 commits
  19. 24 Jul, 2014 1 commit
    • Eric Paris's avatar
      CAPABILITIES: remove undefined caps from all processes · 7d8b6c63
      Eric Paris authored
      This is effectively a revert of 7b9a7ec5
      plus fixing it a different way...
      We found, when trying to run an application from an application which
      had dropped privs that the kernel does security checks on undefined
      capability bits.  This was ESPECIALLY difficult to debug as those
      undefined bits are hidden from /proc/$PID/status.
      Consider a root application which drops all capabilities from ALL 4
      capability sets.  We assume, since the application is going to set
      eff/perm/inh from an array that it will clear not only the defined caps
      less than CAP_LAST_CAP, but also the higher 28ish bits which are
      undefined future capabilities.
      The BSET gets cleared differently.  Instead it is cleared one bit at a
      time.  The problem here is that in security/commoncap.c::cap_task_prctl()
      we actually check the validity of a capability being read.  So any task
      which attempts to 'read all things set in bset' followed by 'unset all
      things set in bset' will not even attempt to unset the undefined bits
      higher than CAP_LAST_CAP.
      So the 'parent' will look something like:
      CapInh:	0000000000000000
      CapPrm:	0000000000000000
      CapEff:	0000000000000000
      CapBnd:	ffffffc000000000
      All of this 'should' be fine.  Given that these are undefined bits that
      aren't supposed to have anything to do with permissions.  But they do...
      So lets now consider a task which cleared the eff/perm/inh completely
      and cleared all of the valid caps in the bset (but not the invalid caps
      it couldn't read out of the kernel).  We know that this is exactly what
      the libcap-ng library does and what the go capabilities library does.
      They both leave you in that above situation if you try to clear all of
      you capapabilities from all 4 sets.  If that root task calls execve()
      the child task will pick up all caps not blocked by the bset.  The bset
      however does not block bits higher than CAP_LAST_CAP.  So now the child
      task has bits in eff which are not in the parent.  These are
      'meaningless' undefined bits, but still bits which the parent doesn't
      The problem is now in cred_cap_issubset() (or any operation which does a
      subset test) as the child, while a subset for valid cap bits, is not a
      subset for invalid cap bits!  So now we set durring commit creds that
      the child is not dumpable.  Given it is 'more priv' than its parent.  It
      also means the parent cannot ptrace the child and other stupidity.
      The solution here:
      1) stop hiding capability bits in status
      	This makes debugging easier!
      2) stop giving any task undefined capability bits.  it's simple, it you
      don't put those invalid bits in CAP_FULL_SET you won't get them in init
      and you won't get them in any other task either.
      	This fixes the cap_issubset() tests and resulting fallout (which
      	made the init task in a docker container untraceable among other
      3) mask out undefined bits when sys_capset() is called as it might use
      ~0, ~0 to denote 'all capabilities' for backward/forward compatibility.
      	This lets 'capsh --caps="all=eip" -- -c /bin/bash' run.
      4) mask out undefined bit when we read a file capability off of disk as
      again likely all bits are set in the xattr for forward/backward
      	This lets 'setcap all+pe /bin/bash; /bin/bash' run
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Steve Grubb <sgrubb@redhat.com>
      Cc: Dan Walsh <dwalsh@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
  20. 06 Jun, 2014 1 commit
  21. 24 Apr, 2014 1 commit