14 Jun, 2018
1 commit
-
The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.HOWEVER.
It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look likeCONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_STACKPROTECTOR_AUTO=yand when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_HAS_SANE_STACKPROTECTOR=yThat's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one. This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_CC_HAS_SANE_STACKPROTECTOR=ywhere the "CC_" versions really are about internal compiler
infrastructure, not the user selections.Acked-by: Masahiro Yamada
Signed-off-by: Linus Torvalds
08 May, 2018
1 commit
-
A number of new docs were added, but they're currently not on
the index.rst from the session they're supposed to be, causing
Sphinx warnings.Add them.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Jonathan Corbet
21 Mar, 2018
1 commit
-
Update SELinux-sctp.rst "SCTP Peer Labeling" section to reflect
how the association permission is validated.Reported-by: Dominick Grift
Signed-off-by: Richard Haines
Signed-off-by: Paul Moore
27 Feb, 2018
1 commit
-
The SELinux SCTP implementation is explained in:
Documentation/security/SELinux-sctp.rstSigned-off-by: Richard Haines
Signed-off-by: Paul Moore
23 Feb, 2018
1 commit
-
The SCTP security hooks are explained in:
Documentation/security/LSM-sctp.rstSigned-off-by: Richard Haines
Signed-off-by: Paul Moore
09 Jan, 2018
1 commit
-
This patch updates the documentation with the observations that led
to commit bdcf0a423ea1 ("kernel: make groups_sort calling a
responsibility group_info allocators") and the new behaviour required.
Specifically that groups_sort() should be called on a new group_list
before set_groups() or set_current_groups() is called.Signed-off-by: NeilBrown
[jc: use proper :c:func: references]
Signed-off-by: Jonathan Corbet
22 Dec, 2017
1 commit
-
Hashing addresses printed with printk specifier %p was implemented
recently. During development a number of issues were raised regarding
leaking kernel addresses to userspace. Other documentation was updated but
security/self-protection missed out.Add self-protection documentation regarding printing kernel addresses.
Signed-off-by: Tobin C. Harding
Signed-off-by: Jonathan Corbet
16 Nov, 2017
1 commit
-
When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent. Some key types will fill as much of the buffer as
possible, while others won't copy anything. Moreover, the in-kernel
documentation contradicted the man page on this point.Update the in-kernel documentation to say that this point is
unspecified.Signed-off-by: Eric Biggers
Signed-off-by: David Howells
13 Oct, 2017
1 commit
-
Make security document refs valid.
Signed-off-by: Tom Saeger
Signed-off-by: Jonathan Corbet
31 Aug, 2017
1 commit
-
Sphinx will now generate the table of contents automatically, which
avoids having the ToC getting out of sync with the rest of the document.Signed-off-by: Josh Holland
Signed-off-by: Jonathan Corbet
25 Aug, 2017
1 commit
-
Several paths in the security/keys documentation were incorrect.
Signed-off-by: Josh Holland
Signed-off-by: Jonathan Corbet
14 Jul, 2017
1 commit
-
Provide more specific examples of keyring restrictions as applied to
X.509 signature chain verification.Signed-off-by: Mat Martineau
Signed-off-by: David Howells
Signed-off-by: James Morris
19 May, 2017
15 commits
-
The white space in the big enumerated list was inconsistent, leading to
some strange formatting artifacts.Signed-off-by: Jonathan Corbet
-
Adjusts for ReST markup and moves under keys security devel index.
Cc: David Howells
Cc: Mimi Zohar
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under keys security devel index.
Cc: David Howells
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under keys security devel index.
Cc: David Howells
Cc: Tyler Hicks
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
This creates a new section in the security development index for kernel
keys, and adjusts for ReST markup.Cc: David Howells
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Acked-by: Casey Schaufler
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Cc: Tetsuo Handa
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Acked-by: John Johansen
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjusts for ReST markup and moves under LSM admin guide.
Cc: Paul Moore
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
The existing LSM.txt file covered both usage and development, so split
this into two files, one under admin-guide and one under kernel
development.Cc: James Morris
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
This updates the credentials API documentation to ReST markup and moves
it under the security subsection of kernel API documentation.Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
This updates the credentials API documentation to ReST markup and moves
it under the security subsection of kernel API documentation.Cc: David Howells
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet -
Adjust IMA-templates.txt for ReST markup and add to the index for
security/, under the Kernel API Documentation.Cc: Mimi Zohar
Signed-off-by: Kees Cook
Signed-off-by: Jonathan Corbet
05 Apr, 2017
4 commits
-
SP800-56A defines the use of DH with key derivation function based on a
counter. The input to the KDF is defined as (DH shared secret || other
information). The value for the "other information" is to be provided by
the caller.The KDF is implemented using the hash support from the kernel crypto API.
The implementation uses the symmetric hash support as the input to the
hash operation is usually very small. The caller is allowed to specify
the hash name that he wants to use to derive the key material allowing
the use of all supported hashes provided with the kernel crypto API.As the KDF implements the proper truncation of the DH shared secret to
the requested size, this patch fills the caller buffer up to its size.The patch is tested with a new test added to the keyutils user space
code which uses a CAVS test vector testing the compliance with
SP800-56A.Signed-off-by: Stephan Mueller
Signed-off-by: David Howells -
Keyrings recently gained restrict_link capabilities that allow
individual keys to be validated prior to linking. This functionality
was only available using internal kernel APIs.With the KEYCTL_RESTRICT_KEYRING command existing keyrings can be
configured to check the content of keys before they are linked, and
then allow or disallow linkage of that key to the keyring.To restrict a keyring, call:
keyctl(KEYCTL_RESTRICT_KEYRING, key_serial_t keyring, const char *type,
const char *restriction)where 'type' is the name of a registered key type and 'restriction' is a
string describing how key linkage is to be restricted. The restriction
option syntax is specific to each key type.Signed-off-by: Mat Martineau
-
The restrict_link functions used to validate keys as they are linked
to a keyring can be associated with specific key types. Each key type
may be loaded (or not) at runtime, so lookup of restrict_link
functions needs to be part of the key type implementation to ensure
that the requested keys can be examined.Signed-off-by: Mat Martineau
-
Replace struct key's restrict_link function pointer with a pointer to
the new struct key_restriction. The structure contains pointers to the
restriction function as well as relevant data for evaluating the
restriction.The garbage collector checks restrict_link->keytype when key types are
unregistered. Restrictions involving a removed key type are converted
to use restrict_link_reject so that restrictions cannot be removed by
unregistering key types.Signed-off-by: Mat Martineau
04 Apr, 2017
2 commits
-
The first argument to the restrict_link_func_t functions was a keyring
pointer. These functions are called by the key subsystem with this
argument set to the destination keyring, but restrict_link_by_signature
expects a pointer to the relevant trusted keyring.Restrict functions may need something other than a single struct key
pointer to allow or reject key linkage, so the data used to make that
decision (such as the trust keyring) is moved to a new, fourth
argument. The first argument is now always the destination keyring.Signed-off-by: Mat Martineau
-
This pointer type needs to be returned from a lookup function, and
without a typedef the syntax gets cumbersome.Signed-off-by: Mat Martineau
02 Mar, 2017
1 commit
-
rcu_dereference_key() and user_key_payload() are currently being used in
two different, incompatible ways:(1) As a wrapper to rcu_dereference() - when only the RCU read lock used
to protect the key.(2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
used to protect the key and the may be being modified.Fix this by splitting both of the key wrappers to produce:
(1) RCU accessors for keys when caller has the key semaphore locked:
dereference_key_locked()
user_key_payload_locked()(2) RCU accessors for keys when caller holds the RCU read lock:
dereference_key_rcu()
user_key_payload_rcu()This should fix following warning in the NFS idmapper
===============================
[ INFO: suspicious RCU usage. ]
4.10.0 #1 Tainted: G W
-------------------------------
./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by mount.nfs/5987:
#0: (rcu_read_lock){......}, at: [] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
stack backtrace:
CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G W 4.10.0 #1
Call Trace:
dump_stack+0xe8/0x154 (unreliable)
lockdep_rcu_suspicious+0x140/0x190
nfs_idmap_get_key+0x380/0x420 [nfsv4]
nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
call_decode+0x29c/0x910 [sunrpc]
__rpc_execute+0x140/0x8f0 [sunrpc]
rpc_run_task+0x170/0x200 [sunrpc]
nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
_nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
nfs4_lookup_root+0xe0/0x350 [nfsv4]
nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
nfs4_find_root_sec+0xc4/0x100 [nfsv4]
nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
nfs4_get_rootfh+0x6c/0x190 [nfsv4]
nfs4_server_common_setup+0xc4/0x260 [nfsv4]
nfs4_create_server+0x278/0x3c0 [nfsv4]
nfs4_remote_mount+0x50/0xb0 [nfsv4]
mount_fs+0x74/0x210
vfs_kern_mount+0x78/0x220
nfs_do_root_mount+0xb0/0x140 [nfsv4]
nfs4_try_mount+0x60/0x100 [nfsv4]
nfs_fs_mount+0x5ec/0xda0 [nfs]
mount_fs+0x74/0x210
vfs_kern_mount+0x78/0x220
do_mount+0x254/0xf70
SyS_mount+0x94/0x100
system_call+0x38/0xe0Reported-by: Jan Stancek
Signed-off-by: David Howells
Tested-by: Jan Stancek
Signed-off-by: James Morris
22 Feb, 2017
1 commit
-
Pull rodata updates from Kees Cook:
"This renames the (now inaccurate) DEBUG_RODATA and related
SET_MODULE_RONX configs to the more sensible STRICT_KERNEL_RWX and
STRICT_MODULE_RWX"* tag 'rodata-v4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
08 Feb, 2017
2 commits
-
Both of these options are poorly named. The features they provide are
necessary for system security and should not be considered debug only.
Change the names to CONFIG_STRICT_KERNEL_RWX and
CONFIG_STRICT_MODULE_RWX to better describe what these options do.Signed-off-by: Laura Abbott
Acked-by: Jessica Yu
Signed-off-by: Kees Cook -
There are multiple architectures that support CONFIG_DEBUG_RODATA and
CONFIG_SET_MODULE_RONX. These options also now have the ability to be
turned off at runtime. Move these to an architecture independent
location and make these options def_bool y for almost all of those
arches.Signed-off-by: Laura Abbott
Acked-by: Ingo Molnar
Acked-by: Heiko Carstens
Signed-off-by: Kees Cook
19 Jan, 2017
1 commit
-
I am still tired of having to find indirect ways to determine
what security modules are active on a system. I have added
/sys/kernel/security/lsm, which contains a comma separated
list of the active security modules. No more groping around
in /proc/filesystems or other clever hacks.Unchanged from previous versions except for being updated
to the latest security next branch.Signed-off-by: Casey Schaufler
Acked-by: John Johansen
Acked-by: Paul Moore
Acked-by: Kees Cook
Signed-off-by: James Morris
15 Dec, 2016
1 commit
-
Pull security subsystem updates from James Morris:
"Generally pretty quiet for this release. Highlights:Yama:
- allow ptrace access for original parent after re-parentingTPM:
- add documentation
- many bugfixes & cleanups
- define a generic open() method for ascii & bios measurementsIntegrity:
- Harden against malformed xattrsSELinux:
- bugfixes & cleanupsSmack:
- Remove unnecessary smack_known_invalid label
- Do not apply star label in smack_setprocattr hook
- parse mnt opts after privileges check (fixes unpriv DoS vuln)"* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (56 commits)
Yama: allow access for the current ptrace parent
tpm: adjust return value of tpm_read_log
tpm: vtpm_proxy: conditionally call tpm_chip_unregister
tpm: Fix handling of missing event log
tpm: Check the bios_dir entry for NULL before accessing it
tpm: return -ENODEV if np is not set
tpm: cleanup of printk error messages
tpm: replace of_find_node_by_name() with dev of_node property
tpm: redefine read_log() to handle ACPI/OF at runtime
tpm: fix the missing .owner in tpm_bios_measurements_ops
tpm: have event log use the tpm_chip
tpm: drop tpm1_chip_register(/unregister)
tpm: replace dynamically allocated bios_dir with a static array
tpm: replace symbolic permission with octal for securityfs files
char: tpm: fix kerneldoc tpm2_unseal_trusted name typo
tpm_tis: Allow tpm_tis to be bound using DT
tpm, tpm_vtpm_proxy: add kdoc comments for VTPM_PROXY_IOC_NEW_DEV
tpm: Only call pm_runtime_get_sync if device has a parent
tpm: define a generic open() method for ascii & bios measurements
Documentation: tpm: add the Physical TPM device tree binding documentation
...
17 Nov, 2016
1 commit
-
There were a few manuals that weren't being built in PDF format, but
there's no reason not to...Signed-off-by: Jonathan Corbet