1. 14 11月, 2008 1 次提交
  2. 10 10月, 2008 1 次提交
  3. 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
  4. 27 7月, 2008 1 次提交
  5. 14 7月, 2008 2 次提交
    • J
      security: remove register_security hook · 6f0f0fd4
      James Morris 提交于
      The register security hook is no longer required, as the capability
      module is always registered.  LSMs wishing to stack capability as
      a secondary module should do so explicitly.
      Signed-off-by: NJames Morris <jmorris@namei.org>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6f0f0fd4
    • S
      Security: split proc ptrace checking into read vs. attach · 006ebb40
      Stephen Smalley 提交于
      Enable security modules to distinguish reading of process state via
      proc from full ptrace access by renaming ptrace_may_attach to
      ptrace_may_access and adding a mode argument indicating whether only
      read access or full attach access is requested.  This allows security
      modules to permit access to reading process state without granting
      full ptrace access.  The base DAC/capability checking remains unchanged.
      
      Read access to /proc/pid/mem continues to apply a full ptrace attach
      check since check_mem_permission() already requires the current task
      to already be ptracing the target.  The other ptrace checks within
      proc for elements like environ, maps, and fds are changed to pass the
      read mode instead of attach.
      
      In the SELinux case, we model such reading of process state as a
      reading of a proc file labeled with the target process' label.  This
      enables SELinux policy to permit such reading of process state without
      permitting control or manipulation of the target process, as there are
      a number of cases where programs probe for such information via proc
      but do not need to be able to control the target (e.g. procps,
      lsof, PolicyKit, ConsoleKit).  At present we have to choose between
      allowing full ptrace in policy (more permissive than required/desired)
      or breaking functionality (or in some cases just silencing the denials
      via dontaudit rules but this can hide genuine attacks).
      
      This version of the patch incorporates comments from Casey Schaufler
      (change/replace existing ptrace_may_attach interface, pass access
      mode), and Chris Wright (provide greater consistency in the checking).
      
      Note that like their predecessors __ptrace_may_attach and
      ptrace_may_attach, the __ptrace_may_access and ptrace_may_access
      interfaces use different return value conventions from each other (0
      or -errno vs. 1 or 0).  I retained this difference to avoid any
      changes to the caller logic but made the difference clearer by
      changing the latter interface to return a bool rather than an int and
      by adding a comment about it to ptrace.h for any future callers.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      006ebb40
  6. 04 6月, 2008 1 次提交
  7. 30 4月, 2008 4 次提交
  8. 29 4月, 2008 1 次提交
  9. 28 4月, 2008 2 次提交
  10. 22 4月, 2008 1 次提交
  11. 19 4月, 2008 1 次提交
    • A
      Security: Introduce security= boot parameter · 076c54c5
      Ahmed S. Darwish 提交于
      Add the security= boot parameter. This is done to avoid LSM
      registration clashes in case of more than one bult-in module.
      
      User can choose a security module to enable at boot. If no
      security= boot parameter is specified, only the first LSM
      asking for registration will be loaded. An invalid security
      module name will be treated as if no module has been chosen.
      
      LSM modules must check now if they are allowed to register
      by calling security_module_enable(ops) first. Modify SELinux
      and SMACK to do so.
      
      Do not let SMACK register smackfs if it was not chosen on
      boot. Smackfs assumes that smack hooks are registered and
      the initial task security setup (swapper->security) is done.
      Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      076c54c5
  12. 13 4月, 2008 1 次提交
    • P
      NetLabel: Allow passing the LSM domain as a shared pointer · 00447872
      Paul Moore 提交于
      Smack doesn't have the need to create a private copy of the LSM "domain" when
      setting NetLabel security attributes like SELinux, however, the current
      NetLabel code requires a private copy of the LSM "domain".  This patches fixes
      that by letting the LSM determine how it wants to pass the domain value.
      
       * NETLBL_SECATTR_DOMAIN_CPY
         The current behavior, NetLabel assumes that the domain value is a copy and
         frees it when done
      
       * NETLBL_SECATTR_DOMAIN
         New, Smack-friendly behavior, NetLabel assumes that the domain value is a
         reference to a string managed by the LSM and does not free it when done
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00447872
  13. 21 3月, 2008 1 次提交
  14. 20 3月, 2008 1 次提交
  15. 06 3月, 2008 1 次提交
  16. 24 2月, 2008 1 次提交
  17. 19 2月, 2008 1 次提交
    • C
      Smack: unlabeled outgoing ambient packets · 4bc87e62
      Casey Schaufler 提交于
      Smack uses CIPSO labeling, but allows for unlabeled packets by
      specifying an "ambient" label that is applied to incoming unlabeled
      packets.
      
      Because the other end of the connection may dislike IP options, and ssh
      is one know application that behaves thus, it is prudent to respond in
      kind.
      
      This patch changes the network labeling behavior such that an outgoing
      packet that would be given a CIPSO label that matches the ambient label
      is left unlabeled.  An "unlbl" domain is added and the netlabel
      defaulting mechanism invoked rather than assuming that everything is
      CIPSO.  Locking has been added around changes to the ambient label as
      the mechanisms used to do so are more involved.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4bc87e62
  18. 15 2月, 2008 1 次提交
    • J
      Embed a struct path into struct nameidata instead of nd->{dentry,mnt} · 4ac91378
      Jan Blunck 提交于
      This is the central patch of a cleanup series. In most cases there is no good
      reason why someone would want to use a dentry for itself. This series reflects
      that fact and embeds a struct path into nameidata.
      
      Together with the other patches of this series
      - it enforced the correct order of getting/releasing the reference count on
        <dentry,vfsmount> pairs
      - it prepares the VFS for stacking support since it is essential to have a
        struct path in every place where the stack can be traversed
      - it reduces the overall code size:
      
      without patch series:
         text    data     bss     dec     hex filename
      5321639  858418  715768 6895825  6938d1 vmlinux
      
      with patch series:
         text    data     bss     dec     hex filename
      5320026  858418  715768 6894212  693284 vmlinux
      
      This patch:
      
      Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix cifs]
      [akpm@linux-foundation.org: fix smack]
      Signed-off-by: NJan Blunck <jblunck@suse.de>
      Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ac91378
  19. 14 2月, 2008 1 次提交
  20. 06 2月, 2008 1 次提交
    • C
      Smack: Simplified Mandatory Access Control Kernel · e114e473
      Casey Schaufler 提交于
      Smack is the Simplified Mandatory Access Control Kernel.
      
      Smack implements mandatory access control (MAC) using labels
      attached to tasks and data containers, including files, SVIPC,
      and other tasks. Smack is a kernel based scheme that requires
      an absolute minimum of application support and a very small
      amount of configuration data.
      
      Smack uses extended attributes and
      provides a set of general mount options, borrowing technics used
      elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
      a pseudo-filesystem smackfs that is used for manipulation of
      system Smack attributes.
      
      The patch, patches for ls and sshd, a README, a startup script,
      and x86 binaries for ls and sshd are also available on
      
          http://www.schaufler-ca.com
      
      Development has been done using Fedora Core 7 in a virtual machine
      environment and on an old Sony laptop.
      
      Smack provides mandatory access controls based on the label attached
      to a task and the label attached to the object it is attempting to
      access. Smack labels are deliberately short (1-23 characters) text
      strings. Single character labels using special characters are reserved
      for system use. The only operation applied to Smack labels is equality
      comparison. No wildcards or expressions, regular or otherwise, are
      used. Smack labels are composed of printable characters and may not
      include "/".
      
      A file always gets the Smack label of the task that created it.
      
      Smack defines and uses these labels:
      
          "*" - pronounced "star"
          "_" - pronounced "floor"
          "^" - pronounced "hat"
          "?" - pronounced "huh"
      
      The access rules enforced by Smack are, in order:
      
      1. Any access requested by a task labeled "*" is denied.
      2. A read or execute access requested by a task labeled "^"
         is permitted.
      3. A read or execute access requested on an object labeled "_"
         is permitted.
      4. Any access requested on an object labeled "*" is permitted.
      5. Any access requested by a task on an object with the same
         label is permitted.
      6. Any access requested that is explicitly defined in the loaded
         rule set is permitted.
      7. Any other access is denied.
      
      Rules may be explicitly defined by writing subject,object,access
      triples to /smack/load.
      
      Smack rule sets can be easily defined that describe Bell&LaPadula
      sensitivity, Biba integrity, and a variety of interesting
      configurations. Smack rule sets can be modified on the fly to
      accommodate changes in the operating environment or even the time
      of day.
      
      Some practical use cases:
      
      Hierarchical levels. The less common of the two usual uses
      for MLS systems is to define hierarchical levels, often
      unclassified, confidential, secret, and so on. To set up smack
      to support this, these rules could be defined:
      
         C        Unclass rx
         S        C       rx
         S        Unclass rx
         TS       S       rx
         TS       C       rx
         TS       Unclass rx
      
      A TS process can read S, C, and Unclass data, but cannot write it.
      An S process can read C and Unclass. Note that specifying that
      TS can read S and S can read C does not imply TS can read C, it
      has to be explicitly stated.
      
      Non-hierarchical categories. This is the more common of the
      usual uses for an MLS system. Since the default rule is that a
      subject cannot access an object with a different label no
      access rules are required to implement compartmentalization.
      
      A case that the Bell & LaPadula policy does not allow is demonstrated
      with this Smack access rule:
      
      A case that Bell&LaPadula does not allow that Smack does:
      
          ESPN    ABC   r
          ABC     ESPN  r
      
      On my portable video device I have two applications, one that
      shows ABC programming and the other ESPN programming. ESPN wants
      to show me sport stories that show up as news, and ABC will
      only provide minimal information about a sports story if ESPN
      is covering it. Each side can look at the other's info, neither
      can change the other. Neither can see what FOX is up to, which
      is just as well all things considered.
      
      Another case that I especially like:
      
          SatData Guard   w
          Guard   Publish w
      
      A program running with the Guard label opens a UDP socket and
      accepts messages sent by a program running with a SatData label.
      The Guard program inspects the message to ensure it is wholesome
      and if it is sends it to a program running with the Publish label.
      This program then puts the information passed in an appropriate
      place. Note that the Guard program cannot write to a Publish
      file system object because file system semanitic require read as
      well as write.
      
      The four cases (categories, levels, mutual read, guardbox) here
      are all quite real, and problems I've been asked to solve over
      the years. The first two are easy to do with traditonal MLS systems
      while the last two you can't without invoking privilege, at least
      for a while.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Cc: Joshua Brindle <method@manicmethod.com>
      Cc: Paul Moore <paul.moore@hp.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e114e473