1. 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
  2. 02 3月, 2017 1 次提交
  3. 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
  4. 19 8月, 2016 1 次提交
  5. 25 12月, 2015 1 次提交
  6. 22 10月, 2015 1 次提交
  7. 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
  8. 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
  9. 19 6月, 2014 1 次提交
  10. 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
  11. 20 11月, 2013 1 次提交
  12. 29 8月, 2013 1 次提交
  13. 26 7月, 2013 6 次提交
  14. 09 6月, 2013 1 次提交
  15. 23 7月, 2012 1 次提交
  16. 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
  17. 06 1月, 2012 4 次提交
  18. 10 9月, 2011 4 次提交
  19. 25 4月, 2011 1 次提交
  20. 02 4月, 2011 1 次提交
  21. 29 3月, 2011 1 次提交
  22. 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
  23. 21 10月, 2010 4 次提交
    • E
      SELinux: allow userspace to read policy back out of the kernel · cee74f47
      Eric Paris 提交于
      There is interest in being able to see what the actual policy is that was
      loaded into the kernel.  The patch creates a new selinuxfs file
      /selinux/policy which can be read by userspace.  The actual policy that is
      loaded into the kernel will be written back out to userspace.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      cee74f47
    • E
      secmark: make secmark object handling generic · 2606fd1f
      Eric Paris 提交于
      Right now secmark has lots of direct selinux calls.  Use all LSM calls and
      remove all SELinux specific knowledge.  The only SELinux specific knowledge
      we leave is the mode.  The only point is to make sure that other LSMs at
      least test this generic code before they assume it works.  (They may also
      have to make changes if they do not represent labels as strings)
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NPaul Moore <paul.moore@hp.com>
      Acked-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      2606fd1f
    • K
      selinux: fix up style problem on /selinux/status · 36f7f284
      KaiGai Kohei 提交于
      This patch fixes up coding-style problem at this commit:
      
       4f27a7d49789b04404eca26ccde5f527231d01d5
       selinux: fast status update interface (/selinux/status)
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      36f7f284
    • K
      selinux: fast status update interface (/selinux/status) · 11904167
      KaiGai Kohei 提交于
      This patch provides a new /selinux/status entry which allows applications
      read-only mmap(2).
      This region reflects selinux_kernel_status structure in kernel space.
        struct selinux_kernel_status
        {
                u32     length;         /* length of this structure */
                u32     sequence;       /* sequence number of seqlock logic */
                u32     enforcing;      /* current setting of enforcing mode */
                u32     policyload;     /* times of policy reloaded */
                u32     deny_unknown;   /* current setting of deny_unknown */
        };
      
      When userspace object manager caches access control decisions provided
      by SELinux, it needs to invalidate the cache on policy reload and setenforce
      to keep consistency.
      However, the applications need to check the kernel state for each accesses
      on userspace avc, or launch a background worker process.
      In heuristic, frequency of invalidation is much less than frequency of
      making access control decision, so it is annoying to invoke a system call
      to check we don't need to invalidate the userspace cache.
      If we can use a background worker thread, it allows to receive invalidation
      messages from the kernel. But it requires us an invasive coding toward the
      base application in some cases; E.g, when we provide a feature performing
      with SELinux as a plugin module, it is unwelcome manner to launch its own
      worker thread from the module.
      
      If we could map /selinux/status to process memory space, application can
      know updates of selinux status; policy reload or setenforce.
      
      A typical application checks selinux_kernel_status::sequence when it tries
      to reference userspace avc. If it was changed from the last time when it
      checked userspace avc, it means something was updated in the kernel space.
      Then, the application can reset userspace avc or update current enforcing
      mode, without any system call invocations.
      This sequence number is updated according to the seqlock logic, so we need
      to wait for a while if it is odd number.
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Acked-by: NEric Paris <eparis@redhat.com>
      --
       security/selinux/include/security.h |   21 ++++++
       security/selinux/selinuxfs.c        |   56 +++++++++++++++
       security/selinux/ss/Makefile        |    2 +-
       security/selinux/ss/services.c      |    3 +
       security/selinux/ss/status.c        |  129 +++++++++++++++++++++++++++++++++++
       5 files changed, 210 insertions(+), 1 deletions(-)
      Signed-off-by: NJames Morris <jmorris@namei.org>
      11904167
  24. 04 2月, 2010 1 次提交
  25. 18 1月, 2010 1 次提交
    • S
      selinux: change the handling of unknown classes · 19439d05
      Stephen Smalley 提交于
      If allow_unknown==deny, SELinux treats an undefined kernel security
      class as an error condition rather than as a typical permission denial
      and thus does not allow permissions on undefined classes even when in
      permissive mode.  Change the SELinux logic so that this case is handled
      as a typical permission denial, subject to the usual permissive mode and
      permissive domain handling.
      
      Also drop the 'requested' argument from security_compute_av() and
      helpers as it is a legacy of the original security server interface and
      is unused.
      
      Changes:
      - Handle permissive domains consistently by moving up the test for a
      permissive domain.
      - Make security_compute_av_user() consistent with security_compute_av();
      the only difference now is that security_compute_av() performs mapping
      between the kernel-private class and permission indices and the policy
      values.  In the userspace case, this mapping is handled by libselinux.
      - Moved avd_init inside the policy lock.
      
      Based in part on a patch by Paul Moore <paul.moore@hp.com>.
      Reported-by: NAndrew Worsley <amworsley@gmail.com>
      Signed-off-by: NStephen D. Smalley <sds@tycho.nsa.gov>
      Reviewed-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      19439d05