UPSTREAM: 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.

Change-Id: Ie70dc489691e2f8413fe593c633a00e6e97bd63a
Signed-off-by: Matthew Garrett <mjg59@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
This commit is contained in:
Matthew Garrett 2019-08-19 17:17:38 -07:00 • committed by Sorayukii
commit 4429a0e046
3 changed files with 46 additions and 0 deletions

View file

@ -1363,6 +1363,11 @@
* @bpf_prog_free_security:
* Clean up the security information stored inside bpf prog.
*
* @locked_down
* Determine whether a kernel feature that potentially enables arbitrary
* code execution in kernel space should be permitted.
*
* @what: kernel feature being accessed
*/
union security_list_options {
@ -1708,6 +1713,7 @@ union security_list_options {
int (*perf_event_write)(struct perf_event *event);
#endif
int (*locked_down)(enum lockdown_reason what);
};
struct security_hook_heads {
@ -1939,6 +1945,7 @@ struct security_hook_heads {
struct hlist_head perf_event_read;
struct hlist_head perf_event_write;
#endif
struct hlist_head locked_down;
};
/*

View file

@ -69,6 +69,33 @@ struct audit_krule;
struct user_namespace;
struct timezone;
/*
* 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, int audit);
@ -377,6 +404,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 */
struct security_mnt_opts {
};
@ -1167,6 +1195,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

View file

@ -1741,3 +1741,10 @@ int security_perf_event_write(struct perf_event *event)
return call_int_hook(perf_event_write, 0, event);
}
#endif /* CONFIG_PERF_EVENTS */
int security_locked_down(enum lockdown_reason what)
{
return call_int_hook(locked_down, 0, what);
}
EXPORT_SYMBOL(security_locked_down);