1. 30 8月, 2014 1 次提交
  2. 29 8月, 2014 1 次提交
    • C
      Smack: Bring-up access mode · d166c802
      Casey Schaufler 提交于
      People keep asking me for permissive mode, and I keep saying "no".
      
      Permissive mode is wrong for more reasons than I can enumerate,
      but the compelling one is that it's once on, never off.
      
      Nonetheless, there is an argument to be made for running a
      process with lots of permissions, logging which are required,
      and then locking the process down. There wasn't a way to do
      that with Smack, but this provides it.
      
      The notion is that you start out by giving the process an
      appropriate Smack label, such as "ATBirds". You create rules
      with a wide range of access and the "b" mode. On Tizen it
      might be:
      
      	ATBirds	System	rwxalb
      	ATBirds	User	rwxalb
      	ATBirds	_	rwxalb
      	User	ATBirds	wb
      	System	ATBirds	wb
      
      Accesses that fail will generate audit records. Accesses
      that succeed because of rules marked with a "b" generate
      log messages identifying the rule, the program and as much
      object information as is convenient.
      
      When the system is properly configured and the programs
      brought in line with the labeling scheme the "b" mode can
      be removed from the rules. When the system is ready for
      production the facility can be configured out.
      
      This provides the developer the convenience of permissive
      mode without creating a system that looks like it is
      enforcing a policy while it is not.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      d166c802
  3. 09 8月, 2014 1 次提交
    • K
      Smack: handle zero-length security labels without panic · b862e561
      Konstantin Khlebnikov 提交于
      Zero-length security labels are invalid but kernel should handle them.
      
      This patch fixes kernel panic after setting zero-length security labels:
      # attr -S -s "SMACK64" -V "" file
      
      And after writing zero-length string into smackfs files syslog and onlycp:
      # python -c 'import os; os.write(1, "")' > /smack/syslog
      
      The problem is caused by brain-damaged logic in function smk_parse_smack()
      which takes pointer to buffer and its length but if length below or equal zero
      it thinks that the buffer is zero-terminated. Unfortunately callers of this
      function are widely used and proper fix requires serious refactoring.
      Signed-off-by: NKonstantin Khlebnikov <k.khlebnikov@samsung.com>
      b862e561
  4. 01 8月, 2014 1 次提交
  5. 07 5月, 2014 1 次提交
  6. 12 4月, 2014 1 次提交
  7. 24 12月, 2013 2 次提交
  8. 12 12月, 2013 1 次提交
  9. 19 10月, 2013 1 次提交
    • C
      Smack: Implement lock security mode · c0ab6e56
      Casey Schaufler 提交于
      Linux file locking does not follow the same rules
      as other mechanisms. Even though it is a write operation
      a process can set a read lock on files which it has open
      only for read access. Two programs with read access to
      a file can use read locks to communicate.
      
      This is not acceptable in a Mandatory Access Control
      environment. Smack treats setting a read lock as the
      write operation that it is. Unfortunately, many programs
      assume that setting a read lock is a read operation.
      These programs are unhappy in the Smack environment.
      
      This patch introduces a new access mode (lock) to address
      this problem. A process with lock access to a file can
      set a read lock. A process with write access to a file can
      set a read lock or a write lock. This prevents a situation
      where processes are granted write access just so they can
      set read locks.
      
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      c0ab6e56
  10. 13 8月, 2013 1 次提交
    • R
      Smack: parse multiple rules per write to load2, up to PAGE_SIZE-1 bytes · 10289b0f
      Rafal Krypa 提交于
      Smack interface for loading rules has always parsed only single rule from
      data written to it. This requires user program to call one write() per
      each rule it wants to load.
      This change makes it possible to write multiple rules, separated by new
      line character. Smack will load at most PAGE_SIZE-1 characters and properly
      return number of processed bytes. In case when user buffer is larger, it
      will be additionally truncated. All characters after last \n will not get
      parsed to avoid partial rule near input buffer boundary.
      Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
      10289b0f
  11. 02 8月, 2013 2 次提交
  12. 04 6月, 2013 1 次提交
  13. 29 5月, 2013 1 次提交
  14. 03 4月, 2013 1 次提交
  15. 20 3月, 2013 2 次提交
  16. 15 12月, 2012 1 次提交
  17. 19 9月, 2012 1 次提交
  18. 30 7月, 2012 1 次提交
  19. 14 7月, 2012 4 次提交
  20. 15 5月, 2012 1 次提交
    • C
      Smack: allow for significantly longer Smack labels v4 · f7112e6c
      Casey Schaufler 提交于
      V4 updated to current linux-security#next
      Targeted for git://gitorious.org/smack-next/kernel.git
      
      Modern application runtime environments like to use
      naming schemes that are structured and generated without
      human intervention. Even though the Smack limit of 23
      characters for a label name is perfectly rational for
      human use there have been complaints that the limit is
      a problem in environments where names are composed from
      a set or sources, including vendor, author, distribution
      channel and application name. Names like
      
      	softwarehouse-pgwodehouse-coolappstore-mellowmuskrats
      
      are becoming harder to avoid. This patch introduces long
      label support in Smack. Labels are now limited to 255
      characters instead of the old 23.
      
      The primary reason for limiting the labels to 23 characters
      was so they could be directly contained in CIPSO category sets.
      This is still done were possible, but for labels that are too
      large a mapping is required. This is perfectly safe for communication
      that stays "on the box" and doesn't require much coordination
      between boxes beyond what would have been required to keep label
      names consistent.
      
      The bulk of this patch is in smackfs, adding and updating
      administrative interfaces. Because existing APIs can't be
      changed new ones that do much the same things as old ones
      have been introduced.
      
      The Smack specific CIPSO data representation has been removed
      and replaced with the data format used by netlabel. The CIPSO
      header is now computed when a label is imported rather than
      on use. This results in improved IP performance. The smack
      label is now allocated separately from the containing structure,
      allowing for larger strings.
      
      Four new /smack interfaces have been introduced as four
      of the old interfaces strictly required labels be specified
      in fixed length arrays.
      
      The access interface is supplemented with the check interface:
      	access  "Subject                 Object                  rwxat"
      	access2 "Subject Object rwaxt"
      
      The load interface is supplemented with the rules interface:
      	load   "Subject                 Object                  rwxat"
      	load2  "Subject Object rwaxt"
      
      The load-self interface is supplemented with the self-rules interface:
      	load-self   "Subject                 Object                  rwxat"
      	load-self2  "Subject Object rwaxt"
      
      The cipso interface is supplemented with the wire interface:
      	cipso  "Subject                  lvl cnt  c1  c2 ..."
      	cipso2 "Subject lvl cnt  c1  c2 ..."
      
      The old interfaces are maintained for compatibility.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      f7112e6c
  21. 18 4月, 2012 1 次提交
  22. 12 11月, 2011 1 次提交
    • C
      Smack: smackfs cipso seq read repair · 40809565
      Casey Schaufler 提交于
      Commit 272cd7a8 introduced
      a change to the way rule lists are handled and reported in
      the smackfs filesystem. One of the issues addressed had to
      do with the termination of read requests on /smack/load.
      This change introduced a error in /smack/cipso, which shares
      some of the same list processing code.
      
      This patch updates all the file access list handling in
      smackfs to use the code introduced for /smack/load.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      40809565
  23. 21 10月, 2011 1 次提交
  24. 19 10月, 2011 1 次提交
  25. 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
  26. 31 3月, 2011 1 次提交
  27. 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
  28. 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
  29. 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
  30. 29 10月, 2010 1 次提交
  31. 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