- 26 Jul, 2014 2 commits
-
-
-
James Morris authored
Merge tag 'keys-next-20140725' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
-
- 25 Jul, 2014 4 commits
-
-
Mimi Zohar authored
The "security: introduce kernel_fw_from_file hook" patch defined a new security hook to evaluate any loaded firmware that wasn't built into the kernel. This patch defines ima_fw_from_file(), which is called from the new security hook, to measure and/or appraise the loaded firmware's integrity. Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Kees Cook authored
This attaches LSM hooks to the existing firmware loading interfaces: filesystem-found firmware and demand-loaded blobs. On errors, loads are aborted and the failure code is returned to userspace. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kees Cook authored
In order to validate the contents of firmware being loaded, there must be a hook to evaluate any loaded firmware that wasn't built into the kernel itself. Without this, there is a risk that a root user could load malicious firmware designed to mount an attack against kernel memory (e.g. via DMA). Signed-off-by:
-
David Howells authored
crypto/asymmetric_keys/pkcs7_key_type.c needs to #include linux/err.h rather than relying on getting it through other headers. Without this, the powerpc allyesconfig build fails. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
David Howells <dhowells@redhat.com>
-
- 24 Jul, 2014 3 commits
-
-
Eric Paris authored
This is effectively a revert of 7b9a7ec5 plus fixing it a different way... We found, when trying to run an application from an application which had dropped privs that the kernel does security checks on undefined capability bits. This was ESPECIALLY difficult to debug as those undefined bits are hidden from /proc/$PID/status. Consider a root application which drops all capabilities from ALL 4 capability sets. We assume, since the application is going to set eff/perm/inh from an array that it will clear not only the defined caps less than CAP_LAST_CAP, but also the higher 28ish bits which are undefined future capabilities. The BSET gets cleared differently. Instead it is cleared one bit at a time. The problem here is that in security/commoncap.c::cap_task_prctl() we actually check the validity of a capability being read. So any task which attempts to 'read all things set in bset' followed by 'unset all things set in bset' will not even attempt to unset the undefined bits higher than CAP_LAST_CAP. So the 'parent' will look something like: CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffc000000000 All of this 'should' be fine. Given that these are undefined bits that aren't supposed to have anything to do with permissions. But they do... So lets now consider a task which cleared the eff/perm/inh completely and cleared all of the valid caps in the bset (but not the invalid caps it couldn't read out of the kernel). We know that this is exactly what the libcap-ng library does and what the go capabilities library does. They both leave you in that above situation if you try to clear all of you capapabilities from all 4 sets. If that root task calls execve() the child task will pick up all caps not blocked by the bset. The bset however does not block bits higher than CAP_LAST_CAP. So now the child task has bits in eff which are not in the parent. These are 'meaningless' undefined bits, but still bits which the parent doesn't have. The problem is now in cred_cap_issubset() (or any operation which does a subset test) as the child, while a subset for valid cap bits, is not a subset for invalid cap bits! So now we set durring commit creds that the child is not dumpable. Given it is 'more priv' than its parent. It also means the parent cannot ptrace the child and other stupidity. The solution here: 1) stop hiding capability bits in status This makes debugging easier! 2) stop giving any task undefined capability bits. it's simple, it you don't put those invalid bits in CAP_FULL_SET you won't get them in init and you won't get them in any other task either. This fixes the cap_issubset() tests and resulting fallout (which made the init task in a docker container untraceable among other things) 3) mask out undefined bits when sys_capset() is called as it might use ~0, ~0 to denote 'all capabilities' for backward/forward compatibility. This lets 'capsh --caps="all=eip" -- -c /bin/bash' run. 4) mask out undefined bit when we read a file capability off of disk as again likely all bits are set in the xattr for forward/backward compatibility. This lets 'setcap all+pe /bin/bash; /bin/bash' run Signed-off-by:
Eric Paris <eparis@redhat.com> Reviewed-by:
James Morris <james.l.morris@oracle.com>
-
James Morris authored
Merge tag 'keys-next-20140722' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
-
Tetsuo Handa authored
In function cap_task_prctl(), we would allocate a credential unconditionally and then check if we support the requested function. If not we would release this credential with abort_creds() by using RCU method. But on some archs such as powerpc, the sys_prctl is heavily used to get/set the floating point exception mode. So the unnecessary allocating/releasing of credential not only introduce runtime overhead but also do cause OOM due to the RCU implementation. This patch removes abort_creds() from cap_task_prctl() by calling prepare_creds() only when we need to modify it. Reported-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
Paul Moore <paul@paul-moore.com> Acked-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Reviewed-by:
-
- 22 Jul, 2014 16 commits
-
-
David Howells authored
Signed-off-by: -
David Howells authored
Signed-off-by: -
David Howells authored
Here's a set of changes that implement a PE file signature checker. This provides the following facility: (1) Extract the signature from the PE file. This is a PKCS#7 message containing, as its data, a hash of the signed parts of the file. (2) Digest the signed parts of the file. (3) Compare the digest with the one from the PKCS#7 message. (4) Validate the signatures on the PKCS#7 message and indicate whether it was matched by a trusted key. Signed-off-by: -
David Howells authored
Here's a set of changes that implement a PKCS#7 message parser in the kernel. The PKCS#7 message parsing will then be used to limit kexec to authenticated kernels only if so configured. The changes provide the following facilities: (1) Parse an ASN.1 PKCS#7 message and pick out useful bits such as the data content and the X.509 certificates used to sign it and all the data signatures. (2) Verify all the data signatures against the set of X.509 certificates available in the message. (3) Follow the certificate chains and verify that: (a) for every self-signed X.509 certificate, check that it validly signed itself, and: (b) for every non-self-signed certificate, if we have a 'parent' certificate, the former is validly signed by the latter. (4) Look for intersections between the certificate chains and the trusted keyring, if any intersections are found, verify that the trusted certificates signed the intersection point in the chain. (5) For testing purposes, a key type can be made available that will take a PKCS#7 message, check that the message is trustworthy, and if so, add its data content into the key. Note that (5) has to be altered to take account of the preparsing patches already committed to this branch. Signed-off-by: -
David Howells authored
Here are a set of changes that make all but encrypted and trusted keys use preparsing. Unfortunately, encrypted and trusted keys incorrectly use the update op to alter a key, so other changes will need to be made for them. These changes permit payload parsing when instantiating or updating a key to be done before locks are taken and to determine the amount of quota that will be required in advance. The latter will make it possible to do LRU discard before any locks are taken. Signed-off-by: -
David Howells authored
Provide key preparsing for the request_key_auth key type so that we can make preparsing mandatory. This does nothing as this type can only be set up internally to the kernel. Signed-off-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com>
-
David Howells authored
Provide key preparsing in the keyring so that we can make preparsing mandatory. For keyrings, however, only an empty payload is permitted. Signed-off-by:
-
David Howells authored
Make use of key preparsing in the big key type so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by:
-
David Howells authored
Make use of key preparsing in the RxRPC protocol so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by:
-
David Howells authored
Make use of key preparsing in the DNS resolver so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by:
-
David Howells authored
Ceph can use user_match() instead of defining its own identical function. Signed-off-by:
Sage Weil <sage@redhat.com> cc: Tommi Virtanen <tommi.virtanen@dreamhost.com>
-
David Howells authored
Make use of key preparsing in Ceph so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by:
-
David Howells authored
Make use of key preparsing in user-defined and logon keys so that quota size determination can take place prior to keyring locking when a key is being added. Also the idmapper key types need to change to match as they use the user-defined key type routines. Signed-off-by:
-
David Howells authored
Call the ->free_preparse() key type op even after ->preparse() returns an error as it does cleaning up type stuff. Signed-off-by:
-
David Howells authored
Allow a key type's preparsing routine to set the expiry time for a key. Signed-off-by:
-
David Howells authored
struct key_preparsed_payload should have two payload pointers to correspond with those in struct key. Signed-off-by:
-
- 19 Jul, 2014 2 commits
-
-
- 18 Jul, 2014 13 commits
-
-
Kees Cook authored
Applying restrictive seccomp filter programs to large or diverse codebases often requires handling threads which may be started early in the process lifetime (e.g., by code that is linked in). While it is possible to apply permissive programs prior to process start up, it is difficult to further restrict the kernel ABI to those threads after that point. This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for synchronizing thread group seccomp filters at filter installation time. When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, filter) an attempt will be made to synchronize all threads in current's threadgroup to its new seccomp filter program. This is possible iff all threads are using a filter that is an ancestor to the filter current is attempting to synchronize to. NULL filters (where the task is running as SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS, ...) has been set on the calling thread, no_new_privs will be set for all synchronized threads too. On success, 0 is returned. On failure, the pid of one of the failing threads will be returned and no filters will have been applied. The race conditions against another thread are: - requesting TSYNC (already handled by sighand lock) - performing a clone (already handled by sighand lock) - changing its filter (already handled by sighand lock) - calling exec (handled by cred_guard_mutex) The clone case is assisted by the fact that new threads will have their seccomp state duplicated from their parent before appearing on the tasklist. Holding cred_guard_mutex means that seccomp filters cannot be assigned while in the middle of another thread's exec (potentially bypassing no_new_privs or similar). The call to de_thread() may kill threads waiting for the mutex. Changes across threads to the filter pointer includes a barrier. Based on patches by Will Drewry. Suggested-by:
Julien Tinnes <jln@chromium.org> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Andy Lutomirski <luto@amacapital.net>
-
Kees Cook authored
This changes the mode setting helper to allow threads to change the seccomp mode from another thread. We must maintain barriers to keep TIF_SECCOMP synchronized with the rest of the seccomp state. Signed-off-by:
-
Kees Cook authored
Normally, task_struct.seccomp.filter is only ever read or modified by the task that owns it (current). This property aids in fast access during system call filtering as read access is lockless. Updating the pointer from another task, however, opens up race conditions. To allow cross-thread filter pointer updates, writes to the seccomp fields are now protected by the sighand spinlock (which is shared by all threads in the thread group). Read access remains lockless because pointer updates themselves are atomic. However, writes (or cloning) often entail additional checking (like maximum instruction counts) which require locking to perform safely. In the case of cloning threads, the child is invisible to the system until it enters the task list. To make sure a child can't be cloned from a thread and left in a prior state, seccomp duplication is additionally moved under the sighand lock. Then parent and child are certain have the same seccomp state when they exit the lock. Based on patches by Will Drewry and David Drysdale. Signed-off-by:
-
Kees Cook authored
In preparation for adding seccomp locking, move filter creation away from where it is checked and applied. This will allow for locking where no memory allocation is happening. The validation, filter attachment, and seccomp mode setting can all happen under the future locks. For extreme defensiveness, I've added a BUG_ON check for the calculated size of the buffer allocation in case BPF_MAXINSN ever changes, which shouldn't ever happen. The compiler should actually optimize out this check since the test above it makes it impossible. Signed-off-by:
-
Kees Cook authored
Since seccomp transitions between threads requires updates to the no_new_privs flag to be atomic, the flag must be part of an atomic flag set. This moves the nnp flag into a separate task field, and introduces accessors. Signed-off-by:
-
Kees Cook authored
Wires up the new seccomp syscall. Signed-off-by:
-
Kees Cook authored
Wires up the new seccomp syscall. Signed-off-by:
-
Kees Cook authored
This adds the new "seccomp" syscall with both an "operation" and "flags" parameter for future expansion. The third argument is a pointer value, used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...). In addition to the TSYNC flag later in this patch series, there is a non-zero chance that this syscall could be used for configuring a fixed argument area for seccomp-tracer-aware processes to pass syscall arguments in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter" for this syscall. Additionally, this syscall uses operation, flags, and user pointer for arguments because strictly passing arguments via a user pointer would mean seccomp itself would be unable to trivially filter the seccomp syscall itself. Signed-off-by:
-
Kees Cook authored
Separates the two mode setting paths to make things more readable with fewer #ifdefs within function bodies. Signed-off-by:
-
Kees Cook authored
To support splitting mode 1 from mode 2, extract the mode checking and assignment logic into common functions. Signed-off-by:
-
Kees Cook authored
In preparation for having other callers of the seccomp mode setting logic, split the prctl entry point away from the core logic that performs seccomp mode setting. Signed-off-by:
-
Kees Cook authored
Add myself as seccomp maintainer. Suggested-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
David Howells authored
Provide a generic instantiation function for key types that use the preparse hook. This makes it easier to prereserve key quota before keyrings get locked to retain the new key. Signed-off-by:
-
