From ac5656d8a4cdd93cd2c74355ed12e5617817e0e7 Mon Sep 17 00:00:00 2001 From: Aaron Goidel Date: Mon, 12 Aug 2019 11:20:00 -0400 Subject: fanotify, inotify, dnotify, security: add security hook for fs notifications As of now, setting watches on filesystem objects has, at most, applied a check for read access to the inode, and in the case of fanotify, requires CAP_SYS_ADMIN. No specific security hook or permission check has been provided to control the setting of watches. Using any of inotify, dnotify, or fanotify, it is possible to observe, not only write-like operations, but even read access to a file. Modeling the watch as being merely a read from the file is insufficient for the needs of SELinux. This is due to the fact that read access should not necessarily imply access to information about when another process reads from a file. Furthermore, fanotify watches grant more power to an application in the form of permission events. While notification events are solely, unidirectional (i.e. they only pass information to the receiving application), permission events are blocking. Permission events make a request to the receiving application which will then reply with a decision as to whether or not that action may be completed. This causes the issue of the watching application having the ability to exercise control over the triggering process. Without drawing a distinction within the permission check, the ability to read would imply the greater ability to control an application. Additionally, mount and superblock watches apply to all files within the same mount or superblock. Read access to one file should not necessarily imply the ability to watch all files accessed within a given mount or superblock. In order to solve these issues, a new LSM hook is implemented and has been placed within the system calls for marking filesystem objects with inotify, fanotify, and dnotify watches. These calls to the hook are placed at the point at which the target path has been resolved and are provided with the path struct, the mask of requested notification events, and the type of object on which the mark is being set (inode, superblock, or mount). The mask and obj_type have already been translated into common FS_* values shared by the entirety of the fs notification infrastructure. The path struct is passed rather than just the inode so that the mount is available, particularly for mount watches. This also allows for use of the hook by pathname-based security modules. However, since the hook is intended for use even by inode based security modules, it is not placed under the CONFIG_SECURITY_PATH conditional. Otherwise, the inode-based security modules would need to enable all of the path hooks, even though they do not use any of them. This only provides a hook at the point of setting a watch, and presumes that permission to set a particular watch implies the ability to receive all notification about that object which match the mask. This is all that is required for SELinux. If other security modules require additional hooks or infrastructure to control delivery of notification, these can be added by them. It does not make sense for us to propose hooks for which we have no implementation. The understanding that all notifications received by the requesting application are all strictly of a type for which the application has been granted permission shows that this implementation is sufficient in its coverage. Security modules wishing to provide complete control over fanotify must also implement a security_file_open hook that validates that the access requested by the watching application is authorized. Fanotify has the issue that it returns a file descriptor with the file mode specified during fanotify_init() to the watching process on event. This is already covered by the LSM security_file_open hook if the security module implements checking of the requested file mode there. Otherwise, a watching process can obtain escalated access to a file for which it has not been authorized. The selinux_path_notify hook implementation works by adding five new file permissions: watch, watch_mount, watch_sb, watch_reads, and watch_with_perm (descriptions about which will follow), and one new filesystem permission: watch (which is applied to superblock checks). The hook then decides which subset of these permissions must be held by the requesting application based on the contents of the provided mask and the obj_type. The selinux_file_open hook already checks the requested file mode and therefore ensures that a watching process cannot escalate its access through fanotify. The watch, watch_mount, and watch_sb permissions are the baseline permissions for setting a watch on an object and each are a requirement for any watch to be set on a file, mount, or superblock respectively. It should be noted that having either of the other two permissions (watch_reads and watch_with_perm) does not imply the watch, watch_mount, or watch_sb permission. Superblock watches further require the filesystem watch permission to the superblock. As there is no labeled object in view for mounts, there is no specific check for mount watches beyond watch_mount to the inode. Such a check could be added in the future, if a suitable labeled object existed representing the mount. The watch_reads permission is required to receive notifications from read-exclusive events on filesystem objects. These events include accessing a file for the purpose of reading and closing a file which has been opened read-only. This distinction has been drawn in order to provide a direct indication in the policy for this otherwise not obvious capability. Read access to a file should not necessarily imply the ability to observe read events on a file. Finally, watch_with_perm only applies to fanotify masks since it is the only way to set a mask which allows for the blocking, permission event. This permission is needed for any watch which is of this type. Though fanotify requires CAP_SYS_ADMIN, this is insufficient as it gives implicit trust to root, which we do not do, and does not support least privilege. Signed-off-by: Aaron Goidel Acked-by: Casey Schaufler Acked-by: Jan Kara Signed-off-by: Paul Moore --- include/linux/security.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 659071c2e57c..7d9c1da1f659 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -259,7 +259,8 @@ int security_dentry_create_files_as(struct dentry *dentry, int mode, struct qstr *name, const struct cred *old, struct cred *new); - +int security_path_notify(const struct path *path, u64 mask, + unsigned int obj_type); int security_inode_alloc(struct inode *inode); void security_inode_free(struct inode *inode); int security_inode_init_security(struct inode *inode, struct inode *dir, @@ -387,7 +388,6 @@ int security_ismaclabel(const char *name); int security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen); int security_secctx_to_secid(const char *secdata, u32 seclen, u32 *secid); void security_release_secctx(char *secdata, u32 seclen); - void security_inode_invalidate_secctx(struct inode *inode); int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen); int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen); @@ -621,6 +621,12 @@ static inline int security_move_mount(const struct path *from_path, return 0; } +static inline int security_path_notify(const struct path *path, u64 mask, + unsigned int obj_type) +{ + return 0; +} + static inline int security_inode_alloc(struct inode *inode) { return 0; -- cgit v1.2.3 From e6b1db98cf4d54d9ea59cfcc195f70dc946fdd38 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:37 -0700 Subject: security: Support early LSMs The lockdown module is intended to allow for kernels to be locked down early in boot - sufficiently early that we don't have the ability to kmalloc() yet. Add support for early initialisation of some LSMs, and then add them to the list of names when we do full initialisation later. Early LSMs are initialised in link order and cannot be overridden via boot parameters, and cannot make use of kmalloc() (since the allocator isn't initialised yet). (Fixed by Stephen Rothwell to include a stub to fix builds when !CONFIG_SECURITY) Signed-off-by: Matthew Garrett Acked-by: Kees Cook Acked-by: Casey Schaufler Cc: Stephen Rothwell Signed-off-by: James Morris --- include/linux/security.h | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 659071c2e57c..c5dd90981c98 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -195,6 +195,7 @@ int unregister_lsm_notifier(struct notifier_block *nb); /* prototypes */ extern int security_init(void); +extern int early_security_init(void); /* Security operations */ int security_binder_set_context_mgr(struct task_struct *mgr); @@ -423,6 +424,11 @@ static inline int security_init(void) return 0; } +static inline int early_security_init(void) +{ + return 0; +} + static inline int security_binder_set_context_mgr(struct task_struct *mgr) { return 0; -- cgit v1.2.3 From 9e47d31d6a57b5babaca36d42b0d11b6db6019b7 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:38 -0700 Subject: security: Add a "locked down" LSM hook Add a mechanism to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. Signed-off-by: Matthew Garrett Acked-by: Kees Cook Acked-by: Casey Schaufler Signed-off-by: James Morris --- include/linux/security.h | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index c5dd90981c98..04cf48fab15d 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -77,6 +77,33 @@ enum lsm_event { LSM_POLICY_CHANGE, }; +/* + * These are reasons that can be passed to the security_locked_down() + * LSM hook. Lockdown reasons that protect kernel integrity (ie, the + * ability for userland to modify kernel code) are placed before + * LOCKDOWN_INTEGRITY_MAX. Lockdown reasons that protect kernel + * confidentiality (ie, the ability for userland to extract + * information from the running kernel that would otherwise be + * restricted) are placed before LOCKDOWN_CONFIDENTIALITY_MAX. + * + * LSM authors should note that the semantics of any given lockdown + * reason are not guaranteed to be stable - the same reason may block + * one set of features in one kernel release, and a slightly different + * set of features in a later kernel release. LSMs that seek to expose + * lockdown policy at any level of granularity other than "none", + * "integrity" or "confidentiality" are responsible for either + * ensuring that they expose a consistent level of functionality to + * userland, or ensuring that userland is aware that this is + * potentially a moving target. It is easy to misuse this information + * in a way that could break userspace. Please be careful not to do + * so. + */ +enum lockdown_reason { + LOCKDOWN_NONE, + LOCKDOWN_INTEGRITY_MAX, + LOCKDOWN_CONFIDENTIALITY_MAX, +}; + /* These functions are in security/commoncap.c */ extern int cap_capable(const struct cred *cred, struct user_namespace *ns, int cap, unsigned int opts); @@ -393,6 +420,7 @@ void security_inode_invalidate_secctx(struct inode *inode); int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen); int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen); int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen); +int security_locked_down(enum lockdown_reason what); #else /* CONFIG_SECURITY */ static inline int call_lsm_notifier(enum lsm_event event, void *data) @@ -1210,6 +1238,10 @@ static inline int security_inode_getsecctx(struct inode *inode, void **ctx, u32 { return -EOPNOTSUPP; } +static inline int security_locked_down(enum lockdown_reason what) +{ + return 0; +} #endif /* CONFIG_SECURITY */ #ifdef CONFIG_SECURITY_NETWORK -- cgit v1.2.3 From 000d388ed3bbed745f366ce71b2bb7c2ee70f449 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:39 -0700 Subject: security: Add a static lockdown policy LSM While existing LSMs can be extended to handle lockdown policy, distributions generally want to be able to apply a straightforward static policy. This patch adds a simple LSM that can be configured to reject either integrity or all lockdown queries, and can be configured at runtime (through securityfs), boot time (via a kernel parameter) or build time (via a kconfig option). Based on initial code by David Howells. Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: David Howells Signed-off-by: James Morris --- include/linux/security.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 04cf48fab15d..74787335d9ce 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -97,6 +97,9 @@ enum lsm_event { * potentially a moving target. It is easy to misuse this information * in a way that could break userspace. Please be careful not to do * so. + * + * If you add to this, remember to extend lockdown_reasons in + * security/lockdown/lockdown.c. */ enum lockdown_reason { LOCKDOWN_NONE, -- cgit v1.2.3 From 49fcf732bdae0550721ef73af7c45109ce26b2a9 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:40 -0700 Subject: lockdown: Enforce module signatures if the kernel is locked down If the kernel is locked down, require that all modules have valid signatures that we can verify. I have adjusted the errors generated: (1) If there's no signature (ENODATA) or we can't check it (ENOPKG, ENOKEY), then: (a) If signatures are enforced then EKEYREJECTED is returned. (b) If there's no signature or we can't check it, but the kernel is locked down then EPERM is returned (this is then consistent with other lockdown cases). (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we return the error we got. Note that the X.509 code doesn't check for key expiry as the RTC might not be valid or might not have been transferred to the kernel's clock yet. [Modified by Matthew Garrett to remove the IMA integration. This will be replaced with integration with the IMA architecture policy patchset.] Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: Jessica Yu Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 74787335d9ce..9e8abb60a99f 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -103,6 +103,7 @@ enum lsm_event { */ enum lockdown_reason { LOCKDOWN_NONE, + LOCKDOWN_MODULE_SIGNATURE, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 9b9d8dda1ed72e9bd560ab0ca93d322a9440510e Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:41 -0700 Subject: lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked down Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been locked down to prevent this. Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: x86@kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 9e8abb60a99f..e5dd446ef35b 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -104,6 +104,7 @@ enum lsm_event { enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, + LOCKDOWN_DEV_MEM, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 7d31f4602f8d366072471ca138e4ea7b8edf9be0 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:42 -0700 Subject: kexec_load: Disable at runtime if the kernel is locked down The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation. This does not affect kexec_file_load() syscall which can check for a signature on the image to be booted. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Acked-by: Dave Young Reviewed-by: Kees Cook cc: kexec@lists.infradead.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index e5dd446ef35b..b607a8ac97fe 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -105,6 +105,7 @@ enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, LOCKDOWN_DEV_MEM, + LOCKDOWN_KEXEC, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 38bd94b8a1bd46e6d3d9718c7ff582e4c8ccb440 Mon Sep 17 00:00:00 2001 From: Josh Boyer Date: Mon, 19 Aug 2019 17:17:46 -0700 Subject: hibernate: Disable when the kernel is locked down There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down. Signed-off-by: Josh Boyer Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: rjw@rjwysocki.net Cc: pavel@ucw.cz cc: linux-pm@vger.kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index b607a8ac97fe..80ac7fb27aa9 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -106,6 +106,7 @@ enum lockdown_reason { LOCKDOWN_MODULE_SIGNATURE, LOCKDOWN_DEV_MEM, LOCKDOWN_KEXEC, + LOCKDOWN_HIBERNATION, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From eb627e17727ebeede70697ae1798688b0d328b54 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:47 -0700 Subject: PCI: Lock down BAR access when the kernel is locked down Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Acked-by: Bjorn Helgaas Reviewed-by: Kees Cook cc: linux-pci@vger.kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 80ac7fb27aa9..2b763f0ee352 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -107,6 +107,7 @@ enum lockdown_reason { LOCKDOWN_DEV_MEM, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, + LOCKDOWN_PCI_ACCESS, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 96c4f67293e4cd8b3394adce5a8041a2784e68a3 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:48 -0700 Subject: x86: Lock down IO port access when the kernel is locked down IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: Kees Cook cc: x86@kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 2b763f0ee352..cd93fa5d3c6d 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -108,6 +108,7 @@ enum lockdown_reason { LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, + LOCKDOWN_IOPORT, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 95f5e95f41dff31b2a4566c5a8975c08a49ae4e3 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:49 -0700 Subject: x86/msr: Restrict MSR access when the kernel is locked down Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Acked-by: Kees Cook Reviewed-by: Thomas Gleixner cc: x86@kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index cd93fa5d3c6d..010637a79eac 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -109,6 +109,7 @@ enum lockdown_reason { LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, + LOCKDOWN_MSR, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From f474e1486b78ac15322f8a1cda48a32a1deff9d3 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:17:50 -0700 Subject: ACPI: Limit access to custom_method when the kernel is locked down custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: Kees Cook cc: linux-acpi@vger.kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 010637a79eac..390e39395112 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -110,6 +110,7 @@ enum lockdown_reason { LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, + LOCKDOWN_ACPI_TABLES, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 3f19cad3fa0d0fff18ee126f03a80420ae7bcbc9 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:53 -0700 Subject: lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by: Dominik Brodowski Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 390e39395112..683f0607e6f2 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -111,6 +111,7 @@ enum lockdown_reason { LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, + LOCKDOWN_PCMCIA_CIS, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 794edf30ee6cd088d5f4079b1d4a4cfe5371203e Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:54 -0700 Subject: lockdown: Lock down TIOCSSERIAL Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use the core serial code. All other drivers seem to either ignore attempts to change port/irq or give an error. Reported-by: Greg Kroah-Hartman Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 683f0607e6f2..b4a85badb03a 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -112,6 +112,7 @@ enum lockdown_reason { LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_PCMCIA_CIS, + LOCKDOWN_TIOCSSERIAL, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 20657f66ef52e5005369e4ef539d4cbf01eab10d Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:55 -0700 Subject: lockdown: Lock down module params that specify hardware parameters (eg. ioport) Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by: Alan Cox Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: Jessica Yu Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index b4a85badb03a..1a3404f9c060 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -113,6 +113,7 @@ enum lockdown_reason { LOCKDOWN_ACPI_TABLES, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, + LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 906357f77a077508d160e729f917c5f0a4304f25 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:56 -0700 Subject: x86/mmiotrace: Lock down the testmmiotrace module The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. This is a runtime check rather than buildtime in order to allow configurations where the same kernel may be run in both locked down or permissive modes depending on local policy. Suggested-by: Thomas Gleixner Signed-off-by: David Howells Acked-by: Steven Rostedt (VMware) Reviewed-by: Kees Cook cc: Thomas Gleixner cc: Steven Rostedt cc: Ingo Molnar cc: "H. Peter Anvin" cc: x86@kernel.org Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 1a3404f9c060..d8db7ea4c4bf 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -114,6 +114,7 @@ enum lockdown_reason { LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, + LOCKDOWN_MMIOTRACE, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 02e935bf5b34edcc4cb0dc532dd0e1a1bfb33b51 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:57 -0700 Subject: lockdown: Lock down /proc/kcore Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. This is limited to lockdown confidentiality mode and is still permitted in integrity mode. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index d8db7ea4c4bf..669e8de5299d 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -116,6 +116,7 @@ enum lockdown_reason { LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_INTEGRITY_MAX, + LOCKDOWN_KCORE, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From a94549dd87f5ea4ca50fee493df08a2dc6256b53 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:58 -0700 Subject: lockdown: Lock down tracing and perf kprobes when in confidentiality mode Disallow the creation of perf and ftrace kprobes when the kernel is locked down in confidentiality mode by preventing their registration. This prevents kprobes from being used to access kernel memory to steal crypto data, but continues to allow the use of kprobes from signed modules. Reported-by: Alexei Starovoitov Signed-off-by: David Howells Signed-off-by: Matthew Garrett Acked-by: Masami Hiramatsu Reviewed-by: Kees Cook Cc: Naveen N. Rao Cc: Anil S Keshavamurthy Cc: davem@davemloft.net Cc: Masami Hiramatsu Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 669e8de5299d..0b2529dbf0f4 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -117,6 +117,7 @@ enum lockdown_reason { LOCKDOWN_MMIOTRACE, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_KCORE, + LOCKDOWN_KPROBES, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 9d1f8be5cf42b497a3bddf1d523f2bb142e9318c Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:17:59 -0700 Subject: bpf: Restrict bpf when kernel lockdown is in confidentiality mode bpf_read() and bpf_read_str() could potentially be abused to (eg) allow private keys in kernel memory to be leaked. Disable them if the kernel has been locked down in confidentiality mode. Suggested-by: Alexei Starovoitov Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook cc: netdev@vger.kernel.org cc: Chun-Yi Lee cc: Alexei Starovoitov Cc: Daniel Borkmann Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 0b2529dbf0f4..e604f4c67f03 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -118,6 +118,7 @@ enum lockdown_reason { LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_KCORE, LOCKDOWN_KPROBES, + LOCKDOWN_BPF_READ, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From b0c8fdc7fdb77586c3d1937050925b960743306e Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:18:00 -0700 Subject: lockdown: Lock down perf when in confidentiality mode Disallow the use of certain perf facilities that might allow userspace to access kernel data. Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index e604f4c67f03..b94f1e697537 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -119,6 +119,7 @@ enum lockdown_reason { LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ, + LOCKDOWN_PERF, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3 From 5496197f9b084f086cb410dd566648b0896fcc74 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Aug 2019 17:18:02 -0700 Subject: debugfs: Restrict debugfs when the kernel is locked down Disallow opening of debugfs files that might be used to muck around when the kernel is locked down as various drivers give raw access to hardware through debugfs. Given the effort of auditing all 2000 or so files and manually fixing each one as necessary, I've chosen to apply a heuristic instead. The following changes are made: (1) chmod and chown are disallowed on debugfs objects (though the root dir can be modified by mount and remount, but I'm not worried about that). (2) When the kernel is locked down, only files with the following criteria are permitted to be opened: - The file must have mode 00444 - The file must not have ioctl methods - The file must not have mmap (3) When the kernel is locked down, files may only be opened for reading. Normal device interaction should be done through configfs, sysfs or a miscdev, not debugfs. Note that this makes it unnecessary to specifically lock down show_dsts(), show_devs() and show_call() in the asus-wmi driver. I would actually prefer to lock down all files by default and have the the files unlocked by the creator. This is tricky to manage correctly, though, as there are 19 creation functions and ~1600 call sites (some of them in loops scanning tables). Signed-off-by: David Howells cc: Andy Shevchenko cc: acpi4asus-user@lists.sourceforge.net cc: platform-driver-x86@vger.kernel.org cc: Matthew Garrett cc: Thomas Gleixner Cc: Greg KH Cc: Rafael J. Wysocki Signed-off-by: Matthew Garrett Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index b94f1e697537..152824b6f456 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -115,6 +115,7 @@ enum lockdown_reason { LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, + LOCKDOWN_DEBUGFS, LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_KCORE, LOCKDOWN_KPROBES, -- cgit v1.2.3 From ccbd54ff54e8b1880456b81c4aea352ebe208843 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 19 Aug 2019 17:18:03 -0700 Subject: tracefs: Restrict tracefs when the kernel is locked down Tracefs may release more information about the kernel than desirable, so restrict it when the kernel is locked down in confidentiality mode by preventing open(). (Fixed by Ben Hutchings to avoid a null dereference in default_file_open()) Signed-off-by: Matthew Garrett Reviewed-by: Steven Rostedt (VMware) Cc: Ben Hutchings Signed-off-by: James Morris --- include/linux/security.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux/security.h') diff --git a/include/linux/security.h b/include/linux/security.h index 152824b6f456..429f9f03372b 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -121,6 +121,7 @@ enum lockdown_reason { LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ, LOCKDOWN_PERF, + LOCKDOWN_TRACEFS, LOCKDOWN_CONFIDENTIALITY_MAX, }; -- cgit v1.2.3