[PATCH] Restrict unprivileged access to kernel syslog

[PATCH] Restrict unprivileged access to kernel syslog

[Dan Rosenberg]

The kernel syslog contains debugging information that is often useful
during exploitation of other vulnerabilities, such as kernel heap
addresses.  Rather than futilely attempt to sanitize hundreds (or
thousands) of printk statements and simultaneously cripple useful
debugging functionality, it is far simpler to create an option that
prevents unprivileged users from reading the syslog.

This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
dmesg_restrict sysctl.  When set to "0", the default, no restrictions
are enforced.  When set to "1", only users with CAP_SYS_ADMIN can read
the kernel syslog via dmesg(8) or other mechanisms.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
---
 Documentation/sysctl/kernel.txt |   11 +++++++++++
 include/linux/kernel.h          |    1 +
 kernel/printk.c                 |    2 ++
 kernel/sysctl.c                 |    9 +++++++++
 security/commoncap.c            |    2 ++
 5 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 3894eaa..c6bac30 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -28,6 +28,7 @@ show up in /proc/sys/kernel:
 - core_uses_pid
 - ctrl-alt-del
 - dentry-state
+- dmesg_restrict
 - domainname
 - hostname
 - hotplug
@@ -213,6 +214,16 @@ to decide what to do with it.
 
 ==============================================================
 
+dmesg_restrict:
+
+This toggle indicates whether unprivileged users are prevented 
+from using dmesg(8) to view messages from the kernel's log
+buffer.  By default, it is set to (0), resulting in no 
+restrictions.  When set to (1), users must have CAP_SYS_ADMIN
+to use dmesg(8).
+
+==============================================================
+
 domainname & hostname:
 
 These files can be used to set the NIS/YP domainname and the
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 450092c..f0d0088 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -293,6 +293,7 @@ extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
 				   unsigned int interval_msec);
 
 extern int printk_delay_msec;
