| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <99FC4B6EFCEFD44486C35F4C281DC6732148DC65@ORSMSX110.amr.corp.intel.com>
Date: Tue, 30 Oct 2018 20:57:22 +0000
From: "Schaufler, Casey" <casey.schaufler@...el.com>
To: Tim Chen <tim.c.chen@...ux.intel.com>,
Jiri Kosina <jikos@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
CC: Tom Lendacky <thomas.lendacky@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Andi Kleen <ak@...ux.intel.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Mallick, Asit K" <asit.k.mallick@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jon Masters <jcm@...hat.com>,
Waiman Long <longman9394@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"Schaufler, Casey" <casey.schaufler@...el.com>,
linux-security-module <linux-security-module@...r.kernel.org>
Subject: RE: [Patch v4 13/18] security: Update security level of a process
when modifying its dumpability
> -----Original Message-----
> From: Tim Chen [mailto:tim.c.chen@...ux.intel.com]
> Sent: Tuesday, October 30, 2018 11:49 AM
> To: Jiri Kosina <jikos@...nel.org>; Thomas Gleixner <tglx@...utronix.de>
> Cc: Tim Chen <tim.c.chen@...ux.intel.com>; Tom Lendacky
> <thomas.lendacky@....com>; Ingo Molnar <mingo@...hat.com>; Peter
> Zijlstra <peterz@...radead.org>; Josh Poimboeuf <jpoimboe@...hat.com>;
> Andrea Arcangeli <aarcange@...hat.com>; David Woodhouse
> <dwmw@...zon.co.uk>; Andi Kleen <ak@...ux.intel.com>; Hansen, Dave
> <dave.hansen@...el.com>; Schaufler, Casey <casey.schaufler@...el.com>;
> Mallick, Asit K <asit.k.mallick@...el.com>; Arjan van de Ven
> <arjan@...ux.intel.com>; Jon Masters <jcm@...hat.com>; Waiman Long
> <longman9394@...il.com>; linux-kernel@...r.kernel.org; x86@...nel.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.chen@...ux.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
Powered by blists - more mailing lists