Skip to content

GitLab

I
ipipe
Switch branch/tag
  1. 09 Sep, 2014 1 commit
  3. 28 Jul, 2014 1 commit
  5. 25 Jul, 2014 1 commit
  7. 10 Jul, 2014 1 commit
    • Paul Moore's avatar
      selinux: fix the default socket labeling in sock_graft() · 4da6daf4
      Paul Moore authored 
      The sock_graft() hook has special handling for AF_INET, AF_INET, and
AF_UNIX sockets as those address families have special hooks which
label the sock before it is attached its associated socket.
Unfortunately, the sock_graft() hook was missing a default approach
to labeling sockets which meant that any other address family which
made use of connections or the accept() syscall would find the
returned socket to be in an "unlabeled" state.  This was recently
demonstrated by the kcrypto/AF_ALG subsystem and the newly released
cryptsetup package (cryptsetup v1.6.5 and later).

This patch preserves the special handling in selinux_sock_graft(),
but adds a default behavior - setting the sock's label equal to the
associated socket - which resolves the problem with AF_ALG and
presumably any other address family which makes use of accept().

Cc: stable@vger.kernel.org
Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
Tested-by: default avatarMilan Broz <gmazyland@gmail.com>
      4da6daf4
  9. 01 Apr, 2014 1 commit
  11. 14 Mar, 2014 1 commit
  13. 10 Mar, 2014 1 commit
    • Nikolay Aleksandrov's avatar
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov authored 
      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: default avatarNikolay Aleksandrov <nikolay@redhat.com>
Acked-by: default avatarPaul Moore <paul@paul-moore.com>
Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  15. 25 Jul, 2013 2 commits
  17. 08 Jun, 2013 4 commits
  19. 12 May, 2013 1 commit
  21. 10 Apr, 2013 1 commit
  23. 09 Apr, 2013 1 commit
  25. 02 Apr, 2013 1 commit
    • Jeff Layton's avatar
      selinux: make security_sb_clone_mnt_opts return an error on context mismatch · 094f7b69
      Jeff Layton authored 
      I had the following problem reported a while back. If you mount the
same filesystem twice using NFSv4 with different contexts, then the
second context= option is ignored. For instance:

    # mount server:/export /mnt/test1
    # mount server:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
    # ls -dZ /mnt/test1
    drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test1
    # ls -dZ /mnt/test2
    drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test2

When we call into SELinux to set the context of a "cloned" superblock,
it will currently just bail out when it notices that we're reusing an
existing superblock. Since the existing superblock is already set up and
presumably in use, we can't go overwriting its context with the one from
the "original" sb. Because of this, the second context= option in this
case cannot take effect.

This patch fixes this by turning security_sb_clone_mnt_opts into an int
return operation. When it finds that the "new" superblock that it has
been handed is already set up, it checks to see whether the contexts on
the old superblock match it. If it does, then it will just return
success, otherwise it'll return -EBUSY and emit a printk to tell the
admin why the second mount failed.

Note that this patch may cause casualties. The NFSv4 code relies on
being able to walk down to an export from the pseudoroot. If you mount
filesystems that are nested within one another with different contexts,
then this patch will make those mounts fail in new and "exciting" ways.

For instance, suppose that /export is a separate filesystem on the
server:

    # mount server:/ /mnt/test1
    # mount salusa:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
    mount.nfs: an incorrect mount option was specified

...with the printk in the ring buffer. Because we *might* eventually
walk down to /mnt/test1/export, the mount is denied due to this patch.
The second mount needs the pseudoroot superblock, but that's already
present with the wrong context.

OTOH, if we mount these in the reverse order, then both mounts work,
because the pseudoroot superblock created when mounting /export is
discarded once that mount is done. If we then however try to walk into
that directory, the automount fails for the similar reasons:

    # cd /mnt/test1/scratch/
    -bash: cd: /mnt/test1/scratch: Device or resource busy

The story I've gotten from the SELinux folks that I've talked to is that
this is desirable behavior. In SELinux-land, mounting the same data
under different contexts is wrong -- there can be only one.

Cc: Steve Dickson <steved@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Acked-by: default avatarEric Paris <eparis@redhat.com>
Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      094f7b69
  27. 14 Jan, 2013 1 commit
    • Paul Moore's avatar
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore authored 
      This patch corrects some problems with LSM/SELinux that were introduced
with the multiqueue patchset.  The problem stems from the fact that the
multiqueue work changed the relationship between the tun device and its
associated socket; before the socket persisted for the life of the
device, however after the multiqueue changes the socket only persisted
for the life of the userspace connection (fd open).  For non-persistent
devices this is not an issue, but for persistent devices this can cause
the tun device to lose its SELinux label.

We correct this problem by adding an opaque LSM security blob to the
tun device struct which allows us to have the LSM security state, e.g.
SELinux labeling information, persist for the lifetime of the tun
device.  In the process we tweak the LSM hooks to work with this new
approach to TUN device/socket labeling and introduce a new LSM hook,
security_tun_dev_attach_queue(), to approve requests to attach to a
TUN queue via TUNSETQUEUE.

