1. 28 3月, 2017 1 次提交
  2. 21 3月, 2017 1 次提交
    • P
      audit: fix auditd/kernel connection state tracking · 5b52330b
      Paul Moore 提交于
      What started as a rather straightforward race condition reported by
      Dmitry using the syzkaller fuzzer ended up revealing some major
      problems with how the audit subsystem managed its netlink sockets and
      its connection with the userspace audit daemon.  Fixing this properly
      had quite the cascading effect and what we are left with is this rather
      large and complicated patch.  My initial goal was to try and decompose
      this patch into multiple smaller patches, but the way these changes
      are intertwined makes it difficult to split these changes into
      meaningful pieces that don't break or somehow make things worse for
      the intermediate states.
      
      The patch makes a number of changes, but the most significant are
      highlighted below:
      
      * The auditd tracking variables, e.g. audit_sock, are now gone and
      replaced by a RCU/spin_lock protected variable auditd_conn which is
      a structure containing all of the auditd tracking information.
      
      * We no longer track the auditd sock directly, instead we track it
      via the network namespace in which it resides and we use the audit
      socket associated with that namespace.  In spirit, this is what the
      code was trying to do prior to this patch (at least I think that is
      what the original authors intended), but it was done rather poorly
      and added a layer of obfuscation that only masked the underlying
      problems.
      
      * Big backlog queue cleanup, again.  In v4.10 we made some pretty big
      changes to how the audit backlog queues work, here we haven't changed
      the queue design so much as cleaned up the implementation.  Brought
      about by the locking changes, we've simplified kauditd_thread() quite
      a bit by consolidating the queue handling into a new helper function,
      kauditd_send_queue(), which allows us to eliminate a lot of very
      similar code and makes the looping logic in kauditd_thread() clearer.
      
      * All netlink messages sent to auditd are now sent via
      auditd_send_unicast_skb().  Other than just making sense, this makes
      the lock handling easier.
      
      * Change the audit_log_start() sleep behavior so that we never sleep
      on auditd events (unchanged) or if the caller is holding the
      audit_cmd_mutex (changed).  Previously we didn't sleep if the caller
      was auditd or if the message type fell between a certain range; the
      type check was a poor effort of doing what the cmd_mutex check now
      does.  Richard Guy Briggs originally proposed not sleeping the
      cmd_mutex owner several years ago but his patch wasn't acceptable
      at the time.  At least the idea lives on here.
      
      * A problem with the lost record counter has been resolved.  Steve
      Grubb and I both happened to notice this problem and according to
      some quick testing by Steve, this problem goes back quite some time.
      It's largely a harmless problem, although it may have left some
      careful sysadmins quite puzzled.
      
      Cc: <stable@vger.kernel.org> # 4.10.x-
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      5b52330b
  3. 15 2月, 2017 1 次提交
  4. 14 2月, 2017 1 次提交
  5. 15 12月, 2016 1 次提交
  6. 30 11月, 2016 1 次提交
  7. 21 11月, 2016 1 次提交
  8. 15 11月, 2016 1 次提交
  9. 31 8月, 2016 1 次提交
  10. 21 7月, 2016 1 次提交
    • P
      audit: fix a double fetch in audit_log_single_execve_arg() · 43761473
      Paul Moore 提交于
      There is a double fetch problem in audit_log_single_execve_arg()
      where we first check the execve(2) argumnets for any "bad" characters
      which would require hex encoding and then re-fetch the arguments for
      logging in the audit record[1].  Of course this leaves a window of
      opportunity for an unsavory application to munge with the data.
      
      This patch reworks things by only fetching the argument data once[2]
      into a buffer where it is scanned and logged into the audit
      records(s).  In addition to fixing the double fetch, this patch
      improves on the original code in a few other ways: better handling
      of large arguments which require encoding, stricter record length
      checking, and some performance improvements (completely unverified,
      but we got rid of some strlen() calls, that's got to be a good
      thing).
      
      As part of the development of this patch, I've also created a basic
      regression test for the audit-testsuite, the test can be tracked on
      GitHub at the following link:
      
       * https://github.com/linux-audit/audit-testsuite/issues/25
      
      [1] If you pay careful attention, there is actually a triple fetch
      problem due to a strnlen_user() call at the top of the function.
      
      [2] This is a tiny white lie, we do make a call to strnlen_user()
      prior to fetching the argument data.  I don't like it, but due to the
      way the audit record is structured we really have no choice unless we
      copy the entire argument at once (which would require a rather
      wasteful allocation).  The good news is that with this patch the
      kernel no longer relies on this strnlen_user() value for anything
      beyond recording it in the log, we also update it with a trustworthy
      value whenever possible.
      Reported-by: NPengfei Wang <wpengfeinudt@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      43761473
  11. 15 7月, 2016 1 次提交
  12. 29 6月, 2016 2 次提交
  13. 17 6月, 2016 1 次提交
  14. 27 4月, 2016 1 次提交
  15. 23 3月, 2016 1 次提交
  16. 25 12月, 2015 1 次提交
  17. 07 8月, 2015 2 次提交
    • R
      audit: implement audit by executable · 34d99af5
      Richard Guy Briggs 提交于
      This adds the ability audit the actions of a not-yet-running process.
      
      This patch implements the ability to filter on the executable path.  Instead of
      just hard coding the ino and dev of the executable we care about at the moment
      the rule is inserted into the kernel, use the new audit_fsnotify
      infrastructure to manage this dynamically.  This means that if the filename
      does not yet exist but the containing directory does, or if the inode in
      question is unlinked and creat'd (aka updated) the rule will just continue to
      work.  If the containing directory is moved or deleted or the filesystem is
      unmounted, the rule is deleted automatically.  A future enhancement would be to
      have the rule survive across directory disruptions.
      
      This is a heavily modified version of a patch originally submitted by Eric
      Paris with some ideas from Peter Moody.
      
      Cc: Peter Moody <peter@hda3.com>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
      [PM: minor whitespace clean to satisfy ./scripts/checkpatch]
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      34d99af5
    • R
      audit: use macros for unset inode and device values · 84cb777e
      Richard Guy Briggs 提交于
      Clean up a number of places were casted magic numbers are used to represent
      unset inode and device numbers in preparation for the audit by executable path
      patch set.
      Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
      [PM: enclosed the _UNSET macros in parentheses for ./scripts/checkpatch]
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      84cb777e
  18. 09 7月, 2015 1 次提交
    • L
      Fix broken audit tests for exec arg len · 45820c29
      Linus Torvalds 提交于
      The "fix" in commit 0b08c5e5 ("audit: Fix check of return value of
      strnlen_user()") didn't fix anything, it broke things.  As reported by
      Steven Rostedt:
      
       "Yes, strnlen_user() returns 0 on fault, but if you look at what len is
        set to, than you would notice that on fault len would be -1"
      
      because we just subtracted one from the return value.  So testing
      against 0 doesn't test for a fault condition, it tests against a
      perfectly valid empty string.
      
      Also fix up the usual braindamage wrt using WARN_ON() inside a
      conditional - make it part of the conditional and remove the explicit
      unlikely() (which is already part of the WARN_ON*() logic, exactly so
      that you don't have to write unreadable code.
      Reported-and-tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Paul Moore <pmoore@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      45820c29
  19. 12 6月, 2015 1 次提交
  20. 30 5月, 2015 1 次提交
  21. 16 4月, 2015 1 次提交
  22. 24 2月, 2015 1 次提交
  23. 26 1月, 2015 1 次提交
  24. 23 1月, 2015 3 次提交
  25. 30 12月, 2014 1 次提交
    • P
      audit: create private file name copies when auditing inodes · fcf22d82
      Paul Moore 提交于
      Unfortunately, while commit 4a928436 ("audit: correctly record file
      names with different path name types") fixed a problem where we were
      not recording filenames, it created a new problem by attempting to use
      these file names after they had been freed.  This patch resolves the
      issue by creating a copy of the filename which the audit subsystem
      frees after it is done with the string.
      
      At some point it would be nice to resolve this issue with refcounts,
      or something similar, instead of having to allocate/copy strings, but
      that is almost surely beyond the scope of a -rcX patch so we'll defer
      that for later.  On the plus side, only audit users should be impacted
      by the string copying.
      Reported-by: NToralf Foerster <toralf.foerster@gmx.de>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      fcf22d82
  26. 23 12月, 2014 1 次提交
    • P
      audit: correctly record file names with different path name types · 4a928436
      Paul Moore 提交于
      There is a problem with the audit system when multiple audit records
      are created for the same path, each with a different path name type.
      The root cause of the problem is in __audit_inode() when an exact
      match (both the path name and path name type) is not found for a
      path name record; the existing code creates a new path name record,
      but it never sets the path name in this record, leaving it NULL.
      This patch corrects this problem by assigning the path name to these
      newly created records.
      
      There are many ways to reproduce this problem, but one of the
      easiest is the following (assuming auditd is running):
      
        # mkdir /root/tmp/test
        # touch /root/tmp/test/567
        # auditctl -a always,exit -F dir=/root/tmp/test
        # touch /root/tmp/test/567
      
      Afterwards, or while the commands above are running, check the audit
      log and pay special attention to the PATH records.  A faulty kernel
      will display something like the following for the file creation:
      
        type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2
          success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
        type=CWD msg=audit(1416957442.025:93):  cwd="/root/tmp"
        type=PATH msg=audit(1416957442.025:93): item=0 name="test/"
          inode=401409 ... nametype=PARENT
        type=PATH msg=audit(1416957442.025:93): item=1 name=(null)
          inode=393804 ... nametype=NORMAL
        type=PATH msg=audit(1416957442.025:93): item=2 name=(null)
          inode=393804 ... nametype=NORMAL
      
      While a patched kernel will show the following:
      
        type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2
          success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
        type=CWD msg=audit(1416955786.566:89):  cwd="/root/tmp"
        type=PATH msg=audit(1416955786.566:89): item=0 name="test/"
          inode=401409 ... nametype=PARENT
        type=PATH msg=audit(1416955786.566:89): item=1 name="test/567"
          inode=393804 ... nametype=NORMAL
      
      This issue was brought up by a number of people, but special credit
      should go to hujianyang@huawei.com for reporting the problem along
      with an explanation of the problem and a patch.  While the original
      patch did have some problems (see the archive link below), it did
      demonstrate the problem and helped kickstart the fix presented here.
      
        * https://lkml.org/lkml/2014/9/5/66Reported-by: Nhujianyang <hujianyang@huawei.com>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NRichard Guy Briggs <rgb@redhat.com>
      4a928436
  27. 20 11月, 2014 2 次提交
  28. 24 9月, 2014 5 次提交
  29. 09 9月, 2014 1 次提交
  30. 10 6月, 2014 1 次提交
  31. 20 3月, 2014 1 次提交