1. 09 Sep, 2014 1 commit
  2. 01 Aug, 2014 1 commit
  3. 30 Apr, 2014 1 commit
  4. 23 Apr, 2014 1 commit
  5. 11 Apr, 2014 8 commits
  6. 14 Mar, 2014 2 commits
  7. 14 Jan, 2014 1 commit
  8. 31 Dec, 2013 2 commits
    • Casey Schaufler's avatar
      Smack: File receive audit correction · 4482a44f
      Casey Schaufler authored
      Eric Paris politely points out:
          Inside smack_file_receive() it seems like you are initting the audit
          field with LSM_AUDIT_DATA_TASK.  And then use
          Seems like LSM_AUDIT_DATA_PATH would make more sense.  (and depending
          on how it's used fix a crash...)
      He is correct. This puts things in order.
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
    • Casey Schaufler's avatar
      Smack: Rationalize mount restrictions · 24ea1b6e
      Casey Schaufler authored
      The mount restrictions imposed by Smack rely heavily on the
      use of the filesystem "floor", which is the label that all
      processes writing to the filesystem must have access to. It
      turns out that while the "floor" notion is sound, it has yet
      to be fully implemented and has never been used.
      The sb_mount and sb_umount hooks only make sense if the
      filesystem floor is used actively, and it isn't. They can
      be reintroduced if a rational restriction comes up. Until
      then, they get removed.
      The sb_kern_mount hook is required for the option processing.
      It is too permissive in the case of unprivileged mounts,
      effectively bypassing the CAP_MAC_ADMIN restrictions if
      any of the smack options are specified. Unprivileged mounts
      are no longer allowed to set Smack filesystem options.
      Additionally, the root and default values are set to the
      label of the caller, in keeping with the policy that objects
      get the label of their creator.
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
  9. 23 Dec, 2013 1 commit
  10. 19 Dec, 2013 1 commit
  11. 28 Oct, 2013 1 commit
  12. 18 Oct, 2013 1 commit
    • Casey Schaufler's avatar
      Smack: Implement lock security mode · c0ab6e56
      Casey Schaufler authored
      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: default avatarCasey Schaufler <casey@schaufler-ca.com>
  13. 06 Aug, 2013 1 commit
  14. 02 Aug, 2013 1 commit
    • Casey Schaufler's avatar
      Smack: network label match fix · 677264e8
      Casey Schaufler authored
      The Smack code that matches incoming CIPSO tags with Smack labels
      reaches through the NetLabel interfaces and compares the network
      data with the CIPSO header associated with a Smack label. This was
      done in a ill advised attempt to optimize performance. It works
      so long as the categories fit in a single capset, but this isn't
      always the case.
      This patch changes the Smack code to use the appropriate NetLabel
      interfaces to compare the incoming CIPSO header with the CIPSO
      header associated with a label. It will always match the CIPSO
      headers correctly.
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
  15. 01 Aug, 2013 1 commit
    • Tomasz Stanislawski's avatar
      security: smack: add a hash table to quicken smk_find_entry() · 4d7cf4a1
      Tomasz Stanislawski authored
      Accepted for the smack-next tree after changing the number of
      slots from 128 to 16.
      This patch adds a hash table to quicken searching of a smack label by its name.
      Basically, the patch improves performance of SMACK initialization.  Parsing of
      rules involves translation from a string to a smack_known (aka label) entity
      which is done in smk_find_entry().
      The current implementation of the function iterates over a global list of
      smack_known resulting in O(N) complexity for smk_find_entry().  The total
      complexity of SMACK initialization becomes O(rules * labels).  Therefore it
      scales quadratically with a complexity of a system.
      Applying the patch reduced the complexity of smk_find_entry() to O(1) as long
      as number of label is in hundreds. If the number of labels is increased please
      update SMACK_HASH_SLOTS constant defined in security/smack/smack.h. Introducing
      the configuration of this constant with Kconfig or cmdline might be a good
      The size of the hash table was adjusted experimentally.  The rule set used by
      TIZEN contains circa 17K rules for 500 labels.  The table above contains
      results of SMACK initialization using 'time smackctl apply' bash command.
      The 'Ref' is a kernel without this patch applied. The consecutive values
      refers to value of SMACK_HASH_SLOTS.  Every measurement was repeated three
      times to reduce noise.
           |  Ref  |   1   |   2   |   4   |   8   |   16  |   32  |   64  |  128  |  256  |  512
      Run1 | 1.156 | 1.096 | 0.883 | 0.764 | 0.692 | 0.667 | 0.649 | 0.633 | 0.634 | 0.629 | 0.620
      Run2 | 1.156 | 1.111 | 0.885 | 0.764 | 0.694 | 0.661 | 0.649 | 0.651 | 0.634 | 0.638 | 0.623
      Run3 | 1.160 | 1.107 | 0.886 | 0.764 | 0.694 | 0.671 | 0.661 | 0.638 | 0.631 | 0.624 | 0.638
      AVG  | 1.157 | 1.105 | 0.885 | 0.764 | 0.693 | 0.666 | 0.653 | 0.641 | 0.633 | 0.630 | 0.627
      Surprisingly, a single hlist is slightly faster than a double-linked list.
      The speed-up saturates near 64 slots.  Therefore I chose value 128 to provide
      some margin if more labels were used.
      It looks that IO becomes a new bottleneck.
      Signed-off-by: default avatarTomasz Stanislawski <t.stanislaws@samsung.com>
  16. 25 Jul, 2013 1 commit
  17. 08 Jun, 2013 1 commit
  18. 28 May, 2013 3 commits
  19. 19 Mar, 2013 1 commit
    • Igor Zhbanov's avatar
      Fix NULL pointer dereference in smack_inode_unlink() and smack_inode_rmdir() · cdb56b60
      Igor Zhbanov authored
      This patch fixes kernel Oops because of wrong common_audit_data type
      in smack_inode_unlink() and smack_inode_rmdir().
      When SMACK security module is enabled and SMACK logging is on (/smack/logging
      is not zero) and you try to delete the file which
      1) you cannot delete due to SMACK rules and logging of failures is on
      2) you can delete and logging of success is on,
      you will see following:
      	Unable to handle kernel NULL pointer dereference at virtual address 000002d7
      	[<...>] (strlen+0x0/0x28)
      	[<...>] (audit_log_untrustedstring+0x14/0x28)
      	[<...>] (common_lsm_audit+0x108/0x6ac)
      	[<...>] (smack_log+0xc4/0xe4)
      	[<...>] (smk_curacc+0x80/0x10c)
      	[<...>] (smack_inode_unlink+0x74/0x80)
      	[<...>] (security_inode_unlink+0x2c/0x30)
      	[<...>] (vfs_unlink+0x7c/0x100)
      	[<...>] (do_unlinkat+0x144/0x16c)
      The function smack_inode_unlink() (and smack_inode_rmdir()) need
      to log two structures of different types. First of all it does:
      	smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_DENTRY);
      	smk_ad_setfield_u_fs_path_dentry(&ad, dentry);
      This will set common audit data type to LSM_AUDIT_DATA_DENTRY
      and store dentry for auditing (by function smk_curacc(), which in turn calls
      dump_common_audit_data(), which is actually uses provided data and logs it).
      	 * You need write access to the thing you're unlinking
      	rc = smk_curacc(smk_of_inode(ip), MAY_WRITE, &ad);
      	if (rc == 0) {
      		 * You also need write access to the containing directory
      Then this function wants to log anoter data:
      		smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
      		smk_ad_setfield_u_fs_inode(&ad, dir);
      The function sets inode field, but don't change common_audit_data type.
      		rc = smk_curacc(smk_of_inode(dir), MAY_WRITE, &ad);
      So the dump_common_audit() function incorrectly interprets inode structure
      as dentry, and Oops will happen.
      This patch reinitializes common_audit_data structures with correct type.
      Also I removed unneeded
      	smk_ad_setfield_u_fs_path_dentry(&ad, NULL);
      initialization, because both dentry and inode pointers are stored
      in the same union.
      Signed-off-by: default avatarIgor Zhbanov <i.zhbanov@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
  20. 23 Feb, 2013 1 commit
  21. 12 Oct, 2012 1 commit
  22. 18 Sep, 2012 2 commits
    • Casey Schaufler's avatar
      Smack: setprocattr memory leak fix · 46a2f3b9
      Casey Schaufler authored
      The data structure allocations being done in prepare_creds
      are duplicated in smack_setprocattr. This results in the
      structure allocated in prepare_creds being orphaned and
      never freed. The duplicate code is removed from
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
    • Casey Schaufler's avatar
      Smack: remove task_wait() hook. · c00bedb3
      Casey Schaufler authored
      On 12/20/2011 11:20 PM, Jarkko Sakkinen wrote:
      > Allow SIGCHLD to be passed to child process without
      > explicit policy. This will help to keep the access
      > control policy simple and easily maintainable with
      > complex applications that require use of multiple
      > security contexts. It will also help to keep them
      > as isolated as possible.
      > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
      I have a slightly different version that applies to the
      current smack-next tree.
      Allow SIGCHLD to be passed to child process without
      explicit policy. This will help to keep the access
      control policy simple and easily maintainable with
      complex applications that require use of multiple
      security contexts. It will also help to keep them
      as isolated as possible.
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
       security/smack/smack_lsm.c |   37 ++++++++-----------------------------
       1 files changed, 8 insertions(+), 29 deletions(-)
  23. 13 Jul, 2012 2 commits
    • Casey Schaufler's avatar
      Smack: onlycap limits on CAP_MAC_ADMIN · 1880eff7
      Casey Schaufler authored
      Smack is integrated with the POSIX capabilities scheme,
      using the capabilities CAP_MAC_OVERRIDE and CAP_MAC_ADMIN to
      determine if a process is allowed to ignore Smack checks or
      change Smack related data respectively. Smack provides an
      additional restriction that if an onlycap value is set
      by writing to /smack/onlycap only tasks with that Smack
      label are allowed to use CAP_MAC_OVERRIDE.
      This change adds CAP_MAC_ADMIN as a capability that is affected
      by the onlycap mechanism.
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
    • Casey Schaufler's avatar
      Smack: fix smack_new_inode bogosities · eb982cb4
      Casey Schaufler authored
      In January of 2012 Al Viro pointed out three bits of code that
      he titled "new_inode_smack bogosities". This patch repairs these
      1. smack_sb_kern_mount() included a NULL check that is impossible.
         The check and NULL case are removed.
      2. smack_kb_kern_mount() included pointless locking. The locking is
         removed. Since this is the only place that lock was used the lock
         is removed from the superblock_smack structure.
      3. smk_fill_super() incorrectly and unnecessarily set the Smack label
         for the smackfs root inode. The assignment has been removed.
      Targeted for git://gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
  24. 31 May, 2012 2 commits
  25. 15 May, 2012 2 commits
    • Casey Schaufler's avatar
      Smack: allow for significantly longer Smack labels v4 · f7112e6c
      Casey Schaufler authored
      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
      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: default avatarCasey Schaufler <casey@schaufler-ca.com>
    • Tetsuo Handa's avatar
      gfp flags for security_inode_alloc()? · ceffec55
      Tetsuo Handa authored
      Dave Chinner wrote:
      > Yes, because you have no idea what the calling context is except
      > for the fact that is from somewhere inside filesystem code and the
      > filesystem could be holding locks. Therefore, GFP_NOFS is really the
      > only really safe way to allocate memory here.
      I see. Thank you.
      I'm not sure, but can call trace happen where somewhere inside network
      filesystem or stackable filesystem code with locks held invokes operations that
      involves GFP_KENREL memory allocation outside that filesystem?
      [PATCH] SMACK: Fix incorrect GFP_KERNEL usage.
      new_inode_smack() which can be called from smack_inode_alloc_security() needs
      to use GFP_NOFS like SELinux's inode_alloc_security() does, for
      security_inode_alloc() is called from inode_init_always() and
      inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.
      smack_inode_init_security() needs to use GFP_NOFS like
      selinux_inode_init_security() does, for initxattrs() callback function (e.g.
      btrfs_initxattrs()) which is called from security_inode_init_security() is
      using GFP_NOFS.
      smack_audit_rule_match() needs to use GFP_ATOMIC, for
      security_audit_rule_match() can be called from audit_filter_user_rules() and
      audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarCasey Schaufler <cschaufler@cschaufler-intel.(none)>