linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).