> -----Original Message----- > From: Tim Chen [mailto:tim.c.c...@linux.intel.com] > Sent: Tuesday, October 30, 2018 11:49 AM > To: Jiri Kosina <ji...@kernel.org>; Thomas Gleixner <t...@linutronix.de> > Cc: Tim Chen <tim.c.c...@linux.intel.com>; Tom Lendacky > <thomas.lenda...@amd.com>; Ingo Molnar <mi...@redhat.com>; Peter > Zijlstra <pet...@infradead.org>; Josh Poimboeuf <jpoim...@redhat.com>; > Andrea Arcangeli <aarca...@redhat.com>; David Woodhouse > <d...@amazon.co.uk>; Andi Kleen <a...@linux.intel.com>; Hansen, Dave > <dave.han...@intel.com>; Schaufler, Casey <casey.schauf...@intel.com>; > Mallick, Asit K <asit.k.mall...@intel.com>; Arjan van de Ven > <ar...@linux.intel.com>; Jon Masters <j...@redhat.com>; Waiman Long > <longman9...@gmail.com>; linux-kernel@vger.kernel.org; x...@kernel.org
Added LSM mail list to the CC: > Subject: [Patch v4 13/18] security: Update security level of a process when > modifying its dumpability "Level" isn't a good description of security characteristics as it has been overloaded in too many ways already. More on that later. > When a process is made non-dumpable, the action implies a higher level > of security implicitly as its memory is imposed with access restriction. How is this "higher level" manifest? > A call to update_process_security() is added to update security defenses > according to a process's dumpability and its implied security level. Can you describe the set of security attributes that are implied by the process' dumpability? I would think that the dumpability would be an artifact of these attributes, not the other way around. > Architecture specific defenses is erected for threads in the process nit: s/is/are/ > by calling arch_set_security(task, SECURITY_LEVEL_HIGH) or the defenses > relaxed via arch_set_security(task, SECURITY_LEVEL_NORMAL). Such defenses > may incur extra overhead and is reserved for tasks needing high security. nit: s/is/are/ > Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com> > --- > fs/exec.c | 2 ++ > include/linux/security.h | 6 ++++++ > kernel/cred.c | 5 ++++- > kernel/sys.c | 1 + > security/security.c | 31 +++++++++++++++++++++++++++++++ > 5 files changed, 44 insertions(+), 1 deletion(-) > > diff --git a/fs/exec.c b/fs/exec.c > index 1ebf6e5..e70c8a7 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1366,6 +1366,8 @@ void setup_new_exec(struct linux_binprm * bprm) > else > set_dumpable(current->mm, SUID_DUMP_USER); > > + update_process_security(current); > + > arch_setup_new_exec(); > perf_event_exec(); > __set_task_comm(current, kbasename(bprm->filename), true); > diff --git a/include/linux/security.h b/include/linux/security.h > index 75f4156..469d05f 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -61,6 +61,12 @@ struct mm_struct; > /* LSM Agnostic defines for sb_set_mnt_opts */ > #define SECURITY_LSM_NATIVE_LABELS 1 > > +/* Security level */ > +#define SECURITY_NORMAL 0 > +#define SECURITY_HIGH 1 NAK: "NORMAL" and "HIGH" are meaningless in this context. If you intend to differentiate between "dumpable" and "undumpable" you could use those, although I would recommend something that describes the reason the task is dumpable. > + > +extern int update_process_security(struct task_struct *task); > + > struct ctl_table; > struct audit_krule; > struct user_namespace; > diff --git a/kernel/cred.c b/kernel/cred.c > index ecf0365..0806a74 100644 > --- a/kernel/cred.c > +++ b/kernel/cred.c > @@ -19,6 +19,7 @@ > #include <linux/security.h> > #include <linux/binfmts.h> > #include <linux/cn_proc.h> > +#include <linux/security.h> > > #if 0 > #define kdebug(FMT, ...) \ > @@ -445,8 +446,10 @@ int commit_creds(struct cred *new) > !uid_eq(old->fsuid, new->fsuid) || > !gid_eq(old->fsgid, new->fsgid) || > !cred_cap_issubset(old, new)) { > - if (task->mm) > + if (task->mm) { > set_dumpable(task->mm, suid_dumpable); > + update_process_security(task); > + } > task->pdeath_signal = 0; > smp_wmb(); > } > diff --git a/kernel/sys.c b/kernel/sys.c > index cf5c675..c6f179a 100644 > --- a/kernel/sys.c > +++ b/kernel/sys.c > @@ -2293,6 +2293,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, > arg2, unsigned long, arg3, > break; > } > set_dumpable(me->mm, arg2); > + update_process_security(me); > break; > > case PR_SET_UNALIGN: > diff --git a/security/security.c b/security/security.c > index 736e78d..12460f2 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -28,6 +28,8 @@ > #include <linux/personality.h> > #include <linux/backing-dev.h> > #include <linux/string.h> > +#include <linux/coredump.h> > +#include <linux/sched/signal.h> > #include <net/flow.h> > > #include <trace/events/initcall.h> > @@ -1353,6 +1355,35 @@ int security_inode_getsecctx(struct inode *inode, > void **ctx, u32 *ctxlen) > } > EXPORT_SYMBOL(security_inode_getsecctx); > > +void __weak arch_set_security(struct task_struct *task, > + unsigned int security_level) > +{ > +} This isn't an LSM hook and hence does not belong in this file. arch_set_security() isn't descriptive, and is in fact a bad choice as task_struct has a field "security". This function has nothing to do with the task->security field, which is what I would expect based on the name. > + > +int update_process_security(struct task_struct *task) Again, this isn't an LSM hook and does not belong in this file. Also again, "security" isn't descriptive in the name. > +{ > + unsigned long flags; > + struct task_struct *t; > + int security_level; > + > + if (!task->mm) > + return -EINVAL; > + > + if (!lock_task_sighand(task, &flags)) > + return -ESRCH; > + > + if (get_dumpable(task->mm) != SUID_DUMP_USER) > + security_level = SECURITY_HIGH; > + else > + security_level = SECURITY_NORMAL; > + > + for_each_thread(task, t) > + arch_set_security(task, security_level); > + > + unlock_task_sighand(task, &flags); > + return 0; > +} > + > #ifdef CONFIG_SECURITY_NETWORK > > int security_unix_stream_connect(struct sock *sock, struct sock *other, > struct > sock *newsk) > -- > 2.9.4