- 24 7月, 2014 3 次提交
-
-
由 Eric Paris 提交于
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: NEric Paris <eparis@redhat.com> Reviewed-by: NKees Cook <keescook@chromium.org> Cc: Andrew Vagin <avagin@openvz.org> Cc: Andrew G. Morgan <morgan@kernel.org> Cc: Serge E. Hallyn <serge.hallyn@canonical.com> Cc: Kees Cook <keescook@chromium.org> Cc: Steve Grubb <sgrubb@redhat.com> Cc: Dan Walsh <dwalsh@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
由 James Morris 提交于
Merge tag 'keys-next-20140722' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
-
由 Tetsuo Handa 提交于
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: NKevin Hao <haokexin@gmail.com> Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: NPaul Moore <paul@paul-moore.com> Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com> Reviewed-by: NKees Cook <keescook@chromium.org> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 23 7月, 2014 16 次提交
-
-
由 David Howells 提交于
Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com>
-
由 David Howells 提交于
Ceph can use user_match() instead of defining its own identical function. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Reviewed-by: NSage Weil <sage@redhat.com> cc: Tommi Virtanen <tommi.virtanen@dreamhost.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Reviewed-by: NSage Weil <sage@redhat.com> cc: Tommi Virtanen <tommi.virtanen@dreamhost.com>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com>
-
由 David Howells 提交于
Call the ->free_preparse() key type op even after ->preparse() returns an error as it does cleaning up type stuff. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com> Reviewed-by: NSage Weil <sage@redhat.com>
-
由 David Howells 提交于
Allow a key type's preparsing routine to set the expiry time for a key. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com> Reviewed-by: NSage Weil <sage@redhat.com>
-
由 David Howells 提交于
struct key_preparsed_payload should have two payload pointers to correspond with those in struct key. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com> Reviewed-by: NSage Weil <sage@redhat.com>
-
- 19 7月, 2014 15 次提交
-
-
-
由 Kees Cook 提交于
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: NJulien Tinnes <jln@chromium.org> Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
Wires up the new seccomp syscall. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com>
-
由 Kees Cook 提交于
Wires up the new seccomp syscall. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
Separates the two mode setting paths to make things more readable with fewer #ifdefs within function bodies. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
To support splitting mode 1 from mode 2, extract the mode checking and assignment logic into common functions. Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Reviewed-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Kees Cook 提交于
Add myself as seccomp maintainer. Suggested-by: NJames Morris <jmorris@namei.org> Signed-off-by: NKees Cook <keescook@chromium.org>
-
由 David Howells 提交于
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: NDavid Howells <dhowells@redhat.com> Acked-by: NSteve Dickson <steved@redhat.com> Acked-by: NJeff Layton <jlayton@primarydata.com> Reviewed-by: NSage Weil <sage@redhat.com>
- 18 7月, 2014 3 次提交
-
-
由 Dmitry Kasatkin 提交于
When SIGNATURE=y but depends on CRYPTO=m, it selects MPILIB as module producing build break. This patch makes digsig to select crypto for correcting dependency. Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
由 Jean Delvare 提交于
You can select MPILIB_EXTRA all you want, it doesn't exist ;-) Surprised kconfig doesn't complain about that... Signed-off-by: NJean Delvare <jdelvare@suse.de> Acked-by: NMarek Vasut <marex@denx.de> Signed-off-by: NDavid Howells <dhowells@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net>
-
由 David Howells 提交于
Special kernel keys, such as those used to hold DNS results for AFS, CIFS and NFS and those used to hold idmapper results for NFS, used to be 'invalidateable' with key_revoke(). However, since the default permissions for keys were reduced: Commit: 96b5c8fe KEYS: Reduce initial permissions on keys it has become impossible to do this. Add a key flag (KEY_FLAG_ROOT_CAN_INVAL) that will permit a key to be invalidated by root. This should not be used for system keyrings as the garbage collector will try and remove any invalidate key. For system keyrings, KEY_FLAG_ROOT_CAN_CLEAR can be used instead. After this, from userspace, keyctl_invalidate() and "keyctl invalidate" can be used by any possessor of CAP_SYS_ADMIN (typically root) to invalidate DNS and idmapper keys. Invalidated keys are immediately garbage collected and will be immediately rerequested if needed again. Signed-off-by: NDavid Howells <dhowells@redhat.com> Tested-by: NSteve Dickson <steved@redhat.com>
-
- 17 7月, 2014 3 次提交
-
-
由 Mimi Zohar 提交于
Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Acked-by: NDavid Howells <dhowells@redhat.com>
-
由 Dmitry Kasatkin 提交于
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed only by builtin keys on the system keyring. This patch defines a new option 'builtin' for the kernel parameter 'keys_ownerid' to allow trust validation using builtin keys. Simplified Mimi's "KEYS: define an owner trusted keyring" patch Changelog v7: - rename builtin_keys to use_builtin_keys Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Dmitry Kasatkin 提交于
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring. This patch defines a new kernel parameter 'ca_keys' to identify the specific key which must be used for trust validation of certificates. Simplified Mimi's "KEYS: define an owner trusted keyring" patch. Changelog: - support for builtin x509 public keys only - export "asymmetric_keyid_match" - remove ifndefs MODULE - rename kernel boot parameter from keys_ownerid to ca_keys Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-