1. 29 4月, 2008 2 次提交
  2. 28 4月, 2008 1 次提交
    • A
      capabilities: implement per-process securebits · 3898b1b4
      Andrew G. Morgan 提交于
      Filesystem capability support makes it possible to do away with (set)uid-0
      based privilege and use capabilities instead.  That is, with filesystem
      support for capabilities but without this present patch, it is (conceptually)
      possible to manage a system with capabilities alone and never need to obtain
      privilege via (set)uid-0.
      
      Of course, conceptually isn't quite the same as currently possible since few
      user applications, certainly not enough to run a viable system, are currently
      prepared to leverage capabilities to exercise privilege.  Further, many
      applications exist that may never get upgraded in this way, and the kernel
      will continue to want to support their setuid-0 base privilege needs.
      
      Where pure-capability applications evolve and replace setuid-0 binaries, it is
      desirable that there be a mechanisms by which they can contain their
      privilege.  In addition to leveraging the per-process bounding and inheritable
      sets, this should include suppressing the privilege of the uid-0 superuser
      from the process' tree of children.
      
      The feature added by this patch can be leveraged to suppress the privilege
      associated with (set)uid-0.  This suppression requires CAP_SETPCAP to
      initiate, and only immediately affects the 'current' process (it is inherited
      through fork()/exec()).  This reimplementation differs significantly from the
      historical support for securebits which was system-wide, unwieldy and which
      has ultimately withered to a dead relic in the source of the modern kernel.
      
      With this patch applied a process, that is capable(CAP_SETPCAP), can now drop
      all legacy privilege (through uid=0) for itself and all subsequently
      fork()'d/exec()'d children with:
      
        prctl(PR_SET_SECUREBITS, 0x2f);
      
      This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES is
      enabled at configure time.
      
      [akpm@linux-foundation.org: fix uninitialised var warning]
      [serue@us.ibm.com: capabilities: use cap_task_prctl when !CONFIG_SECURITY]
      Signed-off-by: NAndrew G. Morgan <morgan@kernel.org>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Paul Moore <paul.moore@hp.com>
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3898b1b4
  3. 22 4月, 2008 2 次提交
  4. 21 4月, 2008 2 次提交
    • E
      SELinux: whitespace and formating fixes for hooks.c · 828dfe1d
      Eric Paris 提交于
      All whitespace and formatting.  Nothing interesting to see here.  About
      the only thing to remember is that we aren't supposed to initialize
      static variables to 0/NULL.  It is done for us and doing it ourselves
      puts them in a different section.
      
      With this patch running checkpatch.pl against hooks.c only gives us
      complaints about busting the 80 character limit and declaring extern's
      in .c files.  Apparently they don't like it, but I don't feel like going
      to the trouble of moving those to .h files...
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      828dfe1d
    • E
      SELinux: clean up printks · 744ba35e
      Eric Paris 提交于
      Make sure all printk start with KERN_*
      Make sure all printk end with \n
      Make sure all printk have the word 'selinux' in them
      Change "function name" to "%s", __func__ (found 2 wrong)
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      744ba35e
  5. 19 4月, 2008 3 次提交
  6. 18 4月, 2008 8 次提交
  7. 10 4月, 2008 1 次提交
  8. 08 4月, 2008 1 次提交
  9. 04 4月, 2008 1 次提交
  10. 02 4月, 2008 1 次提交
  11. 18 3月, 2008 1 次提交
  12. 06 3月, 2008 1 次提交
  13. 15 2月, 2008 2 次提交
  14. 11 2月, 2008 1 次提交
  15. 06 2月, 2008 1 次提交
  16. 30 1月, 2008 10 次提交
  17. 29 1月, 2008 1 次提交
  18. 25 1月, 2008 1 次提交