1. 24 5月, 2017 3 次提交
  2. 23 5月, 2017 1 次提交
    • S
      selinux: log policy capability state when a policy is loaded · 4dc2fce3
      Stephen Smalley 提交于
      Log the state of SELinux policy capabilities when a policy is loaded.
      For each policy capability known to the kernel, log the policy capability
      name and the value set in the policy.  For policy capabilities that are
      set in the loaded policy but unknown to the kernel, log the policy
      capability index, since this is the only information presently available
      in the policy.
      
      Sample output with a policy created with a new capability defined
      that is not known to the kernel:
      SELinux:  policy capability network_peer_controls=1
      SELinux:  policy capability open_perms=1
      SELinux:  policy capability extended_socket_class=1
      SELinux:  policy capability always_check_network=0
      SELinux:  policy capability cgroup_seclabel=0
      SELinux:  unknown policy capability 5
      
      Resolves: https://github.com/SELinuxProject/selinux-kernel/issues/32Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      4dc2fce3
  3. 02 3月, 2017 1 次提交
  4. 09 1月, 2017 1 次提交
    • S
      selinux: support distinctions among all network address families · da69a530
      Stephen Smalley 提交于
      Extend SELinux to support distinctions among all network address families
      implemented by the kernel by defining new socket security classes
      and mapping to them. Otherwise, many sockets are mapped to the generic
      socket class and are indistinguishable in policy.  This has come up
      previously with regard to selectively allowing access to bluetooth sockets,
      and more recently with regard to selectively allowing access to AF_ALG
      sockets.  Guido Trentalancia submitted a patch that took a similar approach
      to add only support for distinguishing AF_ALG sockets, but this generalizes
      his approach to handle all address families implemented by the kernel.
      Socket security classes are also added for ICMP and SCTP sockets.
      Socket security classes were not defined for AF_* values that are reserved
      but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ASH,
      AF_ECONET, AF_SNA, AF_WANPIPE.
      
      Backward compatibility is provided by only enabling the finer-grained
      socket classes if a new policy capability is set in the policy; older
      policies will behave as before.  The legacy redhat1 policy capability
      that was only ever used in testing within Fedora for ptrace_child
      is reclaimed for this purpose; as far as I can tell, this policy
      capability is not enabled in any supported distro policy.
      
      Add a pair of conditional compilation guards to detect when new AF_* values
      are added so that we can update SELinux accordingly rather than having to
      belatedly update it long after new address families are introduced.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      da69a530
  5. 19 8月, 2016 1 次提交
  6. 25 12月, 2015 1 次提交
  7. 22 10月, 2015 1 次提交
  8. 14 7月, 2015 1 次提交
    • J
      selinux: extended permissions for ioctls · fa1aa143
      Jeff Vander Stoep 提交于
      Add extended permissions logic to selinux. Extended permissions
      provides additional permissions in 256 bit increments. Extend the
      generic ioctl permission check to use the extended permissions for
      per-command filtering. Source/target/class sets including the ioctl
      permission may additionally include a set of commands. Example:
      
      allowxperm <source> <target>:<class> ioctl unpriv_app_socket_cmds
      auditallowxperm <source> <target>:<class> ioctl priv_gpu_cmds
      
      Where unpriv_app_socket_cmds and priv_gpu_cmds are macros
      representing commonly granted sets of ioctl commands.
      
      When ioctl commands are omitted only the permissions are checked.
      This feature is intended to provide finer granularity for the ioctl
      permission that may be too imprecise. For example, the same driver
      may use ioctls to provide important and benign functionality such as
      driver version or socket type as well as dangerous capabilities such
      as debugging features, read/write/execute to physical memory or
      access to sensitive data. Per-command filtering provides a mechanism
      to reduce the attack surface of the kernel, and limit applications
      to the subset of commands required.
      
      The format of the policy binary has been modified to include ioctl
      commands, and the policy version number has been incremented to
      POLICYDB_VERSION_XPERMS_IOCTL=30 to account for the format
      change.
      
      The extended permissions logic is deliberately generic to allow
      components to be reused e.g. netlink filters
      Signed-off-by: NJeff Vander Stoep <jeffv@google.com>
      Acked-by: NNick Kralevich <nnk@google.com>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      fa1aa143
  9. 05 6月, 2015 1 次提交
    • S
      selinux: enable per-file labeling for debugfs files. · 134509d5
      Stephen Smalley 提交于
      Add support for per-file labeling of debugfs files so that
      we can distinguish them in policy.  This is particularly
      important in Android where certain debugfs files have to be writable
      by apps and therefore the debugfs directory tree can be read and
      searched by all.
      
      Since debugfs is entirely kernel-generated, the directory tree is
      immutable by userspace, and the inodes are pinned in memory, we can
      simply use the same approach as with proc and label the inodes from
      policy based on pathname from the root of the debugfs filesystem.
      Generalize the existing labeling support used for proc and reuse it
      for debugfs too.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      134509d5
  10. 19 6月, 2014 1 次提交
  11. 10 3月, 2014 1 次提交
    • N
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov 提交于
      security_xfrm_policy_alloc can be called in atomic context so the
      allocation should be done with GFP_ATOMIC. Add an argument to let the
      callers choose the appropriate way. In order to do so a gfp argument
      needs to be added to the method xfrm_policy_alloc_security in struct
      security_operations and to the internal function
      selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
      callers and leave GFP_KERNEL as before for the rest.
      The path that needed the gfp argument addition is:
      security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security ->
      all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) ->
      selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)
      
      Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
      add it to security_context_to_sid which is used inside and prior to this
      patch did only GFP_KERNEL allocation. So add gfp argument to
      security_context_to_sid and adjust all of its callers as well.
      
      CC: Paul Moore <paul@paul-moore.com>
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: LSM list <linux-security-module@vger.kernel.org>
      CC: SELinux list <selinux@tycho.nsa.gov>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  12. 20 11月, 2013 1 次提交
  13. 29 8月, 2013 1 次提交
  14. 26 7月, 2013 6 次提交
  15. 09 6月, 2013 1 次提交
  16. 23 7月, 2012 1 次提交
  17. 10 4月, 2012 2 次提交
    • E
      SELinux: add default_type statements · eed7795d
      Eric Paris 提交于
      Because Fedora shipped userspace based on my development tree we now
      have policy version 27 in the wild defining only default user, role, and
      range.  Thus to add default_type we need a policy.28.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      eed7795d
    • E
      SELinux: allow default source/target selectors for user/role/range · aa893269
      Eric Paris 提交于
      When new objects are created we have great and flexible rules to
      determine the type of the new object.  We aren't quite as flexible or
      mature when it comes to determining the user, role, and range.  This
      patch adds a new ability to specify the place a new objects user, role,
      and range should come from.  For users and roles it can come from either
      the source or the target of the operation.  aka for files the user can
      either come from the source (the running process and todays default) or
      it can come from the target (aka the parent directory of the new file)
      
      examples always are done with
      directory context: system_u:object_r:mnt_t:s0-s0:c0.c512
      process context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      
      [no rule]
      	unconfined_u:object_r:mnt_t:s0   test_none
      [default user source]
      	unconfined_u:object_r:mnt_t:s0   test_user_source
      [default user target]
      	system_u:object_r:mnt_t:s0       test_user_target
      [default role source]
      	unconfined_u:unconfined_r:mnt_t:s0 test_role_source
      [default role target]
      	unconfined_u:object_r:mnt_t:s0   test_role_target
      [default range source low]
      	unconfined_u:object_r:mnt_t:s0 test_range_source_low
      [default range source high]
      	unconfined_u:object_r:mnt_t:s0:c0.c1023 test_range_source_high
      [default range source low-high]
      	unconfined_u:object_r:mnt_t:s0-s0:c0.c1023 test_range_source_low-high
      [default range target low]
      	unconfined_u:object_r:mnt_t:s0 test_range_target_low
      [default range target high]
      	unconfined_u:object_r:mnt_t:s0:c0.c512 test_range_target_high
      [default range target low-high]
      	unconfined_u:object_r:mnt_t:s0-s0:c0.c512 test_range_target_low-high
      Signed-off-by: NEric Paris <eparis@redhat.com>
      aa893269
  18. 06 1月, 2012 4 次提交
  19. 10 9月, 2011 4 次提交
  20. 25 4月, 2011 1 次提交
  21. 02 4月, 2011 1 次提交
  22. 29 3月, 2011 1 次提交
  23. 02 2月, 2011 1 次提交
    • E
      SELinux: Use dentry name in new object labeling · 652bb9b0
      Eric Paris 提交于
      Currently SELinux has rules which label new objects according to 3 criteria.
      The label of the process creating the object, the label of the parent
      directory, and the type of object (reg, dir, char, block, etc.)  This patch
      adds a 4th criteria, the dentry name, thus we can distinguish between
      creating a file in an etc_t directory called shadow and one called motd.
      
      There is no file globbing, regex parsing, or anything mystical.  Either the
      policy exactly (strcmp) matches the dentry name of the object or it doesn't.
      This patch has no changes from today if policy does not implement the new
      rules.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      652bb9b0
  24. 21 10月, 2010 3 次提交