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 <[email protected]>
---
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;
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 <[email protected]>
Acked-by: Kees Cook <[email protected]>
This looks good to me -- it leaves the /proc file access alone for
priv-dropping ksyslogd implementations.
-Kees
--
Kees Cook
Ubuntu Security Team
On Tue, Nov 9, 2010 at 1:34 PM, Kees Cook <[email protected]> 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 <[email protected]>
>
> Acked-by: Kees Cook <[email protected]>
>
> This looks good to me -- it leaves the /proc file access alone for
> priv-dropping ksyslogd implementations.
Acked-by: Eugene Teo <[email protected]>
Looks good to me too. Thanks.
Eugene
* Dan Rosenberg <[email protected]> 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 <[email protected]>
> ---
> 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
On Mon, 08 Nov 2010 22:28:58 -0500
Dan Rosenberg <[email protected]> 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.
>
> 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
On Tue, 09 Nov 2010 07:11:12 -0500
Dan Rosenberg <[email protected]> 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
* Arjan van de Ven <[email protected]> wrote:
> On Tue, 09 Nov 2010 07:11:12 -0500
> Dan Rosenberg <[email protected]> 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
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: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Andrew Morton
Subject: Re: [PATCH] Restrict unprivileged access to kernel syslog
Sent: Nov 9, 2010 9:20 AM
* Arjan van de Ven <[email protected]> wrote:
> On Tue, 09 Nov 2010 07:11:12 -0500
> Dan Rosenberg <[email protected]> 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?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tue 2010-11-09 12:06:49, Alan Cox wrote:
> On Mon, 08 Nov 2010 22:28:58 -0500
> Dan Rosenberg <[email protected]> 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