1. 24 6月, 2016 1 次提交
    • S
      Smack: Add support for unprivileged mounts from user namespaces · 9f50eda2
      Seth Forshee 提交于
      Security labels from unprivileged mounts cannot be trusted.
      Ideally for these mounts we would assign the objects in the
      filesystem the same label as the inode for the backing device
      passed to mount. Unfortunately it's currently impossible to
      determine which inode this is from the LSM mount hooks, so we
      settle for the label of the process doing the mount.
      
      This label is assigned to s_root, and also to smk_default to
      ensure that new inodes receive this label. The transmute property
      is also set on s_root to make this behavior more explicit, even
      though it is technically not necessary.
      
      If a filesystem has existing security labels, access to inodes is
      permitted if the label is the same as smk_root, otherwise access
      is denied. The SMACK64EXEC xattr is completely ignored.
      
      Explicit setting of security labels continues to require
      CAP_MAC_ADMIN in init_user_ns.
      
      Altogether, this ensures that filesystem objects are not
      accessible to subjects which cannot already access the backing
      store, that MAC is not violated for any objects in the fileystem
      which are already labeled, and that a user cannot use an
      unprivileged mount to gain elevated MAC privileges.
      
      sysfs, tmpfs, and ramfs are already mountable from user
      namespaces and support security labels. We can't rule out the
      possibility that these filesystems may already be used in mounts
      from user namespaces with security lables set from the init
      namespace, so failing to trust lables in these filesystems may
      introduce regressions. It is safe to trust labels from these
      filesystems, since the unprivileged user does not control the
      backing store and thus cannot supply security labels, so an
      explicit exception is made to trust labels from these
      filesystems.
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      9f50eda2
  2. 28 5月, 2016 1 次提交
  3. 11 4月, 2016 2 次提交
  4. 17 2月, 2016 1 次提交
  5. 12 2月, 2016 1 次提交
    • C
      Smack: Remove pointless hooks · 491a0b08
      Casey Schaufler 提交于
      Prior to the 4.2 kernel there no no harm in providing
      a security module hook that does nothing, as the default
      hook would get called if the module did not supply one.
      With the list based infrastructure an empty hook adds
      overhead. This patch removes the three Smack hooks that
      don't actually do anything.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      491a0b08
  6. 21 1月, 2016 1 次提交
  7. 25 12月, 2015 2 次提交
  8. 18 12月, 2015 1 次提交
  9. 14 12月, 2015 1 次提交
  10. 10 12月, 2015 1 次提交
    • C
      Smack: File receive for sockets · 79be0935
      Casey Schaufler 提交于
      The existing file receive hook checks for access on
      the file inode even for UDS. This is not right, as
      the inode is not used by Smack to make access checks
      for sockets. This change checks for an appropriate
      access relationship between the receiving (current)
      process and the socket. If the process can't write
      to the socket's send label or the socket's receive
      label can't write to the process fail.
      
      This will allow the legitimate cases, where the
      socket sender and socket receiver can freely communicate.
      Only strangly set socket labels should cause a problem.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      79be0935
  11. 20 10月, 2015 1 次提交
    • Z
      Smack: limited capability for changing process label · 38416e53
      Zbigniew Jasinski 提交于
      This feature introduces new kernel interface:
      
      - <smack_fs>/relabel-self - for setting transition labels list
      
      This list is used to control smack label transition mechanism.
      List is set by, and per process. Process can transit to new label only if
      label is on the list. Only process with CAP_MAC_ADMIN capability can add
      labels to this list. With this list, process can change it's label without
      CAP_MAC_ADMIN but only once. After label changing, list is unset.
      
      Changes in v2:
      * use list_for_each_entry instead of _rcu during label write
      * added missing description in security/Smack.txt
      
      Changes in v3:
      * squashed into one commit
      
      Changes in v4:
      * switch from global list to per-task list
      * since the per-task list is accessed only by the task itself
        there is no need to use synchronization mechanisms on it
      
      Changes in v5:
      * change smackfs interface of relabel-self to the one used for onlycap
        multiple labels are accepted, separated by space, which
        replace the previous list upon write
      Signed-off-by: NZbigniew Jasinski <z.jasinski@samsung.com>
      Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      38416e53
  12. 10 10月, 2015 3 次提交
  13. 13 8月, 2015 1 次提交
  14. 01 8月, 2015 1 次提交
  15. 28 7月, 2015 1 次提交
    • C
      Smack: IPv6 host labeling · 21abb1ec
      Casey Schaufler 提交于
      IPv6 appears to be (finally) coming of age with the
      influx of autonomous devices. In support of this, add
      the ability to associate a Smack label with IPv6 addresses.
      
      This patch also cleans up some of the conditional
      compilation associated with the introduction of
      secmark processing. It's now more obvious which bit
      of code goes with which feature.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      21abb1ec
  16. 23 7月, 2015 1 次提交
  17. 15 5月, 2015 2 次提交
    • L
      smack: pass error code through pointers · e774ad68
      Lukasz Pawelczyk 提交于
      This patch makes the following functions to use ERR_PTR() and related
      macros to pass the appropriate error code through returned pointers:
      
      smk_parse_smack()
      smk_import_entry()
      smk_fetch()
      
      It also makes all the other functions that use them to handle the
      error cases properly. This ways correct error codes from places
      where they happened can be propagated to the user space if necessary.
      
      Doing this it fixes a bug in onlycap and unconfined files
      handling. Previously their content was cleared on any error from
      smk_import_entry/smk_parse_smack, be it EINVAL (as originally intended)
      or ENOMEM. Right now it only reacts on EINVAL passing other codes
      properly to userspace.
      
      Comments have been updated accordingly.
      Signed-off-by: NLukasz Pawelczyk <l.pawelczyk@samsung.com>
      e774ad68
    • S
      Smack: ignore private inode for smack_file_receive · 9777582e
      Seung-Woo Kim 提交于
      The dmabuf fd can be shared between processes via unix domain
      socket. The file of dmabuf fd is came from anon_inode. The inode
      has no set and get xattr operations, so it can not be shared
      between processes with smack. This patch fixes just to ignore
      private inode including anon_inode for smack_file_receive.
      Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
      9777582e
  18. 12 5月, 2015 2 次提交
  19. 16 4月, 2015 1 次提交
  20. 12 4月, 2015 1 次提交
  21. 24 3月, 2015 3 次提交
    • 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
    • J
      Smack: getting the Smack security context of keys · 7fc5f36e
      José Bollo 提交于
      With this commit, the LSM Smack implements the LSM
      side part of the system call keyctl with the action
      code KEYCTL_GET_SECURITY.
      
      It is now possible to get the context of, for example,
      the user session key using the command "keyctl security @s".
      
      The original patch has been modified for merge.
      Signed-off-by: NJosé Bollo <jose.bollo@open.eurogiciel.org>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      7fc5f36e
    • M
      Smack: Assign smack_known_web as default smk_in label for kernel thread's socket · 7412301b
      Marcin Lis 提交于
      This change fixes the bug associated with sockets owned by kernel threads. These
      sockets, created usually by network devices' drivers tasks, received smk_in
      label from the task that created them - the "floor" label in the most cases. The
      result was that they were not able to receive data packets because of missing
      smack rules. The main reason of the access deny is that the socket smk_in label
      is placed as the object during smk check, kernel thread's capabilities are
      omitted.
      Signed-off-by: NMarcin Lis <m.lis@samsung.com>
      7412301b
  22. 23 2月, 2015 1 次提交
  23. 12 2月, 2015 1 次提交
  24. 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
  25. 21 1月, 2015 3 次提交
    • R
      smack: Add missing logging in bidirectional UDS connect check · 138a868f
      Rafal Krypa 提交于
      During UDS connection check, both sides are checked for write access to
      the other side. But only the first check is performed with audit support.
      The second one didn't produce any audit logs. This simple patch fixes that.
      Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
      138a868f
    • 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
    • C
      Smack: Rework file hooks · 5e7270a6
      Casey Schaufler 提交于
      This is one of those cases where you look at code you did
      years ago and wonder what you might have been thinking.
      There are a number of LSM hooks that work off of file pointers,
      and most of them really want the security data from the inode.
      Some, however, really want the security context that the process
      had when the file was opened. The difference went undetected in
      Smack until it started getting used in a real system with real
      testing. At that point it was clear that something was amiss.
      
      This patch corrects the misuse of the f_security value in several
      of the hooks. The behavior will not usually be any different, as
      the process had to be able to open the file in the first place, and
      the old check almost always succeeded, as will the new, but for
      different reasons.
      
      Thanks to the Samsung Tizen development team that identified this.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      5e7270a6
  26. 20 1月, 2015 4 次提交
  27. 20 11月, 2014 1 次提交