Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1353389 > unrolled thread

[PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection. Scott Bauer <sbauer@eng.utah.edu> - 2016-03-08 21:50 +0100
    Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP  protection. One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-03-08 22:10 +0100
      Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl  to disable SROP protection. Kees Cook <keescook@chromium.org> - 2016-03-10 07:40 +0100
        Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl  to disable SROP protection. Andy Lutomirski <luto@amacapital.net> - 2016-03-10 07:50 +0100

#1353389 — [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

This patch adds a sysctl argument to disable SROP protection.

Cc: Abhiram Balasubramanian <abhiram@cs.utah.edu>
Signed-off-by: Scott Bauer <sbauer@eng.utah.edu>
---
 include/linux/signal.h |  2 ++
 kernel/signal.c        | 12 ++++++++++--
 kernel/sysctl.c        |  8 ++++++++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index fae0618..7e580d9 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -9,6 +9,8 @@ struct task_struct;
 
 /* for sysctl */
 extern int print_fatal_signals;
+extern int srop_disabled;
+
 /*
  * Real Time signals may be queued.
  */
diff --git a/kernel/signal.c b/kernel/signal.c
index 00e4a16..dec4e20 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -52,6 +52,7 @@
 static struct kmem_cache *sigqueue_cachep;
 
 int print_fatal_signals __read_mostly;
+int srop_disabled __read_mostly;
 
 static void __user *sig_handler(struct task_struct *t, int sig)
 {
@@ -2452,6 +2453,9 @@ int verify_clear_sigcookie(unsigned long __user *sig_cookie_ptr)
 	unsigned long user_cookie;
 	unsigned long calculated_cookie;
 
+	if (srop_disabled)
+		goto out;
+
 	if (get_user(user_cookie, sig_cookie_ptr))
 		return 1;
 
@@ -2459,13 +2463,17 @@ int verify_clear_sigcookie(unsigned long __user *sig_cookie_ptr)
 
 	if (user_cookie != calculated_cookie) {
 		pr_warn("Signal protector does not match what kernel set it to"\
-			". Possible exploit attempt or buggy program!\n");
+			". Possible exploit attempt or buggy program!\n If you"\
+			" believe this is an error you can disable SROP "\
+			" Protection by #echo 1 > /proc/sys/kernel/"\
+			"disable-srop-protection\n");
 		return 1;
 
 	}
 
+out:
 	user_cookie = 0;
-	return put_user(user_cookie, sig_cookie_ptr)
+	return put_user(user_cookie, sig_cookie_ptr);
 }
 
 EXPORT_SYMBOL(verify_clear_sigcookie);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 97715fd..6c95172 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -524,6 +524,14 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "disable-srop-protection",
+		.data		= &srop_disabled,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+
+	},
 #ifdef CONFIG_SPARC
 	{
 		.procname	= "reboot-cmd",
-- 
1.9.1

[toc] | [next] | [standalone]

#1353414 — Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

On Tue,  8 Mar 2016 13:47:55 -0700
Scott Bauer <sbauer@eng.utah.edu> wrote:

> This patch adds a sysctl argument to disable SROP protection.

Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
capability I can turn off SROP and attack something to get to higher
capability levels ?

(The way almost all distros are set up its kind of academic but for a
properly secured system it might matter).

Alan

[toc] | [prev] | [next] | [standalone]

#1354877 — Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> On Tue,  8 Mar 2016 13:47:55 -0700
> Scott Bauer <sbauer@eng.utah.edu> wrote:
>
>> This patch adds a sysctl argument to disable SROP protection.
>
> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
> capability I can turn off SROP and attack something to get to higher
> capability levels ?
>
> (The way almost all distros are set up its kind of academic but for a
> properly secured system it might matter).

Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
strictly to CAP_SYS_ADMIN?

-Kees

>
> Alan



-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1354881 — Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

On Wed, Mar 9, 2016 at 10:36 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
> <gnomes@lxorguk.ukuu.org.uk> wrote:
>> On Tue,  8 Mar 2016 13:47:55 -0700
>> Scott Bauer <sbauer@eng.utah.edu> wrote:
>>
>>> This patch adds a sysctl argument to disable SROP protection.
>>
>> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
>> capability I can turn off SROP and attack something to get to higher
>> capability levels ?
>>
>> (The way almost all distros are set up its kind of academic but for a
>> properly secured system it might matter).
>
> Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
> strictly to CAP_SYS_ADMIN?

I don't see why this needs to be irrevocable.  If you have
CAP_SYS_ADMIN or write access to /proc or whatever, you can do much
worse things than turning off a user-level mitigation.  For example,
you can ptrace things.  Also, you're already root, so what's the
point?

--Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web