1. 26 3月, 2009 1 次提交
  2. 05 3月, 2009 2 次提交
    • E
      smack: fixes for unlabeled host support · 211a40c0
      etienne 提交于
      The following patch (against 2.6.29rc5) fixes a few issues in the
      smack/netlabel "unlabeled host support" functionnality that was added in
      2.6.29rc.  It should go in before -final.
      
      1) smack_host_label disregard a "0.0.0.0/0 @" rule (or other label),
      preventing 'tagged' tasks to access Internet (many systems drop packets with
      IP options)
      
      2) netmasks were not handled correctly, they were stored in a way _not
      equivalent_ to conversion to be32 (it was equivalent for /0, /8, /16, /24,
      /32 masks but not other masks)
      
      3) smack_netlbladdr prefixes (IP/mask) were not consistent (mask&IP was not
      done), so there could have been different list entries for the same IP
      prefix; if those entries had different labels, well ...
      
      4) they were not sorted
      
      1) 2) 3) are bugs, 4) is a more cosmetic issue.
      The patch :
      
      -creates a new helper smk_netlbladdr_insert to insert a smk_netlbladdr,
      -sorted by netmask length
      
      -use the new sorted nature of  smack_netlbladdrs list to simplify
       smack_host_label : the first match _will_ be the more specific
      
      -corrects endianness issues in smk_write_netlbladdr &  netlbladdr_seq_show
      
      Signed-off-by: <etienne.basset@numericable.fr>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Reviewed-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      211a40c0
    • E
      smack: fixes for unlabeled host support · 113a0e45
      etienne 提交于
      The following patch (against 2.6.29rc5) fixes a few issues in the
      smack/netlabel "unlabeled host support" functionnality that was added in
      2.6.29rc.  It should go in before -final.
      
      1) smack_host_label disregard a "0.0.0.0/0 @" rule (or other label),
      preventing 'tagged' tasks to access Internet (many systems drop packets with
      IP options)
      
      2) netmasks were not handled correctly, they were stored in a way _not
      equivalent_ to conversion to be32 (it was equivalent for /0, /8, /16, /24,
      /32 masks but not other masks)
      
      3) smack_netlbladdr prefixes (IP/mask) were not consistent (mask&IP was not
      done), so there could have been different list entries for the same IP
      prefix; if those entries had different labels, well ...
      
      4) they were not sorted
      
      1) 2) 3) are bugs, 4) is a more cosmetic issue.
      The patch :
      
      -creates a new helper smk_netlbladdr_insert to insert a smk_netlbladdr,
      -sorted by netmask length
      
      -use the new sorted nature of  smack_netlbladdrs list to simplify
       smack_host_label : the first match _will_ be the more specific
      
      -corrects endianness issues in smk_write_netlbladdr &  netlbladdr_seq_show
      
      Signed-off-by: <etienne.basset@numericable.fr>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Reviewed-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      113a0e45
  3. 19 2月, 2009 1 次提交
  4. 28 1月, 2009 1 次提交
  5. 09 1月, 2009 1 次提交
  6. 01 1月, 2009 2 次提交
    • C
      smack: Add support for unlabeled network hosts and networks · 6d3dc07c
      Casey Schaufler 提交于
      Add support for unlabeled network hosts and networks.
      Relies heavily on Paul Moore's netlabel support.
      
      Creates a new entry in /smack called netlabel. Writes to /smack/netlabel
      take the form:
      
          A.B.C.D LABEL
      or
          A.B.C.D/N LABEL
      
      where A.B.C.D is a network address, N is an integer between 0-32,
      and LABEL is the Smack label to be used. If /N is omitted /32 is
      assumed. N designates the netmask for the address. Entries are
      matched by the most specific address/mask pair. 0.0.0.0/0 will
      match everything, while 192.168.1.117/32 will match exactly one
      host.
      
      A new system label "@", pronounced "web", is defined. Processes
      can not be assigned the web label. An address assigned the web
      label can be written to by any process, and packets coming from
      a web address can be written to any socket. Use of the web label
      is a violation of any strict MAC policy, but the web label has
      been requested many times.
      
      The nltype entry has been removed from /smack. It did not work right
      and the netlabel interface can be used to specify that all hosts
      be treated as unlabeled.
      
      CIPSO labels on incoming packets will be honored, even from designated
      single label hosts. Single label hosts can only be written to by
      processes with labels that can write to the label of the host.
      Packets sent to single label hosts will always be unlabeled.
      
      Once added a single label designation cannot be removed, however
      the label may be changed.
      
      The behavior of the ambient label remains unchanged.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      6d3dc07c
    • P
      netlabel: Update kernel configuration API · 6c2e8ac0
      Paul Moore 提交于
      Update the NetLabel kernel API to expose the new features added in kernel
      releases 2.6.25 and 2.6.28: the static/fallback label functionality and network
      address based selectors.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      6c2e8ac0
  7. 25 12月, 2008 1 次提交
    • S
      smackfs: check for allocation failures in smk_set_access() · 81ea714b
      Sergio Luis 提交于
      smackfs: check for allocation failures in smk_set_access()
      
       While adding a new subject/object pair to smack_list, smk_set_access()
       didn't check the return of kzalloc().
      
       This patch changes smk_set_access() to return 0 or -ENOMEM, based on
       kzalloc()'s return. It also updates its caller, smk_write_load(), to
       check for smk_set_access()'s return, given it is no longer a void
       return function.
      Signed-off-by: NSergio Luis <sergio@larces.uece.br>
       To: Casey Schaufler <casey@schaufler-ca.com>
       Cc: Ahmed S. Darwish <darwish.07@gmail.com>
       Cc: LSM <linux-security-module@vger.kernel.org>
       Cc: LKLM <linux-kernel@vger.kernel.org>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      81ea714b
  8. 14 11月, 2008 2 次提交
  9. 10 10月, 2008 1 次提交
    • P
      netlabel: Replace protocol/NetLabel linking with refrerence counts · b1edeb10
      Paul Moore 提交于
      NetLabel has always had a list of backpointers in the CIPSO DOI definition
      structure which pointed to the NetLabel LSM domain mapping structures which
      referenced the CIPSO DOI struct.  The rationale for this was that when an
      administrator removed a CIPSO DOI from the system all of the associated
      NetLabel LSM domain mappings should be removed as well; a list of
      backpointers made this a simple operation.
      
      Unfortunately, while the backpointers did make the removal easier they were
      a bit of a mess from an implementation point of view which was making
      further development difficult.  Since the removal of a CIPSO DOI is a
      realtively rare event it seems to make sense to remove this backpointer
      list as the optimization was hurting us more then it was helping.  However,
      we still need to be able to track when a CIPSO DOI definition is being used
      so replace the backpointer list with a reference count.  In order to
      preserve the current functionality of removing the associated LSM domain
      mappings when a CIPSO DOI is removed we walk the LSM domain mapping table,
      removing the relevant entries.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      b1edeb10
  10. 05 8月, 2008 1 次提交
    • C
      smack: limit privilege by label · 15446235
      Casey Schaufler 提交于
      There have been a number of requests to make the Smack LSM
      enforce MAC even in the face of privilege, either capability
      based or superuser based. This is not universally desired,
      however, so it seems desirable to make it optional. Further,
      at least one legacy OS implemented a scheme whereby only
      processes running with one particular label could be exempt
      from MAC. This patch supports these three cases.
      
      If /smack/onlycap is empty (unset or null-string) privilege
      is enforced in the normal way.
      
      If /smack/onlycap contains a label only processes running with
      that label may be MAC exempt.
      
      If the label in /smack/onlycap is the star label ("*") the
      semantics of the star label combine with the privilege
      restrictions to prevent any violations of MAC, even in the
      presence of privilege.
      
      Again, this will be independent of the privilege scheme.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      15446235
  11. 28 4月, 2008 2 次提交
  12. 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
  13. 25 3月, 2008 1 次提交
  14. 14 3月, 2008 1 次提交
  15. 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
  16. 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