summaryrefslogtreecommitdiffstats
path: root/Documentation/security
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'docs-for-linus' of git://git.lwn.net/linuxLinus Torvalds2016-05-201-0/+261
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull Documentation updates from Jon Corbet: "A bit busier this time around. The most interesting thing (IMO) this time around is some beginning infrastructural work to allow documents to be written using restructured text. Maybe someday, in a galaxy far far away, we'll be able to eliminate the DocBook dependency and have a much better integrated set of kernel docs. Someday. Beyond that, there's a new document on security hardening from Kees, the movement of some sample code over to samples/, a number of improvements to the serial docs from Geert, and the usual collection of corrections, typo fixes, etc" * tag 'docs-for-linus' of git://git.lwn.net/linux: (55 commits) doc: self-protection: provide initial details serial: doc: Use port->state instead of info serial: doc: Always refer to tty_port->mutex Documentation: vm: Spelling s/paltform/platform/g Documentation/memcg: update kmem limit doc as codes behavior docproc: print a comment about autogeneration for rst output docproc: add support for reStructuredText format via --rst option docproc: abstract terminating lines at first space docproc: abstract docproc directive detection docproc: reduce unnecessary indentation docproc: add variables for subcommand and filename kernel-doc: use rst C domain directives and references for types kernel-doc: produce RestructuredText output kernel-doc: rewrite usage description, remove duplicated comments Doc: correct the location of sysrq.c Documentation: fix common spelling mistakes samples: v4l: from Documentation to samples directory samples: connector: from Documentation to samples directory Documentation: xillybus: fix spelling mistake Documentation: x86: fix spelling mistakes ...
| * doc: self-protection: provide initial detailsKees Cook2016-05-181-0/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | This document attempts to codify the intent around kernel self-protection along with discussion of both existing and desired technologies, with attention given to the rationale behind them, and the expectations of their usage. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> [jc: applied fixes suggested by Randy] Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* | Merge tag 'keys-next-20160505' of ↵James Morris2016-05-061-0/+52
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next
| * \ Merge branch 'keys-trust' into keys-nextDavid Howells2016-05-041-0/+22
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | KEYS: Add a facility to restrict new links into a keyringDavid Howells2016-04-111-0/+22
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * / KEYS: Add KEYCTL_DH_COMPUTE commandMat Martineau2016-04-121-0/+30
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds userspace access to Diffie-Hellman computations through a new keyctl() syscall command to calculate shared secrets or public keys using input parameters stored in the keyring. Input key ids are provided in a struct due to the current 5-arg limit for the keyctl syscall. Only user keys are supported in order to avoid exposing the content of logon or encrypted keys. The output is written to the provided buffer, based on the assumption that the values are only needed in userspace. Future support for other types of key derivation would involve a new command, like KEYCTL_ECDH_COMPUTE. Once Diffie-Hellman support is included in the crypto API, this code can be converted to use the crypto API to take advantage of possible hardware acceleration and reduce redundant code. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David Howells <dhowells@redhat.com>
* / LSM: LoadPin for kernel file loading restrictionsKees Cook2016-04-211-0/+17
|/ | | | | | | | | | | | | This LSM enforces that kernel-loaded files (modules, firmware, etc) must all come from the same filesystem, with the expectation that such a filesystem is backed by a read-only device such as dm-verity or CDROM. This allows systems that have a verified and/or unchangeable filesystem to enforce module and firmware loading restrictions without needing to sign the files individually. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
* keys, trusted: seal with a TPM2 authorization policyJarkko Sakkinen2015-12-201-14/+20
| | | | | | | | | | | | | | | | | | | | | TPM2 supports authorization policies, which are essentially combinational logic statements repsenting the conditions where the data can be unsealed based on the TPM state. This patch enables to use authorization policies to seal trusted keys. Two following new options have been added for trusted keys: * 'policydigest=': provide an auth policy digest for sealing. * 'policyhandle=': provide a policy session handle for unsealing. If 'hash=' option is supplied after 'policydigest=' option, this will result an error because the state of the option would become mixed. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: Peter Huewe <peterhuewe@gmx.de>
* keys, trusted: select hash algorithm for TPM2 chipsJarkko Sakkinen2015-12-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Added 'hash=' option for selecting the hash algorithm for add_key() syscall and documentation for it. Added entry for sm3-256 to the following tables in order to support TPM_ALG_SM3_256: * hash_algo_name * hash_digest_size Includes support for the following hash algorithms: * sha1 * sha256 * sha384 * sha512 * sm3-256 Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: James Morris <james.l.morris@oracle.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: Peter Huewe <peterhuewe@gmx.de>
* KEYS: Merge the type-specific data with the payload dataDavid Howells2015-10-211-16/+25
| | | | | | | | | | | | | | | | | Merge the type-specific data with the payload data into one four-word chunk as it seems pointless to keep them separate. Use user_key_payload() for accessing the payloads of overloaded user-defined keys. Signed-off-by: David Howells <dhowells@redhat.com> cc: linux-cifs@vger.kernel.org cc: ecryptfs@vger.kernel.org cc: linux-ext4@vger.kernel.org cc: linux-f2fs-devel@lists.sourceforge.net cc: linux-nfs@vger.kernel.org cc: ceph-devel@vger.kernel.org cc: linux-ima-devel@lists.sourceforge.net
* Smack: limited capability for changing process labelZbigniew Jasinski2015-10-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature introduces new kernel interface: - <smack_fs>/relabel-self - for setting transition labels list This list is used to control smack label transition mechanism. List is set by, and per process. Process can transit to new label only if label is on the list. Only process with CAP_MAC_ADMIN capability can add labels to this list. With this list, process can change it's label without CAP_MAC_ADMIN but only once. After label changing, list is unset. Changes in v2: * use list_for_each_entry instead of _rcu during label write * added missing description in security/Smack.txt Changes in v3: * squashed into one commit Changes in v4: * switch from global list to per-task list * since the per-task list is accessed only by the task itself there is no need to use synchronization mechanisms on it Changes in v5: * change smackfs interface of relabel-self to the one used for onlycap multiple labels are accepted, separated by space, which replace the previous list upon write Signed-off-by: Zbigniew Jasinski <z.jasinski@samsung.com> Signed-off-by: Rafal Krypa <r.krypa@samsung.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
* Merge branch 'smack-for-4.3' of https://github.com/cschaufler/smack-next ↵James Morris2015-08-111-1/+26
|\ | | | | | | into next
| * Smack: IPv6 host labelingCasey Schaufler2015-07-281-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | IPv6 appears to be (finally) coming of age with the influx of autonomous devices. In support of this, add the ability to associate a Smack label with IPv6 addresses. This patch also cleans up some of the conditional compilation associated with the introduction of secmark processing. It's now more obvious which bit of code goes with which feature. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
* | Yama: remove needless CONFIG_SECURITY_YAMA_STACKEDKees Cook2015-07-281-6/+4Star
|/ | | | | | | | | | | | | Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded config for Yama to be made to explicitly stack. Just selecting the main Yama CONFIG will allow it to work, regardless of the major LSM. Since distros using Yama are already forcing it to stack, this is effectively a no-op change. Additionally add MAINTAINERS entry. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Smack: allow multiple labels in onlycapRafal Krypa2015-06-021-3/+3
| | | | | | | | | | | | Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to processes running with the configured label. But having single privileged label is not enough in some real use cases. On a complex system like Tizen, there maybe few programs that need to configure Smack policy in run-time and running them all with a single label is not always practical. This patch extends onlycap feature for multiple labels. They are configured in the same smackfs "onlycap" interface, separated by spaces. Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
* Smack: Updates for Smack documentationCasey Schaufler2015-03-311-50/+79
| | | | | | | | Document the Smack bringup features. Update the proper location for mounting smackfs from /smack to /sys/fs/smackfs. Fix some spelling errors. Suggest the use of the load2 interface instead of the load interface. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
* KEYS: Make /proc/keys unconditional if CONFIG_KEYS=yDavid Howells2015-01-221-2/+0Star
| | | | | | | | | | Now that /proc/keys is used by libkeyutils to look up a key by type and description, we should make it unconditional and remove CONFIG_DEBUG_PROC_KEYS. Reported-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'next' of ↵James Morris2014-11-191-15/+14Star
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next
| * ima: added support for new kernel cmdline parameter ima_template_fmtRoberto Sassu2014-10-131-15/+14Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows users to provide a custom template format through the new kernel command line parameter 'ima_template_fmt'. If the supplied format is not valid, IMA uses the default template descriptor. Changelog: - v3: - added check for 'fields' and 'num_fields' in template_desc_init_fields() (suggested by Mimi Zohar) - v2: - using template_desc_init_fields() to validate a format string (Roberto Sassu) - updated documentation by stating that only the chosen template descriptor is initialized (Roberto Sassu) - v1: - simplified code of ima_template_fmt_setup() (Roberto Sassu, suggested by Mimi Zohar) Signed-off-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
* | Merge commit 'v3.17' into nextJames Morris2014-11-191-1/+1
|\ \ | |/ |/|
| * Merge branch 'for-linus' of ↵Linus Torvalds2014-08-071-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial tree changes from Jiri Kosina: "Summer edition of trivial tree updates" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (23 commits) doc: fix two typos in watchdog-api.txt irq-gic: remove file name from heading comment MAINTAINERS: Add miscdevice.h to file list for char/misc drivers. scsi: mvsas: mv_sas.c: Fix for possible null pointer dereference doc: replace "practise" with "practice" in Documentation befs: remove check for CONFIG_BEFS_RW scsi: doc: fix 'SCSI_NCR_SETUP_MASTER_PARITY' drivers/usb/phy/phy.c: remove a leading space mfd: fix comment cpuidle: fix comment doc: hpfall.c: fix missing null-terminate after strncpy call usb: doc: hotplug.txt code typos kbuild: fix comment in Makefile.modinst SH: add proper prompt to SH_MAGIC_PANEL_R2_VERSION ARM: msm: Remove MSM_SCM crypto: Remove MPILIB_EXTRA doc: CN: remove dead link, kerneltrap.org no longer works media: update reference, kerneltrap.org no longer works hexagon: update reference, kerneltrap.org no longer works doc: LSM: update reference, kerneltrap.org no longer works ...
| | * doc: LSM: update reference, kerneltrap.org no longer worksPranith Kumar2014-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | | kerneltrap.org no longer works, update to a working reference Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | | KEYS: Update the keyrings documentation for match changesDavid Howells2014-09-161-13/+52
|/ / | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com>
* | KEYS: Call ->free_preparse() even after ->preparse() returns an errorDavid Howells2014-07-221-1/+3
| | | | | | | | | | | | | | | | | | | | 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 <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Acked-by: Jeff Layton <jlayton@primarydata.com> Reviewed-by: Sage Weil <sage@redhat.com>
* | KEYS: Allow expiry time to be set when preparsing a keyDavid Howells2014-07-221-3/+7
| | | | | | | | | | | | | | | | | | Allow a key type's preparsing routine to set the expiry time for a key. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Acked-by: Jeff Layton <jlayton@primarydata.com> Reviewed-by: Sage Weil <sage@redhat.com>
* | Merge branch 'serge-next-1' of ↵Linus Torvalds2014-06-101-0/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security Pull security layer updates from Serge Hallyn: "This is a merge of James Morris' security-next tree from 3.14 to yesterday's master, plus four patches from Paul Moore which are in linux-next, plus one patch from Mimi" * 'serge-next-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security: ima: audit log files opened with O_DIRECT flag selinux: conditionally reschedule in hashtab_insert while loading selinux policy selinux: conditionally reschedule in mls_convert_context while loading selinux policy selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES selinux: Report permissive mode in avc: denied messages. Warning in scanf string typing Smack: Label cgroup files for systemd Smack: Verify read access on file open - v3 security: Convert use of typedef ctl_table to struct ctl_table Smack: bidirectional UDS connect check Smack: Correctly remove SMACK64TRANSMUTE attribute SMACK: Fix handling value==NULL in post setxattr bugfix patch for SMACK Smack: adds smackfs/ptrace interface Smack: unify all ptrace accesses in the smack Smack: fix the subject/object order in smack_ptrace_traceme() Minor improvement of 'smack_sb_kern_mount' smack: fix key permission verification KEYS: Move the flags representing required permission to linux/key.h
| * Smack: adds smackfs/ptrace interfaceLukasz Pawelczyk2014-04-111-0/+10
| | | | | | | | | | | | | | | | | | | | This allows to limit ptrace beyond the regular smack access rules. It adds a smackfs/ptrace interface that allows smack to be configured to require equal smack labels for PTRACE_MODE_ATTACH access. See the changes in Documentation/security/Smack.txt below for details. Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@partner.samsung.com> Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
* | doc: spelling error changesCarlos Garcia2014-05-051-1/+1
| | | | | | | | | | | | | | | | Fixed multiple spelling errors. Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Carlos E. Garcia <carlos@cgarcia.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | doc: fix double wordsMasanari Iida2014-03-211-1/+1
|/ | | | | | | | Fix double words "the the" in various files within Documentations. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* ima: update IMA-templates.txt documentationMimi Zohar2014-01-031-2/+4
| | | | | | | | | | | | | Patch "ima: extend the measurement list to include the file signature" defined a new field called 'sig' and a new template called 'ima-sig'. This patch updates the Documentation/security/IMA-templates.txt. Changelog: - fixed formatting issues (Roberto Sassu) Reported-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
* ima: new templates management mechanismRoberto Sassu2013-10-252-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original 'ima' template is fixed length, containing the filedata hash and pathname. The filedata hash is limited to 20 bytes (md5/sha1). The pathname is a null terminated string, limited to 255 characters. To overcome these limitations and to add additional file metadata, it is necessary to extend the current version of IMA by defining additional templates. The main reason to introduce this feature is that, each time a new template is defined, the functions that generate and display the measurement list would include the code for handling a new format and, thus, would significantly grow over time. This patch set solves this problem by separating the template management from the remaining IMA code. The core of this solution is the definition of two new data structures: a template descriptor, to determine which information should be included in the measurement list, and a template field, to generate and display data of a given type. To define a new template field, developers define the field identifier and implement two functions, init() and show(), respectively to generate and display measurement entries. Initially, this patch set defines the following template fields (support for additional data types will be added later):  - 'd': the digest of the event (i.e. the digest of a measured file),         calculated with the SHA1 or MD5 hash algorithm;  - 'n': the name of the event (i.e. the file name), with size up to         255 bytes;  - 'd-ng': the digest of the event, calculated with an arbitrary hash            algorithm (field format: [<hash algo>:]digest, where the digest            prefix is shown only if the hash algorithm is not SHA1 or MD5);  - 'n-ng': the name of the event, without size limitations. Defining a new template descriptor requires specifying the template format, a string of field identifiers separated by the '|' character. This patch set defines the following template descriptors:  - "ima": its format is 'd|n';  - "ima-ng" (default): its format is 'd-ng|n-ng' Further details about the new template architecture can be found in Documentation/security/IMA-templates.txt. Changelog: - don't defer calling ima_init_template() - Mimi - don't define ima_lookup_template_desc() until used - Mimi - squashed with documentation patch - Mimi Signed-off-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
* KEYS: Define a __key_get() wrapper to use rather than atomic_inc()David Howells2013-09-241-5/+8
| | | | | | | Define a __key_get() wrapper to use rather than atomic_inc() on the key usage count as this makes it easier to hook in refcount error debugging. Signed-off-by: David Howells <dhowells@redhat.com>
* KEYS: Use bool in make_key_ref() and is_key_possessed()David Howells2013-09-241-4/+3Star
| | | | | | | Make make_key_ref() take a bool possession parameter and make is_key_possessed() return a bool. Signed-off-by: David Howells <dhowells@redhat.com>
* Smack: add support for modification of existing rulesRafal Krypa2013-03-191-0/+11
| | | | | | | | | | | | | | | | Rule modifications are enabled via /smack/change-rule. Format is as follows: "Subject Object rwaxt rwaxt" First two strings are subject and object labels up to 255 characters. Third string contains permissions to enable. Fourth string contains permissions to disable. All unmentioned permissions will be left unchanged. If no rule previously existed, it will be created. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
* Documentation: fix Documentation/security/00-INDEXJarkko Sakkinen2012-12-181-0/+2
| | | | | | | | keys-ecryptfs.txt was missing from 00-INDEX. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'modsign-keys-devel' into security-next-keysDavid Howells2012-10-021-1/+49
|\ | | | | | | Signed-off-by: David Howells <dhowells@redhat.com>
| * KEYS: Add payload preparsing opportunity prior to key instantiate or updateDavid Howells2012-09-131-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Give the key type the opportunity to preparse the payload prior to the instantiation and update routines being called. This is done with the provision of two new key type operations: int (*preparse)(struct key_preparsed_payload *prep); void (*free_preparse)(struct key_preparsed_payload *prep); If the first operation is present, then it is called before key creation (in the add/update case) or before the key semaphore is taken (in the update and instantiate cases). The second operation is called to clean up if the first was called. preparse() is given the opportunity to fill in the following structure: struct key_preparsed_payload { char *description; void *type_data[2]; void *payload; const void *data; size_t datalen; size_t quotalen; }; Before the preparser is called, the first three fields will have been cleared, the payload pointer and size will be stored in data and datalen and the default quota size from the key_type struct will be stored into quotalen. The preparser may parse the payload in any way it likes and may store data in the type_data[] and payload fields for use by the instantiate() and update() ops. The preparser may also propose a description for the key by attaching it as a string to the description field. This can be used by passing a NULL or "" description to the add_key() system call or the key_create_or_update() function. This cannot work with request_key() as that required the description to tell the upcall about the key to be created. This, for example permits keys that store PGP public keys to generate their own name from the user ID and public key fingerprint in the key. The instantiate() and update() operations are then modified to look like this: int (*instantiate)(struct key *key, struct key_preparsed_payload *prep); int (*update)(struct key *key, struct key_preparsed_payload *prep); and the new payload data is passed in *prep, whether or not it was preparsed. Signed-off-by: David Howells <dhowells@redhat.com>
* | KEYS: Use keyring_alloc() to create special keyringsDavid Howells2012-10-021-0/+17
| | | | | | | | | | | | | | | | | | Use keyring_alloc() to create special keyrings now that it has a permissions parameter rather than using key_alloc() + key_instantiate_and_link(). Also document and export keyring_alloc() so that modules can use it too. Signed-off-by: David Howells <dhowells@redhat.com>
* | Documentation: Update git repository URL for Smack userland toolsDaniel Wagner2012-09-261-4/+3Star
| | | | | | | | | | | | | | | | | | | | The userland git repository has been moved to a new place. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: Rob Landley <rob@landley.net> Cc: linux-security-module@vger.kernel.org Cc: lkml@vger.kernel.org
* | Smack: implement revoking all rules for a subject labelRafal Krypa2012-09-181-0/+3
|/ | | | | | | | | Add /smack/revoke-subject special file. Writing a SMACK label to this file will set the access to '-' for all access rules with that subject label. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
* Yama: higher restrictions should block PTRACE_TRACEMEKees Cook2012-08-101-7/+7
| | | | | | | | | | | The higher ptrace restriction levels should be blocking even PTRACE_TRACEME requests. The comments in the LSM documentation are misleading about when the checks happen (the parent does not go through security_ptrace_access_check() on a PTRACE_TRACEME call). Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # 3.5.x and later Signed-off-by: James Morris <james.l.morris@oracle.com>
* Smack: allow for significantly longer Smack labels v4Casey Schaufler2012-05-151-40/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V4 updated to current linux-security#next Targeted for git://gitorious.org/smack-next/kernel.git Modern application runtime environments like to use naming schemes that are structured and generated without human intervention. Even though the Smack limit of 23 characters for a label name is perfectly rational for human use there have been complaints that the limit is a problem in environments where names are composed from a set or sources, including vendor, author, distribution channel and application name. Names like softwarehouse-pgwodehouse-coolappstore-mellowmuskrats are becoming harder to avoid. This patch introduces long label support in Smack. Labels are now limited to 255 characters instead of the old 23. The primary reason for limiting the labels to 23 characters was so they could be directly contained in CIPSO category sets. This is still done were possible, but for labels that are too large a mapping is required. This is perfectly safe for communication that stays "on the box" and doesn't require much coordination between boxes beyond what would have been required to keep label names consistent. The bulk of this patch is in smackfs, adding and updating administrative interfaces. Because existing APIs can't be changed new ones that do much the same things as old ones have been introduced. The Smack specific CIPSO data representation has been removed and replaced with the data format used by netlabel. The CIPSO header is now computed when a label is imported rather than on use. This results in improved IP performance. The smack label is now allocated separately from the containing structure, allowing for larger strings. Four new /smack interfaces have been introduced as four of the old interfaces strictly required labels be specified in fixed length arrays. The access interface is supplemented with the check interface: access "Subject Object rwxat" access2 "Subject Object rwaxt" The load interface is supplemented with the rules interface: load "Subject Object rwxat" load2 "Subject Object rwaxt" The load-self interface is supplemented with the self-rules interface: load-self "Subject Object rwxat" load-self2 "Subject Object rwaxt" The cipso interface is supplemented with the wire interface: cipso "Subject lvl cnt c1 c2 ..." cipso2 "Subject lvl cnt c1 c2 ..." The old interfaces are maintained for compatibility. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
* KEYS: Add invalidation supportDavid Howells2012-05-111-0/+17
| | | | | | | | | | | | | | | | | | | Add support for invalidating a key - which renders it immediately invisible to further searches and causes the garbage collector to immediately wake up, remove it from keyrings and then destroy it when it's no longer referenced. It's better not to do this with keyctl_revoke() as that marks the key to start returning -EKEYREVOKED to searches when what is actually desired is to have the key refetched. To invalidate a key the caller must be granted SEARCH permission by the key. This may be too strict. It may be better to also permit invalidation if the caller has any of READ, WRITE or SETATTR permission. The primary use for this is to evict keys that are cached in special keyrings, such as the DNS resolver or an ID mapper. Signed-off-by: David Howells <dhowells@redhat.com>
* Merge tag 'v3.4-rc5' into nextJames Morris2012-05-041-1/+13
|\ | | | | | | | | | | | | | | | | Linux 3.4-rc5 Merge to pull in prerequisite change for Smack: 86812bb0de1a3758dc6c7aa01a763158a7c0638a Requested by Casey.
| * keys: update the documentation with info about "logon" keysJeff Layton2012-04-251-1/+13
| | | | | | | | | | Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com>
* | Yama: add additional ptrace scopesKees Cook2012-04-191-1/+9
|/ | | | | | | | | This expands the available Yama ptrace restrictions to include two more modes. Mode 2 requires CAP_SYS_PTRACE for PTRACE_ATTACH, and mode 3 completely disables PTRACE_ATTACH (and locks the sysctl). Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Merge branch 'next' of ↵Linus Torvalds2012-03-213-0/+71
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull security subsystem updates for 3.4 from James Morris: "The main addition here is the new Yama security module from Kees Cook, which was discussed at the Linux Security Summit last year. Its purpose is to collect miscellaneous DAC security enhancements in one place. This also marks a departure in policy for LSM modules, which were previously limited to being standalone access control systems. Chromium OS is using Yama, and I believe there are plans for Ubuntu, at least. This patchset also includes maintenance updates for AppArmor, TOMOYO and others." Fix trivial conflict in <net/sock.h> due to the jumo_label->static_key rename. * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (38 commits) AppArmor: Fix location of const qualifier on generated string tables TOMOYO: Return error if fails to delete a domain AppArmor: add const qualifiers to string arrays AppArmor: Add ability to load extended policy TOMOYO: Return appropriate value to poll(). AppArmor: Move path failure information into aa_get_name and rename AppArmor: Update dfa matching routines. AppArmor: Minor cleanup of d_namespace_path to consolidate error handling AppArmor: Retrieve the dentry_path for error reporting when path lookup fails AppArmor: Add const qualifiers to generated string tables AppArmor: Fix oops in policy unpack auditing AppArmor: Fix error returned when a path lookup is disconnected KEYS: testing wrong bit for KEY_FLAG_REVOKED TOMOYO: Fix mount flags checking order. security: fix ima kconfig warning AppArmor: Fix the error case for chroot relative path name lookup AppArmor: fix mapping of META_READ to audit and quiet flags AppArmor: Fix underflow in xindex calculation AppArmor: Fix dropping of allowed operations that are force audited AppArmor: Add mising end of structure test to caps unpacking ...
| * Yama: add PR_SET_PTRACER_ANYKees Cook2012-02-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | For a process to entirely disable Yama ptrace restrictions, it can use the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed process may ptrace it. This is stronger than calling PR_SET_PTRACER with pid "1" because it includes processes in external pid namespaces. This is currently needed by the Chrome renderer, since its crash handler (Breakpad) runs external to the renderer's pid namespace. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <jmorris@namei.org>
| * security: Yama LSMKees Cook2012-02-092-0/+62
| | | | | | | | | | | | | | | | | | | | | | This adds the Yama Linux Security Module to collect DAC security improvements (specifically just ptrace restrictions for now) that have existed in various forms over the years and have been carried outside the mainline kernel by other Linux distributions like Openwall and grsecurity. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
| * KEYS: Allow special keyrings to be clearedDavid Howells2012-01-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel contains some special internal keyrings, for instance the DNS resolver keyring : 2a93faf1 I----- 1 perm 1f030000 0 0 keyring .dns_resolver: empty It would occasionally be useful to allow the contents of such keyrings to be flushed by root (cache invalidation). Allow a flag to be set on a keyring to mark that someone possessing the sysadmin capability can clear the keyring, even without normal write access to the keyring. Set this flag on the special keyrings created by the DNS resolver, the NFS identity mapper and the CIFS identity mapper. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Jeff Layton <jlayton@redhat.com> Acked-by: Steve Dickson <steved@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-01 15:41:41 +0100