1. 27 10月, 2010 11 次提交
    • E
      IMA: fix the ToMToU logic · bade72d6
      Eric Paris 提交于
      Current logic looks like this:
      
              rc = ima_must_measure(NULL, inode, MAY_READ, FILE_CHECK);
              if (rc < 0)
                      goto out;
      
              if (mode & FMODE_WRITE) {
                      if (inode->i_readcount)
                              send_tomtou = true;
                      goto out;
              }
      
              if (atomic_read(&inode->i_writecount) > 0)
                      send_writers = true;
      
      Lets assume we have a policy which states that all files opened for read
      by root must be measured.
      
      Lets assume the file has permissions 777.
      
      Lets assume that root has the given file open for read.
      
      Lets assume that a non-root process opens the file write.
      
      The non-root process will get to ima_counts_get() and will check the
      ima_must_measure().  Since it is not supposed to measure it will goto
      out.
      
      We should check the i_readcount no matter what since we might be causing
      a ToMToU voilation!
      
      This is close to correct, but still not quite perfect.  The situation
      could have been that root, which was interested in the mesurement opened
      and closed the file and another process which is not interested in the
      measurement is the one holding the i_readcount ATM.  This is just overly
      strict on ToMToU violations, which is better than not strict enough...
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bade72d6
    • E
      IMA: explicit IMA i_flag to remove global lock on inode_delete · 196f5181
      Eric Paris 提交于
      Currently for every removed inode IMA must take a global lock and search
      the IMA rbtree looking for an associated integrity structure.  Instead
      we explicitly mark an inode when we add an integrity structure so we
      only have to take the global lock and do the removal if it exists.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      196f5181
    • E
      IMA: drop refcnt from ima_iint_cache since it isn't needed · 64c62f06
      Eric Paris 提交于
      Since finding a struct ima_iint_cache requires a valid struct inode, and
      the struct ima_iint_cache is supposed to have the same lifetime as a
      struct inode (technically they die together but don't need to be created
      at the same time) we don't have to worry about the ima_iint_cache
      outliving or dieing before the inode.  So the refcnt isn't useful.  Just
      get rid of it and free the structure when the inode is freed.
      Signed-off-by: NEric Paris <eapris@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      64c62f06
    • E
      IMA: only allocate iint when needed · bc7d2a3e
      Eric Paris 提交于
      IMA always allocates an integrity structure to hold information about
      every inode, but only needed this structure to track the number of
      readers and writers currently accessing a given inode.  Since that
      information was moved into struct inode instead of the integrity struct
      this patch stops allocating the integrity stucture until it is needed.
      Thus greatly reducing memory usage.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc7d2a3e
    • E
      IMA: move read counter into struct inode · a178d202
      Eric Paris 提交于
      IMA currently allocated an inode integrity structure for every inode in
      core.  This stucture is about 120 bytes long.  Most files however
      (especially on a system which doesn't make use of IMA) will never need
      any of this space.  The problem is that if IMA is enabled we need to
      know information about the number of readers and the number of writers
      for every inode on the box.  At the moment we collect that information
      in the per inode iint structure and waste the rest of the space.  This
      patch moves those counters into the struct inode so we can eventually
      stop allocating an IMA integrity structure except when absolutely
      needed.
      
      This patch does the minimum needed to move the location of the data.
      Further cleanups, especially the location of counter updates, may still
      be possible.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a178d202
    • E
      IMA: use i_writecount rather than a private counter · b9593d30
      Eric Paris 提交于
      IMA tracks the number of struct files which are holding a given inode
      readonly and the number which are holding the inode write or r/w.  It
      needs this information so when a new reader or writer comes in it can
      tell if this new file will be able to invalidate results it already made
      about existing files.
      
      aka if a task is holding a struct file open RO, IMA measured the file
      and recorded those measurements and then a task opens the file RW IMA
      needs to note in the logs that the old measurement may not be correct.
      It's called a "Time of Measure Time of Use" (ToMToU) issue.  The same is
      true is a RO file is opened to an inode which has an open writer.  We
      cannot, with any validity, measure the file in question since it could
      be changing.
      
      This patch attempts to use the i_writecount field to track writers.  The
      i_writecount field actually embeds more information in it's value than
      IMA needs but it should work for our purposes and allow us to shrink the
      struct inode even more.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b9593d30
    • E
      IMA: use inode->i_lock to protect read and write counters · ad16ad00
      Eric Paris 提交于
      Currently IMA used the iint->mutex to protect the i_readcount and
      i_writecount.  This patch uses the inode->i_lock since we are going to
      start using in inode objects and that is the most appropriate lock.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ad16ad00
    • E
      IMA: convert internal flags from long to char · 15aac676
      Eric Paris 提交于
      The IMA flags is an unsigned long but there is only 1 flag defined.
      Lets save a little space and make it a char.  This packs nicely next to
      the array of u8's.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      15aac676
    • E
      IMA: use unsigned int instead of long for counters · 497f3233
      Eric Paris 提交于
      Currently IMA uses 2 longs in struct inode.  To save space (and as it
      seems impossible to overflow 32 bits) we switch these to unsigned int.
      The switch to unsigned does require slightly different checks for
      underflow, but it isn't complex.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      497f3233
    • E
      IMA: drop the inode opencount since it isn't needed for operation · b575156d
      Eric Paris 提交于
      The opencount was used to help debugging to make sure that everything
      which created a struct file also correctly made the IMA calls.  Since we
      moved all of that into the VFS this isn't as necessary.  We should be
      able to get the same amount of debugging out of just the reader and
      write count.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b575156d
    • E
      IMA: use rbtree instead of radix tree for inode information cache · 85491641
      Eric Paris 提交于
      The IMA code needs to store the number of tasks which have an open fd
      granting permission to write a file even when IMA is not in use.  It
      needs this information in order to be enabled at a later point in time
      without losing it's integrity garantees.
      
      At the moment that means we store a little bit of data about every inode
      in a cache.  We use a radix tree key'd on the inode's memory address.
      Dave Chinner pointed out that a radix tree is a terrible data structure
      for such a sparse key space.  This patch switches to using an rbtree
      which should be more efficient.
      
      Bug report from Dave:
      
       "I just noticed that slabtop was reporting an awfully high usage of
        radix tree nodes:
      
         OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
        4200331 2778082  66%    0.55K 144839       29   2317424K radix_tree_node
        2321500 2060290  88%    1.00K  72581       32   2322592K xfs_inode
        2235648 2069791  92%    0.12K  69864       32    279456K iint_cache
      
        That is, 2.7M radix tree nodes are allocated, and the cache itself is
        consuming 2.3GB of RAM.  I know that the XFS inodei caches are indexed
        by radix tree node, but for 2 million cached inodes that would mean a
        density of 1 inode per radix tree node, which for a system with 16M
        inodes in the filsystems is an impossibly low density.  The worst I've
        seen in a production system like kernel.org is about 20-25% density,
        which would mean about 150-200k radix tree nodes for that many inodes.
        So it's not the inode cache.
      
        So I looked up what the iint_cache was.  It appears to used for
        storing per-inode IMA information, and uses a radix tree for indexing.
        It uses the *address* of the struct inode as the indexing key.  That
        means the key space is extremely sparse - for XFS the struct inode
        addresses are approximately 1000 bytes apart, which means the closest
        the radix tree index keys get is ~1000.  Which means that there is a
        single entry per radix tree leaf node, so the radix tree is using
        roughly 550 bytes for every 120byte structure being cached.  For the
        above example, it's probably wasting close to 1GB of RAM...."
      Reported-by: NDave Chinner <david@fromorbit.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      85491641
  2. 27 9月, 2010 1 次提交
  3. 10 9月, 2010 2 次提交
    • D
      KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring · 3d96406c
      David Howells 提交于
      Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership
      of the parent process's session keyring whether or not the parent has a session
      keyring [CVE-2010-2960].
      
      This results in the following oops:
      
        BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
        IP: [<ffffffff811ae4dd>] keyctl_session_to_parent+0x251/0x443
        ...
        Call Trace:
         [<ffffffff811ae2f3>] ? keyctl_session_to_parent+0x67/0x443
         [<ffffffff8109d286>] ? __do_fault+0x24b/0x3d0
         [<ffffffff811af98c>] sys_keyctl+0xb4/0xb8
         [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b
      
      if the parent process has no session keyring.
      
      If the system is using pam_keyinit then it mostly protected against this as all
      processes derived from a login will have inherited the session keyring created
      by pam_keyinit during the log in procedure.
      
      To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.
      Reported-by: NTavis Ormandy <taviso@cmpxchg8b.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NTavis Ormandy <taviso@cmpxchg8b.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3d96406c
    • D
      KEYS: Fix RCU no-lock warning in keyctl_session_to_parent() · 9d1ac65a
      David Howells 提交于
      There's an protected access to the parent process's credentials in the middle
      of keyctl_session_to_parent().  This results in the following RCU warning:
      
        ===================================================
        [ INFO: suspicious rcu_dereference_check() usage. ]
        ---------------------------------------------------
        security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!
      
        other info that might help us debug this:
      
        rcu_scheduler_active = 1, debug_locks = 0
        1 lock held by keyctl-session-/2137:
         #0:  (tasklist_lock){.+.+..}, at: [<ffffffff811ae2ec>] keyctl_session_to_parent+0x60/0x236
      
        stack backtrace:
        Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1
        Call Trace:
         [<ffffffff8105606a>] lockdep_rcu_dereference+0xaa/0xb3
         [<ffffffff811ae379>] keyctl_session_to_parent+0xed/0x236
         [<ffffffff811af77e>] sys_keyctl+0xb4/0xb6
         [<ffffffff81001eab>] system_call_fastpath+0x16/0x1b
      
      The code should take the RCU read lock to make sure the parents credentials
      don't go away, even though it's holding a spinlock and has IRQ disabled.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d1ac65a
  4. 08 9月, 2010 5 次提交
  5. 18 8月, 2010 4 次提交
    • N
      tty: fix fu_list abuse · d996b62a
      Nick Piggin 提交于
      tty: fix fu_list abuse
      
      tty code abuses fu_list, which causes a bug in remount,ro handling.
      
      If a tty device node is opened on a filesystem, then the last link to the inode
      removed, the filesystem will be allowed to be remounted readonly. This is
      because fs_may_remount_ro does not find the 0 link tty inode on the file sb
      list (because the tty code incorrectly removed it to use for its own purpose).
      This can result in a filesystem with errors after it is marked "clean".
      
      Taking idea from Christoph's initial patch, allocate a tty private struct
      at file->private_data and put our required list fields in there, linking
      file and tty. This makes tty nodes behave the same way as other device nodes
      and avoid meddling with the vfs, and avoids this bug.
      
      The error handling is not trivial in the tty code, so for this bugfix, I take
      the simple approach of using __GFP_NOFAIL and don't worry about memory errors.
      This is not a problem because our allocator doesn't fail small allocs as a rule
      anyway. So proper error handling is left as an exercise for tty hackers.
      
      [ Arguably filesystem's device inode would ideally be divorced from the
      driver's pseudo inode when it is opened, but in practice it's not clear whether
      that will ever be worth implementing. ]
      
      Cc: linux-kernel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d996b62a
    • N
      fs: cleanup files_lock locking · ee2ffa0d
      Nick Piggin 提交于
      fs: cleanup files_lock locking
      
      Lock tty_files with a new spinlock, tty_files_lock; provide helpers to
      manipulate the per-sb files list; unexport the files_lock spinlock.
      
      Cc: linux-kernel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ee2ffa0d
    • N
      apparmor: use task path helpers · 44672e4f
      Nick Piggin 提交于
      apparmor: use task path helpers
      Signed-off-by: NNick Piggin <npiggin@kernel.dk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      44672e4f
    • D
      Make do_execve() take a const filename pointer · d7627467
      David Howells 提交于
      Make do_execve() take a const filename pointer so that kernel_execve() compiles
      correctly on ARM:
      
      arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type
      
      This also requires the argv and envp arguments to be consted twice, once for
      the pointer array and once for the strings the array points to.  This is
      because do_execve() passes a pointer to the filename (now const) to
      copy_strings_kernel().  A simpler alternative would be to cast the filename
      pointer in do_execve() when it's passed to copy_strings_kernel().
      
      do_execve() may not change any of the strings it is passed as part of the argv
      or envp lists as they are some of them in .rodata, so marking these strings as
      const should be fine.
      
      Further kernel_execve() and sys_execve() need to be changed to match.
      
      This has been test built on x86_64, frv, arm and mips.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7627467
  6. 17 8月, 2010 1 次提交
  7. 13 8月, 2010 1 次提交
  8. 11 8月, 2010 1 次提交
  9. 07 8月, 2010 2 次提交
  10. 05 8月, 2010 1 次提交
    • R
      apparmor: depends on NET · 06c22dad
      Randy Dunlap 提交于
      SECURITY_APPARMOR should depend on NET since AUDIT needs
      (depends on) NET.
      
      Fixes 70-80 errors that occur when CONFIG_NET is not enabled,
      but APPARMOR selects AUDIT without qualification.  E.g.:
      
      audit.c:(.text+0x33361): undefined reference to `netlink_unicast'
      (.text+0x333df): undefined reference to `netlink_unicast'
      audit.c:(.text+0x3341d): undefined reference to `skb_queue_tail'
      audit.c:(.text+0x33424): undefined reference to `kfree_skb'
      audit.c:(.text+0x334cb): undefined reference to `kfree_skb'
      audit.c:(.text+0x33597): undefined reference to `skb_put'
      audit.c:(.text+0x3369b): undefined reference to `__alloc_skb'
      audit.c:(.text+0x336d7): undefined reference to `kfree_skb'
      (.text+0x3374c): undefined reference to `__alloc_skb'
      auditfilter.c:(.text+0x35305): undefined reference to `skb_queue_tail'
      lsm_audit.c:(.text+0x2873): undefined reference to `init_net'
      lsm_audit.c:(.text+0x2878): undefined reference to `dev_get_by_index'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      06c22dad
  11. 02 8月, 2010 11 次提交