1. 08 3月, 2010 1 次提交
  2. 05 3月, 2010 1 次提交
  3. 04 3月, 2010 1 次提交
  4. 03 3月, 2010 4 次提交
  5. 25 2月, 2010 3 次提交
  6. 07 2月, 2010 5 次提交
  7. 27 1月, 2010 1 次提交
  8. 14 1月, 2010 1 次提交
    • A
      Fix ACC_MODE() for real · 6d125529
      Al Viro 提交于
      commit 5300990c had stepped on a rather
      nasty mess: definitions of ACC_MODE used to be different.  Fixed the
      resulting breakage, converting them to variant that takes O_... value;
      all callers have that and it actually simplifies life (see tomoyo part
      of changes).
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6d125529
  9. 04 1月, 2010 1 次提交
  10. 23 12月, 2009 1 次提交
  11. 17 12月, 2009 10 次提交
  12. 04 12月, 2009 1 次提交
  13. 25 11月, 2009 1 次提交
  14. 24 11月, 2009 2 次提交
    • S
      remove CONFIG_SECURITY_FILE_CAPABILITIES compile option · b3a222e5
      Serge E. Hallyn 提交于
      As far as I know, all distros currently ship kernels with default
      CONFIG_SECURITY_FILE_CAPABILITIES=y.  Since having the option on
      leaves a 'no_file_caps' option to boot without file capabilities,
      the main reason to keep the option is that turning it off saves
      you (on my s390x partition) 5k.  In particular, vmlinux sizes
      came to:
      
      without patch fscaps=n:		 	53598392
      without patch fscaps=y:		 	53603406
      with this patch applied:		53603342
      
      with the security-next tree.
      
      Against this we must weigh the fact that there is no simple way for
      userspace to figure out whether file capabilities are supported,
      while things like per-process securebits, capability bounding
      sets, and adding bits to pI if CAP_SETPCAP is in pE are not supported
      with SECURITY_FILE_CAPABILITIES=n, leaving a bit of a problem for
      applications wanting to know whether they can use them and/or why
      something failed.
      
      It also adds another subtly different set of semantics which we must
      maintain at the risk of severe security regressions.
      
      So this patch removes the SECURITY_FILE_CAPABILITIES compile
      option.  It drops the kernel size by about 50k over the stock
      SECURITY_FILE_CAPABILITIES=y kernel, by removing the
      cap_limit_ptraced_target() function.
      
      Changelog:
      	Nov 20: remove cap_limit_ptraced_target() as it's logic
      		was ifndef'ed.
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NAndrew G. Morgan" <morgan@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      b3a222e5
    • E
      SELinux: print denials for buggy kernel with unknown perms · 0bce9527
      Eric Paris 提交于
      Historically we've seen cases where permissions are requested for classes
      where they do not exist.  In particular we have seen CIFS forget to set
      i_mode to indicate it is a directory so when we later check something like
      remove_name we have problems since it wasn't defined in tclass file.  This
      used to result in a avc which included the permission 0x2000 or something.
      Currently the kernel will deny the operations (good thing) but will not
      print ANY information (bad thing).  First the auditdeny field is no
      extended to include unknown permissions.  After that is fixed the logic in
      avc_dump_query to output this information isn't right since it will remove
      the permission from the av and print the phrase "<NULL>".  This takes us
      back to the behavior before the classmap rewrite.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      0bce9527
  15. 21 11月, 2009 3 次提交
  16. 19 11月, 2009 2 次提交
    • M
      ima: replace GFP_KERNEL with GFP_NOFS · c09c59e6
      Mimi Zohar 提交于
      While running fsstress tests on the NFSv4 mounted ext3 and ext4
      filesystem, the following call trace was generated on the nfs
      server machine.
      
      Replace GFP_KERNEL with GFP_NOFS in ima_iint_insert() to avoid a
      potential deadlock.
      
           =================================
          [ INFO: inconsistent lock state ]
          2.6.31-31.el6.x86_64 #1
          ---------------------------------
          inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
          kswapd2/75 [HC0[0]:SC0[0]:HE1:SE1] takes:
           (jbd2_handle){+.+.?.}, at: [<ffffffff811edd5e>] jbd2_journal_start+0xfe/0x13f
          {RECLAIM_FS-ON-W} state was registered at:
            [<ffffffff81091e40>] mark_held_locks+0x65/0x99
            [<ffffffff81091f31>] lockdep_trace_alloc+0xbd/0xf5
            [<ffffffff81126fdd>] kmem_cache_alloc+0x40/0x185
            [<ffffffff812344d7>] ima_iint_insert+0x3d/0xf1
            [<ffffffff812345b0>] ima_inode_alloc+0x25/0x44
            [<ffffffff811484ac>] inode_init_always+0xec/0x271
            [<ffffffff81148682>] alloc_inode+0x51/0xa1
            [<ffffffff81148700>] new_inode+0x2e/0x94
            [<ffffffff811b2f08>] ext4_new_inode+0xb8/0xdc9
            [<ffffffff811be611>] ext4_create+0xcf/0x175
            [<ffffffff8113e2cd>] vfs_create+0x82/0xb8
            [<ffffffff8113f337>] do_filp_open+0x32c/0x9ee
            [<ffffffff811309b9>] do_sys_open+0x6c/0x12c
            [<ffffffff81130adc>] sys_open+0x2e/0x44
            [<ffffffff81011e42>] system_call_fastpath+0x16/0x1b
            [<ffffffffffffffff>] 0xffffffffffffffff
          irq event stamp: 90371
          hardirqs last  enabled at (90371): [<ffffffff8112708d>]
          kmem_cache_alloc+0xf0/0x185
          hardirqs last disabled at (90370): [<ffffffff81127026>]
          kmem_cache_alloc+0x89/0x185
          softirqs last  enabled at (89492): [<ffffffff81068ecf>]
          __do_softirq+0x1bf/0x1eb
          softirqs last disabled at (89477): [<ffffffff8101312c>] call_softirq+0x1c/0x30
      
          other info that might help us debug this:
          2 locks held by kswapd2/75:
           #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810f98ba>] shrink_slab+0x44/0x177
           #1:  (&type->s_umount_key#25){++++..}, at: [<ffffffff811450ba>]
      Reported-by: NMuni P. Beerakam <mbeeraka@in.ibm.com>
      Reported-by: NAmit K. Arora <amitarora@in.ibm.com>
      Cc: stable@kernel.org
      Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      c09c59e6
    • E
      sysctl: Drop & in front of every proc_handler. · 6d456111
      Eric W. Biederman 提交于
      For consistency drop & in front of every proc_handler.  Explicity
      taking the address is unnecessary and it prevents optimizations
      like stubbing the proc_handlers to NULL.
      
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      6d456111
  17. 12 11月, 2009 2 次提交