1. 23 7月, 2015 1 次提交
  2. 03 6月, 2015 1 次提交
    • R
      Smack: allow multiple labels in onlycap · c0d77c88
      Rafal Krypa 提交于
      Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to
      processes running with the configured label. But having single privileged
      label is not enough in some real use cases. On a complex system like Tizen,
      there maybe few programs that need to configure Smack policy in run-time
      and running them all with a single label is not always practical.
      This patch extends onlycap feature for multiple labels. They are configured
      in the same smackfs "onlycap" interface, separated by spaces.
      Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
      c0d77c88
  3. 12 5月, 2015 2 次提交
  4. 24 3月, 2015 1 次提交
    • C
      Smack: Allow an unconfined label in bringup mode · bf4b2fee
      Casey Schaufler 提交于
      I have vehemently opposed adding a "permissive" mode to Smack
      for the simple reasons that it would be subject to massive abuse
      and that developers refuse to turn it off come product release.
      I still believe that this is true, and still refuse to add a
      general "permissive mode". So don't ask again.
      
      Bumjin Im suggested an approach that addresses most of the concerns,
      and I have implemented it here. I still believe that we'd be better
      off without this sort of thing, but it looks like this minimizes the
      abuse potential.
      
      Firstly, you have to configure Smack Bringup Mode. That allows
      for "release" software to be ammune from abuse. Second, only one
      label gets to be "permissive" at a time. You can use it for
      debugging, but that's about it.
      
      A label written to smackfs/unconfined is treated specially.
      If either the subject or object label of an access check
      matches the "unconfined" label, and the access would not
      have been allowed otherwise an audit record and a console
      message are generated. The audit record "request" string is
      marked with either "(US)" or "(UO)", to indicate that the
      request was granted because of an unconfined label. The
      fact that an inode was accessed by an unconfined label is
      remembered, and subsequent accesses to that "impure"
      object are noted in the log. The impurity is not stored in
      the filesystem, so a file mislabled as a side effect of
      using an unconfined label may still cause concern after
      a reboot.
      
      So, it's there, it's dangerous, but so many application
      developers seem incapable of living without it I have
      given in. I've tried to make it as safe as I can, but
      in the end it's still a chain saw.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      bf4b2fee
  5. 22 1月, 2015 1 次提交
    • A
      smack: fix possible use after frees in task_security() callers · 6d1cff2a
      Andrey Ryabinin 提交于
      We hit use after free on dereferncing pointer to task_smack struct in
      smk_of_task() called from smack_task_to_inode().
      
      task_security() macro uses task_cred_xxx() to get pointer to the task_smack.
      task_cred_xxx() could be used only for non-pointer members of task's
      credentials. It cannot be used for pointer members since what they point
      to may disapper after dropping RCU read lock.
      
      Mainly task_security() used this way:
      	smk_of_task(task_security(p))
      
      Intead of this introduce function smk_of_task_struct() which
      takes task_struct as argument and returns pointer to smk_known struct
      and do this under RCU read lock.
      Bogus task_security() macro is not used anymore, so remove it.
      
      KASan's report for this:
      
      	AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600
      	=============================================================================
      	BUG kmalloc-64 (Tainted: PO): kasan error
      	-----------------------------------------------------------------------------
      
      	Disabling lock debugging due to kernel taint
      	INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866
      		kmem_cache_alloc_trace+0x88/0x1bc
      		new_task_smack+0x44/0xd8
      		smack_cred_prepare+0x48/0x21c
      		security_prepare_creds+0x44/0x4c
      		prepare_creds+0xdc/0x110
      		smack_setprocattr+0x104/0x150
      		security_setprocattr+0x4c/0x54
      		proc_pid_attr_write+0x12c/0x194
      		vfs_write+0x1b0/0x370
      		SyS_write+0x5c/0x94
      		ret_fast_syscall+0x0/0x48
      	INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564
      		kfree+0x270/0x290
      		smack_cred_free+0xc4/0xd0
      		security_cred_free+0x34/0x3c
      		put_cred_rcu+0x58/0xcc
      		rcu_process_callbacks+0x738/0x998
      		__do_softirq+0x264/0x4cc
      		do_softirq+0x94/0xf4
      		irq_exit+0xbc/0x120
      		handle_IRQ+0x104/0x134
      		gic_handle_irq+0x70/0xac
      		__irq_svc+0x44/0x78
      		_raw_spin_unlock+0x18/0x48
      		sync_inodes_sb+0x17c/0x1d8
      		sync_filesystem+0xac/0xfc
      		vdfs_file_fsync+0x90/0xc0
      		vfs_fsync_range+0x74/0x7c
      	INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080
      	INFO: Object 0xc4635600 @offset=5632 fp=0x  (null)
      
      	Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
      	Redzone c4635640: bb bb bb bb                                      ....
      	Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      	CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1
      	Backtrace:
      	[<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24)
      	 r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140
      	[<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28)
      	[<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144)
      	[<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44)
      	 r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600
      	[<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538)
      	 r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7
      	[<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8)
      	[<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70)
      	 r5:c4635600 r4:ca9da000
      	[<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44)
      	 r5:cca25e80 r4:c0ba9780
      	[<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178)
      	 r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124
      	[<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4)
      	 r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148
      	[<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108)
      	[<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648)
      	[<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88)
      	[<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198)
      	 r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000
      	[<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34)
      	[<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48)
      	Read of size 4 by thread T834:
      	Memory state around the buggy address:
      	 c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      	 c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	>c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	           ^
      	 c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	 c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
      	 c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	==================================================================
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: <stable@vger.kernel.org>
      6d1cff2a
  6. 21 1月, 2015 1 次提交
    • C
      Smack: secmark support for netfilter · 69f287ae
      Casey Schaufler 提交于
      Smack uses CIPSO to label internet packets and thus provide
      for access control on delivery of packets. The netfilter facility
      was not used to allow for Smack to work properly without netfilter
      configuration. Smack does not need netfilter, however there are
      cases where it would be handy.
      
      As a side effect, the labeling of local IPv4 packets can be optimized
      and the handling of local IPv6 packets is just all out better.
      
      The best part is that the netfilter tools use "contexts" that
      are just strings, and they work just as well for Smack as they
      do for SELinux.
      
      All of the conditional compilation for IPv6 was implemented
      by Rafal Krypa <r.krypa@samsung.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      69f287ae
  7. 30 8月, 2014 1 次提交
  8. 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
  9. 12 4月, 2014 3 次提交
  10. 24 12月, 2013 1 次提交
  11. 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
  12. 02 8月, 2013 2 次提交
    • C
      Smack: network label match fix · 677264e8
      Casey Schaufler 提交于
      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: NCasey Schaufler <casey@schaufler-ca.com>
      677264e8
    • T
      security: smack: add a hash table to quicken smk_find_entry() · 4d7cf4a1
      Tomasz Stanislawski 提交于
      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
      idea.
      
      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: NTomasz Stanislawski <t.stanislaws@samsung.com>
      4d7cf4a1
  13. 29 5月, 2013 3 次提交
  14. 20 3月, 2013 1 次提交
  15. 14 7月, 2012 2 次提交
    • C
      Smack: onlycap limits on CAP_MAC_ADMIN · 1880eff7
      Casey Schaufler 提交于
      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: NCasey Schaufler <casey@schaufler-ca.com>
      1880eff7
    • C
      Smack: fix smack_new_inode bogosities · eb982cb4
      Casey Schaufler 提交于
      In January of 2012 Al Viro pointed out three bits of code that
      he titled "new_inode_smack bogosities". This patch repairs these
      errors.
      
      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: NCasey Schaufler <casey@schaufler-ca.com>
      eb982cb4
  16. 15 5月, 2012 2 次提交
    • 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
    • C
      Smack: recursive tramsmute · 2267b13a
      Casey Schaufler 提交于
      The transmuting directory feature of Smack requires that
      the transmuting attribute be explicitly set in all cases.
      It seems the users of this facility would expect that the
      transmuting attribute be inherited by subdirectories that
      are created in a transmuting directory. This does not seem
      to add any additional complexity to the understanding of
      how the system works.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      2267b13a
  17. 10 4月, 2012 1 次提交
  18. 04 4月, 2012 2 次提交
    • E
      LSM: shrink the common_audit_data data union · 48c62af6
      Eric Paris 提交于
      After shrinking the common_audit_data stack usage for private LSM data I'm
      not going to shrink the data union.  To do this I'm going to move anything
      larger than 2 void * ptrs to it's own structure and require it to be declared
      separately on the calling stack.  Thus hot paths which don't need more than
      a couple pointer don't have to declare space to hold large unneeded
      structures.  I could get this down to one void * by dealing with the key
      struct and the struct path.  We'll see if that is helpful after taking care of
      networking.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c62af6
    • E
      LSM: shrink sizeof LSM specific portion of common_audit_data · 3b3b0e4f
      Eric Paris 提交于
      Linus found that the gigantic size of the common audit data caused a big
      perf hit on something as simple as running stat() in a loop.  This patch
      requires LSMs to declare the LSM specific portion separately rather than
      doing it in a union.  Thus each LSM can be responsible for shrinking their
      portion and don't have to pay a penalty just because other LSMs have a
      bigger space requirement.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b3b0e4f
  19. 21 10月, 2011 1 次提交
  20. 13 10月, 2011 2 次提交
    • 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
  21. 26 4月, 2011 2 次提交
  22. 10 2月, 2011 1 次提交
  23. 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
  24. 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
  25. 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
  26. 02 8月, 2010 1 次提交
  27. 10 7月, 2009 2 次提交
  28. 14 4月, 2009 1 次提交