The SELinux code has been adjusted to match the new LSM hooks, the
other LSMs do not make use of the LSM TUN controls.  This patch makes
use of the recently added "tun_socket:attach_queue" permission to
restrict access to the TUNSETQUEUE operation.  On older SELinux
policies which do not define the "tun_socket:attach_queue" permission
the access control decision for TUNSETQUEUE will be handled according
to the SELinux policy's unknown permission setting.
Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
Acked-by: default avatarEric Paris <eparis@parisplace.org>
Tested-by: default avatarJason Wang <jasowang@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
  29. 14 Dec, 2012 1 commit
  31. 12 Oct, 2012 1 commit
  33. 25 Sep, 2012 1 commit
  35. 21 Sep, 2012 1 commit
  37. 05 Sep, 2012 1 commit
  39. 10 Aug, 2012 1 commit
  41. 01 Jun, 2012 1 commit
  43. 31 May, 2012 2 commits
  45. 14 Apr, 2012 1 commit
    • Andy Lutomirski's avatar
      Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs · 259e5e6c
      Andy Lutomirski authored 
      With this change, calling
  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
disables privilege granting operations at execve-time.  For example, a
process will not be able to execute a setuid binary to change their uid
or gid if this bit is set.  The same is true for file capabilities.

Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
LSMs respect the requested behavior.

To determine if the NO_NEW_PRIVS bit is set, a task may call
  prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
It returns 1 if set and 0 if it is not set. If any of the arguments are
non-zero, it will return -1 and set errno to -EINVAL.
(PR_SET_NO_NEW_PRIVS behaves similarly.)

This functionality is desired for the proposed seccomp filter patch
series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
system call behavior for itself and its child tasks without being
able to impact the behavior of a more privileged task.

Another potential use is making certain privileged operations
unprivileged.  For example, chroot may be considered "safe" if it cannot
affect privileged tasks.

Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
set and AppArmor is in use.  It is fixed in a subsequent patch.
Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
Signed-off-by: default avatarWill Drewry <wad@chromium.org>
Acked-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarKees Cook <keescook@chromium.org>

v18: updated change desc
v17: using new define values as per 3.4
Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      259e5e6c
  47. 09 Apr, 2012 1 commit
  49. 28 Feb, 2012 1 commit
  51. 13 Feb, 2012 2 commits
  53. 09 Feb, 2012 1 commit
  55. 07 Jan, 2012 1 commit
  57. 05 Jan, 2012 5 commits
    • Eric Paris's avatar
      security: remove the security_netlink_recv hook as it is equivalent to capable() · fd778461
      Eric Paris authored 
      Once upon a time netlink was not sync and we had to get the effective
capabilities from the skb that was being received.  Today we instead get
the capabilities from the current task.  This has rendered the entire
purpose of the hook moot as it is now functionally equivalent to the
capable() call.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      fd778461
    • Eric Paris's avatar
      capabilities: remove all _real_ interfaces · 2920a840
      Eric Paris authored 
      The name security_real_capable and security_real_capable_noaudit just don't
make much sense to me.  Convert them to use security_capable and
security_capable_noaudit.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      2920a840
    • Eric Paris's avatar
      capabilities: introduce security_capable_noaudit · c7eba4a9
      Eric Paris authored 
      Exactly like security_capable except don't audit any denials.  This is for
places where the kernel may make decisions about what to do if a task has a
given capability, but which failing that capability is not a sign of a
security policy violation.  An example is checking if a task has
CAP_SYS_ADMIN to lower it's likelyhood of being killed by the oom killer.
This check is not a security violation if it is denied.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
Acked-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      c7eba4a9
    • Eric Paris's avatar
      capabilities: reverse arguments to security_capable · b7e724d3
      Eric Paris authored 
      security_capable takes ns, cred, cap.  But the LSM capable() hook takes
cred, ns, cap.  The capability helper functions also take cred, ns, cap.
Rather than flip argument order just to flip it back, leave them alone.
Heck, this should be a little faster since argument will be in the right
place!
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      b7e724d3
    • Eric Paris's avatar
      capabilities: remove the task from capable LSM hook entirely · 6a9de491
      Eric Paris authored 
      The capabilities framework is based around credentials, not necessarily the
current task.  Yet we still passed the current task down into LSMs from the
security_capable() LSM hook as if it was a meaningful portion of the security
decision.  This patch removes the 'generic' passing of current and instead
forces individual LSMs to use current explicitly if they think it is
appropriate.  In our case those LSMs are SELinux and AppArmor.

I believe the AppArmor use of current is incorrect, but that is wholely
unrelated to this patch.  This patch does not change what AppArmor does, it
just makes it clear in the AppArmor code that it is doing it.

The SELinux code still uses current in it's audit message, which may also be
wrong and needs further investigation.  Again this is NOT a change, it may
have always been wrong, this patch just makes it clear what is happening.
Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      6a9de491
  59. 04 Jan, 2012 1 commit