+extern int dmesg_restrict;
 
 /*
  * Print a one-time message (analogous to WARN_ONCE() et al):
diff --git a/kernel/printk.c b/kernel/printk.c
index b2ebaee..99b1ec3 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -261,6 +261,8 @@ static inline void boot_delay_msec(void)
 }
 #endif
 
+int dmesg_restrict = 0;
+
 int do_syslog(int type, char __user *buf, int len, bool from_file)
 {
 	unsigned i, j, limit, count;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c33a1ed..b65bf63 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -704,6 +704,15 @@ static struct ctl_table kern_table[] = {
 	},
 #endif
 	{
+		.procname	= "dmesg_restrict",
+		.data		= &dmesg_restrict,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &zero,
+		.extra2		= &one,
+	},
+	{
 		.procname	= "ngroups_max",
 		.data		= &ngroups_max,
 		.maxlen		= sizeof (int),
diff --git a/security/commoncap.c b/security/commoncap.c
index 5e632b4..04b80f9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -895,6 +895,8 @@ int cap_syslog(int type, bool from_file)
 {
 	if (type != SYSLOG_ACTION_OPEN && from_file)
 		return 0;
+	if (dmesg_restrict && !capable(CAP_SYS_ADMIN))
+		return -EPERM;
 	if ((type != SYSLOG_ACTION_READ_ALL &&
 	     type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
 		return -EPERM;

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Kees Cook]

On Mon, Nov 08, 2010 at 10:28:58PM -0500, Dan Rosenberg wrote:
> The kernel syslog contains debugging information that is often useful
> during exploitation of other vulnerabilities, such as kernel heap
> addresses.  Rather than futilely attempt to sanitize hundreds (or
> thousands) of printk statements and simultaneously cripple useful
> debugging functionality, it is far simpler to create an option that
> prevents unprivileged users from reading the syslog.
> 
> This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
> dmesg_restrict sysctl.  When set to "0", the default, no restrictions
> are enforced.  When set to "1", only users with CAP_SYS_ADMIN can read
> the kernel syslog via dmesg(8) or other mechanisms.
> 
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>

Acked-by: Kees Cook <kees.cook@canonical.com>

This looks good to me -- it leaves the /proc file access alone for
priv-dropping ksyslogd implementations.

-Kees

-- 
Kees Cook
Ubuntu Security Team

Re: [Security] [PATCH] Restrict unprivileged access to kernel syslog

[Eugene Teo]

On Tue, Nov 9, 2010 at 1:34 PM, Kees Cook <kees.cook@canonical.com> wrote:
> On Mon, Nov 08, 2010 at 10:28:58PM -0500, Dan Rosenberg wrote:
>> The kernel syslog contains debugging information that is often useful
>> during exploitation of other vulnerabilities, such as kernel heap
>> addresses.  Rather than futilely attempt to sanitize hundreds (or
>> thousands) of printk statements and simultaneously cripple useful
>> debugging functionality, it is far simpler to create an option that
>> prevents unprivileged users from reading the syslog.
>>
>> This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
>> dmesg_restrict sysctl.  When set to "0", the default, no restrictions
>> are enforced.  When set to "1", only users with CAP_SYS_ADMIN can read
>> the kernel syslog via dmesg(8) or other mechanisms.
>>
>> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
>
> Acked-by: Kees Cook <kees.cook@canonical.com>
>
> This looks good to me -- it leaves the /proc file access alone for
> priv-dropping ksyslogd implementations.

Acked-by: Eugene Teo <eugeneteo@kernel.org>

Looks good to me too. Thanks.

Eugene

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Ingo Molnar]

* Dan Rosenberg <drosenberg@vsecurity.com> wrote:

> The kernel syslog contains debugging information that is often useful
> during exploitation of other vulnerabilities, such as kernel heap
> addresses.  Rather than futilely attempt to sanitize hundreds (or
> thousands) of printk statements and simultaneously cripple useful
> debugging functionality, it is far simpler to create an option that
> prevents unprivileged users from reading the syslog.
> 
> This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
> dmesg_restrict sysctl.  When set to "0", the default, no restrictions
> are enforced.  When set to "1", only users with CAP_SYS_ADMIN can read
> the kernel syslog via dmesg(8) or other mechanisms.
> 
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
> ---
>  Documentation/sysctl/kernel.txt |   11 +++++++++++
>  include/linux/kernel.h          |    1 +
>  kernel/printk.c                 |    2 ++
>  kernel/sysctl.c                 |    9 +++++++++
>  security/commoncap.c            |    2 ++
>  5 files changed, 25 insertions(+), 0 deletions(-)

> +int dmesg_restrict = 0;

The initialization to zero is implicit, no need to write it out.

Also, it would also be useful to have a CONFIG_SECURITY_RESTRICT_DMESG=y option 
introduced by your patch as well, which flag allows a distro or user to disable 
unprivileged syslog reading via the kernel config.

Thanks,

	Ingo

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Dan Rosenberg]

> 
> The initialization to zero is implicit, no need to write it out.
> 

I'll resend after the first round of comments.

> Also, it would also be useful to have a CONFIG_SECURITY_RESTRICT_DMESG=y option 
> introduced by your patch as well, which flag allows a distro or user to disable 
> unprivileged syslog reading via the kernel config.

Are you suggesting having the existence of the sysctl depend on
CONFIG_SECURITY_RESTRICT_DMESG, or having a choice between a sysctl
(when config is disabled) and having restrictions always on (when config
is enabled)?

-Dan

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Arjan van de Ven]

On Tue, 09 Nov 2010 07:11:12 -0500
Dan Rosenberg <drosenberg@vsecurity.com> wrote:

> 
> > 
> > The initialization to zero is implicit, no need to write it out.
> > 
> 
> I'll resend after the first round of comments.
> 
> > Also, it would also be useful to have a
> > CONFIG_SECURITY_RESTRICT_DMESG=y option introduced by your patch as
> > well, which flag allows a distro or user to disable unprivileged
> > syslog reading via the kernel config.
> 
> Are you suggesting having the existence of the sysctl depend on
> CONFIG_SECURITY_RESTRICT_DMESG, or having a choice between a sysctl
> (when config is disabled) and having restrictions always on (when
> config is enabled)?

and/or have the sysctl default value depend on the config option


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Ingo Molnar]

* Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 09 Nov 2010 07:11:12 -0500
> Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> 
> > 
> > > 
> > > The initialization to zero is implicit, no need to write it out.
> > > 
> > 
> > I'll resend after the first round of comments.
> > 
> > > Also, it would also be useful to have a
> > > CONFIG_SECURITY_RESTRICT_DMESG=y option introduced by your patch as
> > > well, which flag allows a distro or user to disable unprivileged
> > > syslog reading via the kernel config.
> > 
> > Are you suggesting having the existence of the sysctl depend on 
> > CONFIG_SECURITY_RESTRICT_DMESG, or having a choice between a sysctl (when config 
> > is disabled) and having restrictions always on (when config is enabled)?
> 
> and/or have the sysctl default value depend on the config option

Yeah. I think we should have the sysctl unconditionally as in Dan's current patch - 
and make the default depend on the Kconfig setting (defaulting to off).

I.e. essentially the same as the current patch, just a bit more configurability via 
the Kconfig setting.

Thanks,

	Ingo

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Alan Cox]

On Mon, 08 Nov 2010 22:28:58 -0500
Dan Rosenberg <drosenberg@vsecurity.com> wrote:

> The kernel syslog contains debugging information that is often useful
> during exploitation of other vulnerabilities, such as kernel heap
> addresses.  Rather than futilely attempt to sanitize hundreds (or
> thousands) of printk statements and simultaneously cripple useful
> debugging functionality, it is far simpler to create an option that
> prevents unprivileged users from reading the syslog.

Except for anything that appears on the screen - which is remotely
readable via the screen access APIs. Looks sane to me (pointless but
sane) and the checks match the ones needed to redirect the console so you
need CAP_SYS_ADMIN either way.

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Pavel Machek]

On Tue 2010-11-09 12:06:49, Alan Cox wrote:
> On Mon, 08 Nov 2010 22:28:58 -0500
> Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> 
> > The kernel syslog contains debugging information that is often useful
> > during exploitation of other vulnerabilities, such as kernel heap
> > addresses.  Rather than futilely attempt to sanitize hundreds (or
> > thousands) of printk statements and simultaneously cripple useful
> > debugging functionality, it is far simpler to create an option that
> > prevents unprivileged users from reading the syslog.
> 
> Except for anything that appears on the screen - which is remotely
> readable via the screen access APIs. Looks sane to me (pointless but
> sane) and the checks match the ones needed to redirect the console so you
> need CAP_SYS_ADMIN either way.

/dev/vcsa is only protected by filesystem permissions IIRC.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Restrict unprivileged access to kernel syslog

[Dan Rosenberg]

I agree with this.  Unless anyone else has any suggestions, I'll get this ready tonight.

-Dan

------Original Message------
From: Ingo Molnar
To: Arjan van de Ven
Cc: Dan Rosenberg
Cc: linux-kernel@vger.kernel.org
Cc: security@kernel.org
Cc: stable@kernel.org
Cc: Andrew Morton
Subject: Re: [PATCH] Restrict unprivileged access to kernel syslog
Sent: Nov 9, 2010 9:20 AM


* Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 09 Nov 2010 07:11:12 -0500
> Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> 
> > 
> > > 
> > > The initialization to zero is implicit, no need to write it out.
> > > 
> > 
> > I'll resend after the first round of comments.
> > 
> > > Also, it would also be useful to have a
> > > CONFIG_SECURITY_RESTRICT_DMESG=y option introduced by your patch as
> > > well, which flag allows a distro or user to disable unprivileged
> > > syslog reading via the kernel config.
> > 
> > Are you suggesting having the existence of the sysctl depend on 
> > CONFIG_SECURITY_RESTRICT_DMESG, or having a choice between a sysctl (when config 
> > is disabled) and having restrictions always on (when config is enabled)?
> 
> and/or have the sysctl default value depend on the config option

Yeah. I think we should have the sysctl unconditionally as in Dan's current patch - 
and make the default depend on the Kconfig setting (defaulting to off).

I.e. essentially the same as the current patch, just a bit more configurability via 
the Kconfig setting.

Thanks,

	Ingo
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