1. 27 9月, 2008 1 次提交
  2. 11 9月, 2008 1 次提交
  3. 04 9月, 2008 1 次提交
  4. 03 9月, 2008 1 次提交
  5. 28 8月, 2008 2 次提交
    • K
      SELinux: add boundary support and thread context assignment · d9250dea
      KaiGai Kohei 提交于
      The purpose of this patch is to assign per-thread security context
      under a constraint. It enables multi-threaded server application
      to kick a request handler with its fair security context, and
      helps some of userspace object managers to handle user's request.
      
      When we assign a per-thread security context, it must not have wider
      permissions than the original one. Because a multi-threaded process
      shares a single local memory, an arbitary per-thread security context
      also means another thread can easily refer violated information.
      
      The constraint on a per-thread security context requires a new domain
      has to be equal or weaker than its original one, when it tries to assign
      a per-thread security context.
      
      Bounds relationship between two types is a way to ensure a domain can
      never have wider permission than its bounds. We can define it in two
      explicit or implicit ways.
      
      The first way is using new TYPEBOUNDS statement. It enables to define
      a boundary of types explicitly. The other one expand the concept of
      existing named based hierarchy. If we defines a type with "." separated
      name like "httpd_t.php", toolchain implicitly set its bounds on "httpd_t".
      
      This feature requires a new policy version.
      The 24th version (POLICYDB_VERSION_BOUNDARY) enables to ship them into
      kernel space, and the following patch enables to handle it.
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      d9250dea
    • E
      securityfs: do not depend on CONFIG_SECURITY · da31894e
      Eric Paris 提交于
      Add a new Kconfig option SECURITYFS which will build securityfs support
      but does not require CONFIG_SECURITY.  The only current user of
      securityfs does not depend on CONFIG_SECURITY and there is no reason the
      full LSM needs to be built to build this fs.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      da31894e
  6. 20 8月, 2008 1 次提交
  7. 15 8月, 2008 1 次提交
  8. 14 8月, 2008 1 次提交
    • D
      security: Fix setting of PF_SUPERPRIV by __capable() · 5cd9c58f
      David Howells 提交于
      Fix the setting of PF_SUPERPRIV by __capable() as it could corrupt the flags
      the target process if that is not the current process and it is trying to
      change its own flags in a different way at the same time.
      
      __capable() is using neither atomic ops nor locking to protect t->flags.  This
      patch removes __capable() and introduces has_capability() that doesn't set
      PF_SUPERPRIV on the process being queried.
      
      This patch further splits security_ptrace() in two:
      
       (1) security_ptrace_may_access().  This passes judgement on whether one
           process may access another only (PTRACE_MODE_ATTACH for ptrace() and
           PTRACE_MODE_READ for /proc), and takes a pointer to the child process.
           current is the parent.
      
       (2) security_ptrace_traceme().  This passes judgement on PTRACE_TRACEME only,
           and takes only a pointer to the parent process.  current is the child.
      
           In Smack and commoncap, this uses has_capability() to determine whether
           the parent will be permitted to use PTRACE_ATTACH if normal checks fail.
           This does not set PF_SUPERPRIV.
      
      Two of the instances of __capable() actually only act on current, and so have
      been changed to calls to capable().
      
      Of the places that were using __capable():
      
       (1) The OOM killer calls __capable() thrice when weighing the killability of a
           process.  All of these now use has_capability().
      
       (2) cap_ptrace() and smack_ptrace() were using __capable() to check to see
           whether the parent was allowed to trace any process.  As mentioned above,
           these have been split.  For PTRACE_ATTACH and /proc, capable() is now
           used, and for PTRACE_TRACEME, has_capability() is used.
      
       (3) cap_safe_nice() only ever saw current, so now uses capable().
      
       (4) smack_setprocattr() rejected accesses to tasks other than current just
           after calling __capable(), so the order of these two tests have been
           switched and capable() is used instead.
      
       (5) In smack_file_send_sigiotask(), we need to allow privileged processes to
           receive SIGIO on files they're manipulating.
      
       (6) In smack_task_wait(), we let a process wait for a privileged process,
           whether or not the process doing the waiting is privileged.
      
      I've tested this with the LTP SELinux and syscalls testscripts.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: NAndrew G. Morgan <morgan@kernel.org>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      5cd9c58f
  9. 07 8月, 2008 1 次提交
  10. 05 8月, 2008 5 次提交
  11. 30 7月, 2008 1 次提交
    • E
      SELinux: /proc/mounts should show what it can · 383795c2
      Eric Paris 提交于
      Given a hosed SELinux config in which a system never loads policy or
      disables SELinux we currently just return -EINVAL for anyone trying to
      read /proc/mounts.  This is a configuration problem but we can certainly
      be more graceful.  This patch just ignores -EINVAL when displaying LSM
      options and causes /proc/mounts display everything else it can.  If
      policy isn't loaded the obviously there are no options, so we aren't
      really loosing any information here.
      
      This is safe as the only other return of EINVAL comes from
      security_sid_to_context_core() in the case of an invalid sid.  Even if a
      FS was mounted with a now invalidated context that sid should have been
      remapped to unlabeled and so we won't hit the EINVAL and will work like
      we should.  (yes, I tested to make sure it worked like I thought)
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Tested-by: NMarc Dionne <marc.c.dionne@gmail.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      383795c2
  12. 27 7月, 2008 4 次提交
  13. 26 7月, 2008 3 次提交
  14. 25 7月, 2008 2 次提交
  15. 15 7月, 2008 1 次提交
  16. 14 7月, 2008 14 次提交