From: "Schaufler, Casey" <casey.schaufler@intel.com>
To: Tim Chen <tim.c.chen@linux.intel.com>,
Jiri Kosina <jikos@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Andi Kleen <ak@linux.intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Jon Masters <jcm@redhat.com>, Waiman Long <longman9394@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: RE: [Patch v4 13/18] security: Update security level of a process when modifying its dumpability
Date: Tue, 30 Oct 2018 20:57:22 +0000 [thread overview]
Message-ID: <99FC4B6EFCEFD44486C35F4C281DC6732148DC65@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <e8b6b10e15653b3b2c5727e935f75142e441f834.1540923609.git.tim.c.chen@linux.intel.com>
> -----Original Message-----
> From: Tim Chen [mailto:tim.c.chen@linux.intel.com]
> Sent: Tuesday, October 30, 2018 11:49 AM
> To: Jiri Kosina <jikos@kernel.org>; Thomas Gleixner <tglx@linutronix.de>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>; Tom Lendacky
> <thomas.lendacky@amd.com>; Ingo Molnar <mingo@redhat.com>; Peter
> Zijlstra <peterz@infradead.org>; Josh Poimboeuf <jpoimboe@redhat.com>;
> Andrea Arcangeli <aarcange@redhat.com>; David Woodhouse
> <dwmw@amazon.co.uk>; Andi Kleen <ak@linux.intel.com>; Hansen, Dave
> <dave.hansen@intel.com>; Schaufler, Casey <casey.schaufler@intel.com>;
> Mallick, Asit K <asit.k.mallick@intel.com>; Arjan van de Ven
> <arjan@linux.intel.com>; Jon Masters <jcm@redhat.com>; Waiman Long
> <longman9394@gmail.com>; linux-kernel@vger.kernel.org; x86@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.chen@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
next prev parent reply other threads:[~2018-10-30 20:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 18:49 [Patch v4 00/18] Provide process property based options to enable Spectre v2 userspace-userspace protection* Tim Chen
2018-10-30 18:49 ` [Patch v4 01/18] x86/speculation: Clean up spectre_v2_parse_cmdline() Tim Chen
2018-10-30 18:49 ` [Patch v4 02/18] x86/speculation: Remove unnecessary ret variable in cpu_show_common() Tim Chen
2018-10-30 18:49 ` [Patch v4 03/18] x86/speculation: Reorganize cpu_show_common() Tim Chen
2018-11-03 18:07 ` Thomas Gleixner
2018-11-05 19:12 ` Tim Chen
2018-11-05 19:17 ` Thomas Gleixner
2018-10-30 18:49 ` [Patch v4 04/18] x86/speculation: Add X86_FEATURE_USE_IBRS_ENHANCED Tim Chen
2018-10-30 18:49 ` [Patch v4 05/18] x86/speculation: Disable STIBP when enhanced IBRS is in use Tim Chen
2018-10-30 18:49 ` [Patch v4 06/18] smt: Create cpu_smt_enabled static key for SMT specific code Tim Chen
2018-10-30 18:49 ` [Patch v4 07/18] x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key Tim Chen
2018-11-03 18:29 ` Thomas Gleixner
2018-11-08 1:43 ` Tim Chen
2018-11-08 11:18 ` Thomas Gleixner
2018-10-30 18:49 ` [Patch v4 08/18] sched: Deprecate sched_smt_present and use " Tim Chen
2018-11-03 18:20 ` Thomas Gleixner
2018-11-09 22:08 ` Tim Chen
2018-10-30 18:49 ` [Patch v4 09/18] x86/speculation: Rename SSBD update functions Tim Chen
2018-10-30 18:49 ` [Patch v4 10/18] x86/speculation: Reorganize speculation control MSRs update Tim Chen
2018-10-30 18:49 ` [Patch v4 11/18] x86/speculation: Update comment on TIF_SSBD Tim Chen
2018-10-30 18:49 ` [Patch v4 12/18] x86: Group thread info flags by functionality Tim Chen
2018-10-30 18:49 ` [Patch v4 13/18] security: Update security level of a process when modifying its dumpability Tim Chen
2018-10-30 20:57 ` Schaufler, Casey [this message]
2018-10-30 21:30 ` Tim Chen
2018-10-30 21:53 ` Schaufler, Casey
2018-10-30 18:49 ` [Patch v4 14/18] x86/speculation: Turn on or off STIBP according to a task's TIF_STIBP Tim Chen
2018-10-30 18:49 ` [Patch v4 15/18] x86/speculation: Add Spectre v2 app to app protection modes Tim Chen
2018-10-30 18:49 ` [Patch v4 16/18] x86/speculation: Enable STIBP to protect security sensitive tasks Tim Chen
2018-10-30 21:07 ` Schaufler, Casey
2018-10-30 21:34 ` Tim Chen
2018-10-30 22:02 ` Schaufler, Casey
2018-10-30 18:49 ` [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote CPUs Tim Chen
2018-11-04 19:49 ` Thomas Gleixner
2018-11-05 22:02 ` Tim Chen
2018-11-05 23:04 ` Thomas Gleixner
2018-11-05 23:59 ` Tim Chen
2018-11-06 7:46 ` Thomas Gleixner
2018-11-07 0:18 ` Tim Chen
2018-11-07 18:33 ` Waiman Long
2018-11-07 23:15 ` Tim Chen
2018-11-07 23:03 ` Thomas Gleixner
2018-11-08 0:22 ` Tim Chen
2018-10-30 18:49 ` [Patch v4 18/18] x86/speculation: Create PRCTL interface to restrict indirect branch speculation Tim Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99FC4B6EFCEFD44486C35F4C281DC6732148DC65@ORSMSX110.amr.corp.intel.com \
--to=casey.schaufler@intel.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=asit.k.mallick@intel.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=jcm@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=longman9394@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.c.chen@linux.intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).