1. 19 10月, 2011 1 次提交
  2. 13 10月, 2011 4 次提交
    • J
      Smack: fix for /smack/access output, use string instead of byte · f8859d98
      Jarkko Sakkinen 提交于
      Small fix for the output of access SmackFS file. Use string
      is instead of byte. Makes it easier to extend API if it is
      needed.
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@intel.com>
      f8859d98
    • C
      Smack: Clean up comments · ce8a4321
      Casey Schaufler 提交于
      There are a number of comments in the Smack code that
      are either malformed or include code. This patch cleans
      them up.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      ce8a4321
    • C
      Smack: Rule list lookup performance · 272cd7a8
      Casey Schaufler 提交于
      This patch is targeted for the smack-next tree.
      
      Smack access checks suffer from two significant performance
      issues. In cases where there are large numbers of rules the
      search of the single list of rules is wasteful. Comparing the
      string values of the smack labels is less efficient than a
      numeric comparison would.
      
      These changes take advantage of the Smack label list, which
      maintains the mapping of Smack labels to secids and optional
      CIPSO labels. Because the labels are kept perpetually, an
      access check can be done strictly based on the address of the
      label in the list without ever looking at the label itself.
      Rather than keeping one global list of rules the rules with
      a particular subject label can be based off of that label
      list entry. The access check need never look at entries that
      do not use the current subject label.
      
      This requires that packets coming off the network with
      CIPSO direct Smack labels that have never been seen before
      be treated carefully. The only case where they could be
      delivered is where the receiving socket has an IPIN star
      label, so that case is explicitly addressed.
      
      On a system with 39,800 rules (200 labels in all permutations)
      a system with this patch runs an access speed test in 5% of
      the time of the old version. That should be a best case
      improvement. If all of the rules are associated with the
      same subject label and all of the accesses are for processes
      with that label (unlikely) the improvement is about 30%.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      272cd7a8
    • J
      Smack: check permissions from user space (v2) · 828716c2
      Jarkko Sakkinen 提交于
      Adds a new file into SmackFS called 'access'. Wanted
      Smack permission is written into /smack/access.
      After that result can be read from the opened file.
      If access applies result contains 1 and otherwise
      0. File access is protected from race conditions
      by using simple_transaction_get()/set() API.
      
      Fixes from the previous version:
      - Removed smack.h changes, refactoring left-over
      from previous version.
      - Removed #include <linux/smack.h>, refactoring
      left-over from previous version.
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@intel.com>
      Signed-off-by: NCasey Schaufler <cschaufler@cschaufler-intel.(none)>
      828716c2
  3. 31 3月, 2011 1 次提交
  4. 18 1月, 2011 1 次提交
    • C
      Subject: [PATCH] Smack: mmap controls for library containment · 7898e1f8
      Casey Schaufler 提交于
        In the embedded world there are often situations
        where libraries are updated from a variety of sources,
        for a variety of reasons, and with any number of
        security characteristics. These differences
        might include privilege required for a given library
        provided interface to function properly, as occurs
        from time to time in graphics libraries. There are
        also cases where it is important to limit use of
        libraries based on the provider of the library and
        the security aware application may make choices
        based on that criteria.
      
        These issues are addressed by providing an additional
        Smack label that may optionally be assigned to an object,
        the SMACK64MMAP attribute. An mmap operation is allowed
        if there is no such attribute.
      
        If there is a SMACK64MMAP attribute the mmap is permitted
        only if a subject with that label has all of the access
        permitted a subject with the current task label.
      
        Security aware applications may from time to time
        wish to reduce their "privilege" to avoid accidental use
        of privilege. One case where this arises is the
        environment in which multiple sources provide libraries
        to perform the same functions. An application may know
        that it should eschew services made available from a
        particular vendor, or of a particular version.
      
        In support of this a secondary list of Smack rules has
        been added that is local to the task. This list is
        consulted only in the case where the global list has
        approved access. It can only further restrict access.
        Unlike the global last, if no entry is found on the
        local list access is granted. An application can add
        entries to its own list by writing to /smack/load-self.
      
        The changes appear large as they involve refactoring
        the list handling to accomodate there being more
        than one rule list.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      7898e1f8
  5. 08 12月, 2010 1 次提交
    • J
      Smack: Transmute labels on specified directories · 5c6d1125
      Jarkko Sakkinen 提交于
      In a situation where Smack access rules allow processes
      with multiple labels to write to a directory it is easy
      to get into a situation where the directory gets cluttered
      with files that the owner can't deal with because while
      they could be written to the directory a process at the
      label of the directory can't write them. This is generally
      the desired behavior, but when it isn't it is a real
      issue.
      
      This patch introduces a new attribute SMACK64TRANSMUTE that
      instructs Smack to create the file with the label of the directory
      under certain circumstances.
      
      A new access mode, "t" for transmute, is made available to
      Smack access rules, which are expanded from "rwxa" to "rwxat".
      If a file is created in a directory marked as transmutable
      and if access was granted to perform the operation by a rule
      that included the transmute mode, then the file gets the
      Smack label of the directory instead of the Smack label of the
      creating process.
      
      Note that this is equivalent to creating an empty file at the
      label of the directory and then having the other process write
      to it. The transmute scheme requires that both the access rule
      allows transmutation and that the directory be explicitly marked.
      Signed-off-by: NJarkko Sakkinen <ext-jarkko.2.sakkinen@nokia.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      5c6d1125
  6. 02 12月, 2010 1 次提交
    • C
      This patch adds a new security attribute to Smack called · 676dac4b
      Casey Schaufler 提交于
      SMACK64EXEC. It defines label that is used while task is
      running.
      
      Exception: in smack_task_wait() child task is checked
      for write access to parent task using label inherited
      from the task that forked it.
      
      Fixed issues from previous submit:
      - SMACK64EXEC was not read when SMACK64 was not set.
      - inode security blob was not updated after setting
        SMACK64EXEC
      - inode security blob was not updated when removing
        SMACK64EXEC
      676dac4b
  7. 29 10月, 2010 1 次提交
  8. 15 10月, 2010 1 次提交
    • A
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann 提交于
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      seem to be a way to do that using coccinelle.
      
      Some amount of new code is currently sitting in linux-next that should get
      the same modifications, which I will do at the end of the merge window.
      
      Many thanks to Julia Lawall for helping me learn to write a semantic
      patch that does all this.
      
      ===== begin semantic patch =====
      // This adds an llseek= method to all file operations,
      // as a preparation for making no_llseek the default.
      //
      // The rules are
      // - use no_llseek explicitly if we do nonseekable_open
      // - use seq_lseek for sequential files
      // - use default_llseek if we know we access f_pos
      // - use noop_llseek if we know we don't access f_pos,
      //   but we still want to allow users to call lseek
      //
      @ open1 exists @
      identifier nested_open;
      @@
      nested_open(...)
      {
      <+...
      nonseekable_open(...)
      ...+>
      }
      
      @ open exists@
      identifier open_f;
      identifier i, f;
      identifier open1.nested_open;
      @@
      int open_f(struct inode *i, struct file *f)
      {
      <+...
      (
      nonseekable_open(...)
      |
      nested_open(...)
      )
      ...+>
      }
      
      @ read disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      <+...
      (
         *off = E
      |
         *off += E
      |
         func(..., off, ...)
      |
         E = *off
      )
      ...+>
      }
      
      @ read_no_fpos disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ write @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      <+...
      (
        *off = E
      |
        *off += E
      |
        func(..., off, ...)
      |
        E = *off
      )
      ...+>
      }
      
      @ write_no_fpos @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ fops0 @
      identifier fops;
      @@
      struct file_operations fops = {
       ...
      };
      
      @ has_llseek depends on fops0 @
      identifier fops0.fops;
      identifier llseek_f;
      @@
      struct file_operations fops = {
      ...
       .llseek = llseek_f,
      ...
      };
      
      @ has_read depends on fops0 @
      identifier fops0.fops;
      identifier read_f;
      @@
      struct file_operations fops = {
      ...
       .read = read_f,
      ...
      };
      
      @ has_write depends on fops0 @
      identifier fops0.fops;
      identifier write_f;
      @@
      struct file_operations fops = {
      ...
       .write = write_f,
      ...
      };
      
      @ has_open depends on fops0 @
      identifier fops0.fops;
      identifier open_f;
      @@
      struct file_operations fops = {
      ...
       .open = open_f,
      ...
      };
      
      // use no_llseek if we call nonseekable_open
      ////////////////////////////////////////////
      @ nonseekable1 depends on !has_llseek && has_open @
      identifier fops0.fops;
      identifier nso ~= "nonseekable_open";
      @@
      struct file_operations fops = {
      ...  .open = nso, ...
      +.llseek = no_llseek, /* nonseekable */
      };
      
      @ nonseekable2 depends on !has_llseek @
      identifier fops0.fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...  .open = open_f, ...
      +.llseek = no_llseek, /* open uses nonseekable */
      };
      
      // use seq_lseek for sequential files
      /////////////////////////////////////
      @ seq depends on !has_llseek @
      identifier fops0.fops;
      identifier sr ~= "seq_read";
      @@
      struct file_operations fops = {
      ...  .read = sr, ...
      +.llseek = seq_lseek, /* we have seq_read */
      };
      
      // use default_llseek if there is a readdir
      ///////////////////////////////////////////
      @ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier readdir_e;
      @@
      // any other fop is used that changes pos
      struct file_operations fops = {
      ... .readdir = readdir_e, ...
      +.llseek = default_llseek, /* readdir is present */
      };
      
      // use default_llseek if at least one of read/write touches f_pos
      /////////////////////////////////////////////////////////////////
      @ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read.read_f;
      @@
      // read fops use offset
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = default_llseek, /* read accesses f_pos */
      };
      
      @ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ... .write = write_f, ...
      +	.llseek = default_llseek, /* write accesses f_pos */
      };
      
      // Use noop_llseek if neither read nor write accesses f_pos
      ///////////////////////////////////////////////////////////
      
      @ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      identifier write_no_fpos.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ...
       .write = write_f,
       .read = read_f,
      ...
      +.llseek = noop_llseek, /* read and write both use no f_pos */
      };
      
      @ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write_no_fpos.write_f;
      @@
      struct file_operations fops = {
      ... .write = write_f, ...
      +.llseek = noop_llseek, /* write uses no f_pos */
      };
      
      @ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      @@
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = noop_llseek, /* read uses no f_pos */
      };
      
      @ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      @@
      struct file_operations fops = {
      ...
      +.llseek = noop_llseek, /* no read or write fn */
      };
      ===== End semantic patch =====
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Christoph Hellwig <hch@infradead.org>
      6038f373
  9. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  10. 23 9月, 2009 1 次提交
  11. 22 5月, 2009 1 次提交
  12. 15 4月, 2009 1 次提交
  13. 14 4月, 2009 1 次提交
  14. 28 3月, 2009 1 次提交
  15. 26 3月, 2009 1 次提交
  16. 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
  17. 19 2月, 2009 1 次提交
  18. 28 1月, 2009 1 次提交
  19. 09 1月, 2009 1 次提交
  20. 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
  21. 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
  22. 14 11月, 2008 2 次提交
  23. 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
  24. 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
  25. 28 4月, 2008 2 次提交
  26. 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
  27. 25 3月, 2008 1 次提交
  28. 14 3月, 2008 1 次提交
  29. 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
  30. 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