summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* calipso: Add validation of CALIPSO option.Huw Davies2016-06-273-0/+74
| | | | | | | | | | | Lengths, checksum and the DOI are checked. Checking of the level and categories are left for the socket layer. CRC validation is performed in the calipso module to avoid unconditionally linking crc_ccitt() into ipv6. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Pass a family parameter to netlbl_skbuff_err().Huw Davies2016-06-276-12/+19
| | | | | | | | | | This makes it possible to route the error to the appropriate labelling engine. CALIPSO is far less verbose than CIPSO when encountering a bogus packet, so there is no need for a CALIPSO error handler. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* calipso: Allow the lsm to label the skbuff directly.Huw Davies2016-06-276-4/+308
| | | | | | | | | In some cases, the lsm needs to add the label to the skbuff directly. A NF_INET_LOCAL_OUT IPv6 hook is added to selinux to match the IPv4 behaviour. This allows selinux to label the skbuffs that it requires. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* ipv6: constify the skb pointer of ipv6_find_tlv().Huw Davies2016-06-272-2/+2
| | | | | Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* calipso: Allow request sockets to be relabelled by the lsm.Huw Davies2016-06-276-8/+163
| | | | | | | | | Request sockets need to have a label that takes into account the incoming connection as well as their parent's label. This is used for the outgoing SYN-ACK and for their child full-socket. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* ipv6: Allow request socks to contain IPv6 options.Huw Davies2016-06-274-7/+27
| | | | | | | | | | | | If set, these will take precedence over the parent's options during both sending and child creation. If they're not set, the parent's options (if any) will be used. This is to allow the security_inet_conn_request() hook to modify the IPv6 options in just the same way that it already may do for IPv4. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Prevent setsockopt() from changing the hop-by-hop option.Huw Davies2016-06-271-1/+16
| | | | | | | | | If a socket has a netlabel in place then don't let setsockopt() alter the socket's IPv6 hop-by-hop option. This is in the same spirit as the existing check for IPv4. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* calipso: Set the calipso socket label to match the secattr.Huw Davies2016-06-2710-10/+728
| | | | | | | | | CALIPSO is a hop-by-hop IPv6 option. A lot of this patch is based on the equivalent CISPO code. The main difference is due to manipulating the options in the hop-by-hop header. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Move bitmap manipulation functions to the NetLabel core.Huw Davies2016-06-273-79/+85
| | | | | | | This is to allow the CALIPSO labelling engine to use these. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* ipv6: Add ipv6_renew_options_kern() that accepts a kernel mem pointer.Huw Davies2016-06-272-0/+55
| | | | | | | | | | | | The functionality is equivalent to ipv6_renew_options() except that the newopt pointer is in kernel, not user, memory The kernel memory implementation will be used by the CALIPSO network labelling engine, which needs to be able to set IPv6 hop-by-hop options. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Add support for removing a CALIPSO DOI.Huw Davies2016-06-274-0/+150
| | | | | | | | | Remove a specified DOI through the NLBL_CALIPSO_C_REMOVE command. It requires the attribute: NLBL_CALIPSO_A_DOI. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Add support for creating a CALIPSO protocol domain mapping.Huw Davies2016-06-274-5/+89
| | | | | | | | This extends the NLBL_MGMT_C_ADD and NLBL_MGMT_C_ADDDEF commands to accept CALIPSO protocol DOIs. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Add support for enumerating the CALIPSO DOI list.Huw Davies2016-06-274-0/+165
| | | | | | | | Enumerate the DOI list through the NLBL_CALIPSO_C_LISTALL command. It takes no attributes. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Add support for querying a CALIPSO DOI.Huw Davies2016-06-274-0/+193
| | | | | | | | | | | | Query a specified DOI through the NLBL_CALIPSO_C_LIST command. It requires the attribute: NLBL_CALIPSO_A_DOI. The reply will contain: NLBL_CALIPSO_A_MTYPE Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Initial support for the CALIPSO netlink protocol.Huw Davies2016-06-2712-2/+604
| | | | | | | | | | | | | | | | | | | | | | CALIPSO is a packet labelling protocol for IPv6 which is very similar to CIPSO. It is specified in RFC 5570. Much of the code is based on the current CIPSO code. This adds support for adding passthrough-type CALIPSO DOIs through the NLBL_CALIPSO_C_ADD command. It requires attributes: NLBL_CALIPSO_A_TYPE which must be CALIPSO_MAP_PASS. NLBL_CALIPSO_A_DOI. In passthrough mode the CALIPSO engine will map MLS secattr levels and categories directly to the packet label. At this stage, the major difference between this and the CIPSO code is that IPv6 may be compiled as a module. To allow for this the CALIPSO functions are registered at module init time. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Add an address family to domain hash entries.Huw Davies2016-06-276-58/+192
| | | | | | | | | | | | | | | | | | | | | The reason is to allow different labelling protocols for different address families with the same domain. This requires the addition of an address family attribute in the netlink communication protocol. It is used in several messages: NLBL_MGMT_C_ADD and NLBL_MGMT_C_ADDDEF take it as an optional attribute for the unlabelled protocol. It may be one of AF_INET, AF_INET6 or AF_UNSPEC (to specify both address families). If it is missing, it defaults to AF_UNSPEC. NLBL_MGMT_C_LISTALL and NLBL_MGMT_C_LISTDEF return it as part of the enumeration of each item. Addtionally, it may be sent to LISTDEF to specify which address family to return. Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: Mark rcu pointers with __rcu.Huw Davies2016-06-272-4/+4
| | | | | | | | This fixes sparse errors of the form: incompatible types in comparison expression (different address spaces) Signed-off-by: Huw Davies <huw@codeweavers.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* selinux: fix type mismatchHeinrich Schuchardt2016-06-151-1/+1
| | | | | | | | | avc_cache_threshold is of type unsigned int. Do not use a signed new_value in sscanf(page, "%u", &new_value). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> [PM: subject prefix fix, description cleanup] Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: handle sparse category maps in netlbl_catmap_getlong()Paul Moore2016-06-091-5/+4
| | | | | | | | | | | | In cases where the category bitmap is sparse enough that gaps exist between netlbl_lsm_catmap structs, callers to netlbl_catmap_getlong() could find themselves prematurely ending their search through the category bitmap. Further, the methods used to calculate the 'idx' and 'off' values were incorrect for bitmaps this large. This patch changes the netlbl_catmap_getlong() behavior so that it always skips over gaps and calculates the index and offset values correctly. Signed-off-by: Paul Moore <paul@paul-moore.com>
* selinux: import NetLabel category bitmaps correctlyPaul Moore2016-06-091-1/+1
| | | | | | | | | The existing ebitmap_netlbl_import() code didn't correctly handle the case where the ebitmap_node was not aligned/sized to a power of two, this patch fixes this (on x86_64 ebitmap_node contains six bitmaps making a range of 0..383). Signed-off-by: Paul Moore <paul@paul-moore.com>
* iucv: properly clone LSM attributes to newly created child socketsPaul Moore2016-06-071-1/+4
| | | | | | | | Much like we had to do for AF_BLUETOOTH and AF_ALG, make sure we properly clone the parent socket's LSM attributes to newly created child sockets. Signed-off-by: Paul Moore <paul@paul-moore.com>
* netlabel: add address family checks to netlbl_{sock,req}_delattr()Paul Moore2016-06-061-2/+10
| | | | | | | | | | | | It seems risky to always rely on the caller to ensure the socket's address family is correct before passing it to the NetLabel kAPI, especially since we see at least one LSM which didn't. Add address family checks to the *_delattr() functions to help prevent future problems. Cc: <stable@vger.kernel.org> Reported-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
* selinux: Only apply bounds checking to source typesStephen Smalley2016-05-311-48/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current bounds checking of both source and target types requires allowing any domain that has access to the child domain to also have the same permissions to the parent, which is undesirable. Drop the target bounds checking. KaiGai Kohei originally removed all use of target bounds in commit 7d52a155e38d ("selinux: remove dead code in type_attribute_bounds_av()") but this was reverted in commit 2ae3ba39389b ("selinux: libsepol: remove dead code in check_avtab_hierarchy_callback()") because it would have required explicitly allowing the parent any permissions to the child that the child is allowed to itself. This change in contrast retains the logic for the case where both source and target types are bounded, thereby allowing access if the parent of the source is allowed the corresponding permissions to the parent of the target. Further, this change reworks the logic such that we only perform a single computation for each case and there is no ambiguity as to how to resolve a bounds violation. Under the new logic, if the source type and target types are both bounded, then the parent of the source type must be allowed the same permissions to the parent of the target type. If only the source type is bounded, then the parent of the source type must be allowed the same permissions to the target type. Examples of the new logic and comparisons with the old logic: 1. If we have: typebounds A B; then: allow B self:process <permissions>; will satisfy the bounds constraint iff: allow A self:process <permissions>; is also allowed in policy. Under the old logic, the allow rule on B satisfies the bounds constraint if any of the following three are allowed: allow A B:process <permissions>; or allow B A:process <permissions>; or allow A self:process <permissions>; However, either of the first two ultimately require the third to satisfy the bounds constraint under the old logic, and therefore this degenerates to the same result (but is more efficient - we only need to perform one compute_av call). 2. If we have: typebounds A B; typebounds A_exec B_exec; then: allow B B_exec:file <permissions>; will satisfy the bounds constraint iff: allow A A_exec:file <permissions>; is also allowed in policy. This is essentially the same as #1; it is merely included as an example of dealing with object types related to a bounded domain in a manner that satisfies the bounds relationship. Note that this approach is preferable to leaving B_exec unbounded and having: allow A B_exec:file <permissions>; in policy because that would allow B's entrypoints to be used to enter A. Similarly for _tmp or other related types. 3. If we have: typebounds A B; and an unbounded type T, then: allow B T:file <permissions>; will satisfy the bounds constraint iff: allow A T:file <permissions>; is allowed in policy. The old logic would have been identical for this example. 4. If we have: typebounds A B; and an unbounded domain D, then: allow D B:unix_stream_socket <permissions>; is not subject to any bounds constraints under the new logic because D is not bounded. This is desirable so that we can allow a domain to e.g. connectto a child domain without having to allow it to do the same to its parent. The old logic would have required: allow D A:unix_stream_socket <permissions>; to also be allowed in policy. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> [PM: re-wrapped description to appease checkpatch.pl] Signed-off-by: Paul Moore <paul@paul-moore.com>
* LSM: LoadPin: provide enablement CONFIGKees Cook2016-05-172-6/+15
| | | | | | | | | | | Instead of being enabled by default when SECURITY_LOADPIN is selected, provide an additional (default off) config to determine the boot time behavior. As before, the "loadpin.enabled=0/1" kernel parameter remains available. Suggested-by: James Morris <jmorris@namei.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Merge branch 'stable-4.7' of git://git.infradead.org/users/pcmoore/selinux ↵James Morris2016-05-066-61/+128
|\ | | | | | | into next
| * selinux: apply execstack check on thread stacksStephen Smalley2016-04-261-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The execstack check was only being applied on the main process stack. Thread stacks allocated via mmap were only subject to the execmem permission check. Augment the check to apply to the current thread stack as well. Note that this does NOT prevent making a different thread's stack executable. Suggested-by: Nick Kralevich <nnk@google.com> Acked-by: Nick Kralevich <nnk@google.com> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: distinguish non-init user namespace capability checksStephen Smalley2016-04-262-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Distinguish capability checks against a target associated with the init user namespace versus capability checks against a target associated with a non-init user namespace by defining and using separate security classes for the latter. This is needed to support e.g. Chrome usage of user namespaces for the Chrome sandbox without needing to allow Chrome to also exercise capabilities on targets in the init user namespace. Suggested-by: Dan Walsh <dwalsh@redhat.com> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: check ss_initialized before revalidating an inode labelPaul Moore2016-04-191-1/+1
| | | | | | | | | | | | | | There is no point in trying to revalidate an inode's security label if the security server is not yet initialized. Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: delay inode label lookup as long as possiblePaul Moore2016-04-191-8/+13
| | | | | | | | | | | | | | Since looking up an inode's label can result in revalidation, delay the lookup as long as possible to limit the performance impact. Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: don't revalidate an inode's label when explicitly setting itPaul Moore2016-04-191-2/+11
| | | | | | | | | | | | | | There is no point in attempting to revalidate an inode's security label when we are in the process of setting it. Reported-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: Change bool variable name to index.Prarit Bhargava2016-04-142-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | security_get_bool_value(int bool) argument "bool" conflicts with in-kernel macros such as BUILD_BUG(). This patch changes this to index which isn't a type. Cc: Paul Moore <paul@paul-moore.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Eric Paris <eparis@parisplace.org> Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Andrew Perepechko <anserper@ya.ru> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: selinux@tycho.nsa.gov Cc: Eric Paris <eparis@redhat.com> Cc: Paul Moore <pmoore@redhat.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-by: David Howells <dhowells@redhat.com> [PM: wrapped description for checkpatch.pl, use "selinux:..." as subj] Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: restrict kernel module loadingJeff Vander Stoep2016-04-052-1/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Utilize existing kernel_read_file hook on kernel module load. Add module_load permission to the system class. Enforces restrictions on kernel module origin when calling the finit_module syscall. The hook checks that source type has permission module_load for the target type. Example for finit_module: allow foo bar_file:system module_load; Similarly restrictions are enforced on kernel module loading when calling the init_module syscall. The hook checks that source type has permission module_load with itself as the target object because the kernel module is sourced from the calling process. Example for init_module: allow foo foo:system module_load; Signed-off-by: Jeff Vander Stoep <jeffv@google.com> [PM: fixed return value of selinux_kernel_read_file()] Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: consolidate the ptrace parent lookup codePaul Moore2016-04-051-21/+17
| | | | | | | | | | | | | | We lookup the tracing parent in two places, using effectively the same code, let's consolidate it. Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: simply inode label states to INVALID and INITIALIZEDPaul Moore2016-04-052-4/+3
| | | | | | | | | | | | | | | | | | There really is no need for LABEL_MISSING as we really only care if the inode's label is INVALID or INITIALIZED. Also adjust the revalidate code to reload the label whenever the label is not INITIALIZED so we are less sensitive to label state in the future. Signed-off-by: Paul Moore <paul@paul-moore.com>
| * selinux: don't revalidate inodes in selinux_socket_getpeersec_dgram()Paul Moore2016-04-051-3/+5
| | | | | | | | | | | | | | We don't have to worry about socket inodes being invalidated so use inode_security_novalidate() to fetch the inode's security blob. Signed-off-by: Paul Moore <paul@paul-moore.com>
| * netlabel: fix a problem with netlbl_secattr_catmap_setrng()Janak Desai2016-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | We try to be clever and set large chunks of the bitmap at once, when possible; unfortunately we weren't very clever when we wrote the code and messed up the if-conditional. Fix this bug and restore proper operation. Signed-off-by: Janak Desai <Janak.Desai@gtri.gatech.edu> Signed-off-by: Paul Moore <paul@paul-moore.com>
* | Merge tag 'keys-next-20160505' of ↵James Morris2016-05-0656-717/+1341
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
| * \ Merge branch 'keys-trust' into keys-nextDavid Howells2016-05-0441-517/+673
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a set of patches that changes how certificates/keys are determined to be trusted. That's currently a two-step process: (1) Up until recently, when an X.509 certificate was parsed - no matter the source - it was judged against the keys in .system_keyring, assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set upon them. This has just been changed such that any key in the .ima_mok keyring, if configured, may also be used to judge the trustworthiness of a new certificate, whether or not the .ima_mok keyring is meant to be consulted for whatever process is being undertaken. If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED will be set upon a key it is loaded into (if it is loaded into one), no matter what the key is going to be loaded for. (2) If an X.509 certificate is loaded into a key, then that key - if KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the system keyring only, but has been extended to various IMA keyrings. A user can at will link any key marked KEY_FLAG_TRUSTED into any keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks permit it. These patches change that: (1) Trust becomes a matter of consulting the ring of trusted keys supplied when the trust is evaluated only. (2) Every keyring can be supplied with its own manager function to restrict what may be added to that keyring. This is called whenever a key is to be linked into the keyring to guard against a key being created in one keyring and then linked across. This function is supplied with the keyring and the key type and payload[*] of the key being linked in for use in its evaluation. It is permitted to use other data also, such as the contents of other keyrings such as the system keyrings. [*] The type and payload are supplied instead of a key because as an optimisation this function may be called whilst creating a key and so may reject the proposed key between preparse and allocation. (3) A default manager function is provided that permits keys to be restricted to only asymmetric keys that are vouched for by the contents of the system keyring. A second manager function is provided that just rejects with EPERM. (4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available so that the kernel can initialise keyrings with keys that form the root of the trust relationship. (5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with key_preparsed_payload::trusted. This change also makes it possible in future for userspace to create a private set of trusted keys and then to have it sealed by setting a manager function where the private set is wholly independent of the kernel's trust relationships. Further changes in the set involve extracting certain IMA special keyrings and making them generally global: (*) .system_keyring is renamed to .builtin_trusted_keys and remains read only. It carries only keys built in to the kernel. It may be where UEFI keys should be loaded - though that could better be the new secondary keyring (see below) or a separate UEFI keyring. (*) An optional secondary system keyring (called .secondary_trusted_keys) is added to replace the IMA MOK keyring. (*) Keys can be added to the secondary keyring by root if the keys can be vouched for by either ring of system keys. (*) Module signing and kexec only use .builtin_trusted_keys and do not use the new secondary keyring. (*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as that's the only type currently permitted on the system keyrings. (*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY, is provided to allow keys to be added to IMA keyrings, subject to the restriction that such keys are validly signed by a key already in the system keyrings. If this option is enabled, but secondary keyrings aren't, additions to the IMA keyrings will be restricted to signatures verifiable by keys in the builtin system keyring only. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | IMA: Use the the system trusted keyrings instead of .ima_mokDavid Howells2016-04-115-64/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY) that, when enabled, allows keys to be added to the IMA keyrings by userspace - with the restriction that each must be signed by a key in the system trusted keyrings. EPERM will be returned if this option is disabled, ENOKEY will be returned if no authoritative key can be found and EKEYREJECTED will be returned if the signature doesn't match. Other errors such as ENOPKG may also be returned. If this new option is enabled, the builtin system keyring is searched, as is the secondary system keyring if that is also enabled. Intermediate keys between the builtin system keyring and the key being added can be added to the secondary keyring (which replaces .ima_mok) to form a trust chain - provided they are also validly signed by a key in one of the trusted keyrings. The .ima_mok keyring is then removed and the IMA blacklist keyring gets its own config option (IMA_BLACKLIST_KEYRING). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
| | * | certs: Add a secondary system keyring that can be added to dynamicallyDavid Howells2016-04-113-16/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a secondary system keyring that can be added to by root whilst the system is running - provided the key being added is vouched for by a key built into the kernel or already added to the secondary keyring. Rename .system_keyring to .builtin_trusted_keys to distinguish it more obviously from the new keyring (called .secondary_trusted_keys). The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING. If the secondary keyring is enabled, a link is created from that to .builtin_trusted_keys so that the the latter will automatically be searched too if the secondary keyring is searched. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTEDDavid Howells2016-04-117-59/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer meaningful. Also we can drop the trusted flag from the preparse structure. Given this, we no longer need to pass the key flags through to restrict_link(). Further, we can now get rid of keyring_restrict_trusted_only() also. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Move the point of trust determination to __key_link()David Howells2016-04-119-76/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Make the system trusted keyring depend on the asymmetric key typeDavid Howells2016-04-112-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the system trusted keyring depend on the asymmetric key type as there's not a lot of point having it if you can't then load asymmetric keys onto it. This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to 'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'. Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't work as the Kconfig interpreter then wrongly complains about dependency loops. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | X.509: Move the trust validation code out to its own fileDavid Howells2016-04-114-80/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the X.509 trust validation code out to its own file so that it can be generalised. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | X.509: Use verify_signature() if we have a struct key * to useDavid Howells2016-04-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should call verify_signature() rather than directly calling public_key_verify_signature() if we have a struct key to use as we shouldn't be poking around in the private data of the key struct as that's subtype dependent. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Generalise x509_request_asymmetric_key()David Howells2016-04-115-39/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generalise x509_request_asymmetric_key(). It doesn't really have any dependencies on X.509 features as it uses generalised IDs and the public_key structs that contain data extracted from X.509. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Move x509_request_asymmetric_key() to asymmetric_type.cDavid Howells2016-04-114-95/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be generalised. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Add a facility to restrict new links into a keyringDavid Howells2016-04-1115-52/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a facility whereby proposed new links to be added to a keyring can be vetted, permitting them to be rejected if necessary. This can be used to block public keys from which the signature cannot be verified or for which the signature verification fails. It could also be used to provide blacklisting. This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE. To this end: (1) A function pointer is added to the key struct that, if set, points to the vetting function. This is called as: int (*restrict_link)(struct key *keyring, const struct key_type *key_type, unsigned long key_flags, const union key_payload *key_payload), where 'keyring' will be the keyring being added to, key_type and key_payload will describe the key being added and key_flags[*] can be AND'ed with KEY_FLAG_TRUSTED. [*] This parameter will be removed in a later patch when KEY_FLAG_TRUSTED is removed. The function should return 0 to allow the link to take place or an error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the link. The pointer should not be set directly, but rather should be set through keyring_alloc(). Note that if called during add_key(), preparse is called before this method, but a key isn't actually allocated until after this function is called. (2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to key_create_or_update() or key_instantiate_and_link() to bypass the restriction check. (3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring with this restriction emplaced can be considered 'trustworthy' by virtue of being in the keyring when that keyring is consulted. (4) key_alloc() and keyring_alloc() take an extra argument that will be used to set restrict_link in the new key. This ensures that the pointer is set before the key is published, thus preventing a window of unrestrictedness. Normally this argument will be NULL. (5) As a temporary affair, keyring_restrict_trusted_only() is added. It should be passed to keyring_alloc() as the extra argument instead of setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in a later patch with functions that look in the appropriate places for authoritative keys. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
| | * | PKCS#7: Make trust determination dependent on contents of trust keyringDavid Howells2016-04-069-32/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the determination of the trustworthiness of a key dependent on whether a key that can verify it is present in the supplied ring of trusted keys rather than whether or not the verifying key has KEY_FLAG_TRUSTED set. verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust chain cannot be verified. Signed-off-by: David Howells <dhowells@redhat.com>
| | * | KEYS: Generalise system_verify_data() to provide access to internal contentDavid Howells2016-04-0615-173/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generalise system_verify_data() to provide access to internal content through a callback. This allows all the PKCS#7 stuff to be hidden inside this function and removed from the PE file parser and the PKCS#7 test key. If external content is not required, NULL should be passed as data to the function. If the callback is not required, that can be set to NULL. The function is now called verify_pkcs7_signature() to contrast with verify_pefile_signature() and the definitions of both have been moved into linux/verification.h along with the key_being_used_for enum. Signed-off-by: David Howells <dhowells@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-16 09:22:55 +0100