[PATCH] Restrict unprivileged access to kernel syslog
Dan Rosenberg
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 <drose...@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;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kees Cook
> 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 <drose...@vsecurity.com>
Acked-by: Kees Cook <kees...@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
Eugene Teo
> 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 <drose...@vsecurity.com>
>
> Acked-by: Kees Cook <kees...@canonical.com>
>
> This looks good to me -- it leaves the /proc file access alone for
> priv-dropping ksyslogd implementations.
Acked-by: Eugene Teo <euge...@kernel.org>
Looks good to me too. Thanks.
Eugene
Ingo Molnar
* Dan Rosenberg <drose...@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 <drose...@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
Alan Cox
Dan Rosenberg <drose...@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.
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
Arjan van de Ven
Dan Rosenberg <drose...@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
Ingo Molnar
* Arjan van de Ven <ar...@infradead.org> wrote:
> On Tue, 09 Nov 2010 07:11:12 -0500
> Dan Rosenberg <drose...@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
Dan Rosenberg
-Dan
Dan Rosenberg
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.
v2 adds CONFIG_SECURITY_RESTRICT_DMESG. When enabled, the default
sysctl value is set to "1". When disabled, the default sysctl value is
set to "0".
Signed-off-by: Dan Rosenberg <drose...@vsecurity.com>
CC: Linus Torvalds <torv...@linux-foundation.org>
CC: Ingo Molnar <mi...@elte.hu>
CC: Kees Cook <kees...@canonical.com>
CC: stable <sta...@kernel.org>
---
Documentation/sysctl/kernel.txt | 11 +++++++++++
include/linux/kernel.h | 1 +
kernel/printk.c | 6 ++++++
kernel/sysctl.c | 9 +++++++++
security/Kconfig | 11 +++++++++++
security/commoncap.c | 2 ++
6 files changed, 40 insertions(+), 0 deletions(-)
index b2ebaee..485d653 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -261,6 +261,12 @@ static inline void boot_delay_msec(void)
}
#endif
+#ifdef CONFIG_SECURITY_RESTRICT_DMESG
+int dmesg_restrict = 1;
+#else
+int dmesg_restrict;
+#endif
+
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/Kconfig b/security/Kconfig
index bd72ae6..6ca390e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -39,6 +39,17 @@ config KEYS_DEBUG_PROC_KEYS
If you are unsure as to whether this is required, answer N.
+config SECURITY_RESTRICT_DMESG
+ bool "Restrict unprivileged access to the kernel syslog"
+ help
+ This enforces restrictions on unprivileged users reading the kernel
+ syslog via dmesg(8).
+
+ If this option is not selected, no restrictions will be enforced
+ unless the dmesg_restrict sysctl is explicitly set to (1).
+
+ If you are unsure how to answer this question, answer N.
+
config SECURITY
bool "Enable different security models"
depends on SYSFS
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;
Ingo Molnar
* Dan Rosenberg <drose...@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.
>
> v2 adds CONFIG_SECURITY_RESTRICT_DMESG. When enabled, the default
> sysctl value is set to "1". When disabled, the default sysctl value is
> set to "0".
>
> Signed-off-by: Dan Rosenberg <drose...@vsecurity.com>
> CC: Linus Torvalds <torv...@linux-foundation.org>
> CC: Ingo Molnar <mi...@elte.hu>
> CC: Kees Cook <kees...@canonical.com>
> CC: stable <sta...@kernel.org>
Acked-by: Ingo Molnar <mi...@elte.hu>
Linus, Andrew, any objections against pushing this trivial control flag upstream out
of band, after a bit of testing? It's not like it can break anything, and the flag
is very useful to distros.
Thanks,
Ingo
Andrew Morton
>
> * Dan Rosenberg <drose...@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.
> >
> > v2 adds CONFIG_SECURITY_RESTRICT_DMESG. When enabled, the default
> > sysctl value is set to "1". When disabled, the default sysctl value is
> > set to "0".
> >
> > Signed-off-by: Dan Rosenberg <drose...@vsecurity.com>
> > CC: Linus Torvalds <torv...@linux-foundation.org>
> > CC: Ingo Molnar <mi...@elte.hu>
> > CC: Kees Cook <kees...@canonical.com>
> > CC: stable <sta...@kernel.org>
>
> Acked-by: Ingo Molnar <mi...@elte.hu>
>
> Linus, Andrew, any objections against pushing this trivial control flag upstream out
> of band, after a bit of testing? It's not like it can break anything, and the flag
> is very useful to distros.
>
OK by me, apart from ...
a) I'd question the need for the config option. Are distros really
so lame that they can't trust themselves to poke a number into
procfs at boot time?
b) we have "dmesg_restrict" and "CONFIG_RESTRICT_DMESG". Less
dyslexia, please.
Kees Cook
> 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.
>
> v2 adds CONFIG_SECURITY_RESTRICT_DMESG. When enabled, the default
> sysctl value is set to "1". When disabled, the default sysctl value is
> set to "0".
>
> Signed-off-by: Dan Rosenberg <drose...@vsecurity.com>
> CC: Linus Torvalds <torv...@linux-foundation.org>
> CC: Ingo Molnar <mi...@elte.hu>
> CC: Kees Cook <kees...@canonical.com>
> CC: stable <sta...@kernel.org>
Acked-by: Kees Cook <kees...@canonical.com>
As before, this looks fine and does the right thing with regard to /proc
access to the kernel log.
--
Kees Cook
Ubuntu Security Team
Dave Jones
> a) I'd question the need for the config option. Are distros really
> so lame that they can't trust themselves to poke a number into
> procfs at boot time?
short answer: yes.
* /etc/sysctl.conf is for users to override decisions distros have made,
rather than a catalog of those decisions.
* Sometimes we change our mind on those decisions. Flipping a config option
in the kernel means we push out an update, and forget about it.
Users /etc/sysctl.conf's contain all kinds of crazyness. ask Davem about
the stale TCP 'tuning' crap that lingered for years in Fedora users configs
before anyone noticed.
(We could update the sysctl.conf at post-install of the kernel package,
but if you've ever seen a distro kernel packaging schema, you'd understand
why adding more magic like this isn't desirable)
There's a bunch of patches we carry in Fedora that change defaults because there's
no CONFIG option for them, which I've been meaning to get around to
hacking up into options so we can carry a few less patches.
Dave
Ingo Molnar
* Dave Jones <da...@redhat.com> wrote:
> On Wed, Nov 10, 2010 at 07:26:38AM -0800, Andrew Morton wrote:
>
> > a) I'd question the need for the config option. Are distros really
> > so lame that they can't trust themselves to poke a number into
> > procfs at boot time?
>
> short answer: yes.
>
> * /etc/sysctl.conf is for users to override decisions distros have made,
> rather than a catalog of those decisions.
>
> * Sometimes we change our mind on those decisions. Flipping a config option
> in the kernel means we push out an update, and forget about it.
> Users /etc/sysctl.conf's contain all kinds of crazyness. ask Davem about
> the stale TCP 'tuning' crap that lingered for years in Fedora users configs
> before anyone noticed.
> (We could update the sysctl.conf at post-install of the kernel package,
> but if you've ever seen a distro kernel packaging schema, you'd understand
> why adding more magic like this isn't desirable)
>
> There's a bunch of patches we carry in Fedora that change defaults because there's
> no CONFIG option for them, which I've been meaning to get around to hacking up
> into options so we can carry a few less patches.
_YES_.
A self-contained .config that carries all kernel related defaults is a very powerful
thing. We need more of that.
Thanks,
Ingo
Ingo Molnar
* Andrew Morton <ak...@linux-foundation.org> wrote:
> OK by me, apart from ...
>
> a) I'd question the need for the config option. Are distros really
> so lame that they can't trust themselves to poke a number into
> procfs at boot time?
When it comes to security i personally prefer 'permanent' defaults that is a
property of the booting image. I'd even change the default for the x86 defconfig for
example - and we could make this option default-y in the future. (We cannot ever
make the sysctl default itself default-1, it would break compatibility with old
behavior.)
> b) we have "dmesg_restrict" and "CONFIG_RESTRICT_DMESG". Less
> dyslexia, please.
Good point. CONFIG_DMESG_RESTRICT is the proper hierarchical naming i suspect.
Thanks,
Ingo
Dan Rosenberg
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.
v3 sets a default for the config, renames to
CONFIG_SECURITY_DMESG_RESTRICT to be consistent with the sysctl name,
and adds Acks.
Signed-off-by: Dan Rosenberg <drose...@vsecurity.com>
Acked-by: Ingo Molnar <mi...@elte.hu>
Acked-by: Eugene Teo <euge...@kernel.org>
Acked-by: Kees Cook <kees...@canonical.com>
CC: Linus Torvalds <torv...@linux-foundation.org>
CC: Andrew Morton <ak...@linux-foundation.org>
CC: stable <sta...@kernel.org>
---
Documentation/sysctl/kernel.txt | 11 +++++++++++
include/linux/kernel.h | 1 +
kernel/printk.c | 6 ++++++
kernel/sysctl.c | 9 +++++++++
security/Kconfig | 12 ++++++++++++
security/commoncap.c | 2 ++
6 files changed, 41 insertions(+), 0 deletions(-)
index b2ebaee..38e7d58 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -261,6 +261,12 @@ static inline void boot_delay_msec(void)
}
#endif
+#ifdef CONFIG_SECURITY_DMESG_RESTRICT
index bd72ae6..ffb2493 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -39,6 +39,18 @@ config KEYS_DEBUG_PROC_KEYS
If you are unsure as to whether this is required, answer N.
+config SECURITY_DMESG_RESTRICT
+ bool "Restrict unprivileged access to the kernel syslog"
+ default n
+ help
+ This enforces restrictions on unprivileged users reading the kernel
+ syslog via dmesg(8).
+
+ If this option is not selected, no restrictions will be enforced
+ unless the dmesg_restrict sysctl is explicitly set to (1).
+
+ If you are unsure how to answer this question, answer N.
+
config SECURITY
bool "Enable different security models"
depends on SYSFS
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;
Andrew Morton
Dan Rosenberg <drose...@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.
>
> v3 sets a default for the config, renames to
> CONFIG_SECURITY_DMESG_RESTRICT to be consistent with the sysctl name,
> and adds Acks.
>
The patch adds trailing whitespace. checkpatch detects it.
> CC: stable <sta...@kernel.org>
hm. Reasons for this?
> ...
>
> +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).
Actually, the default depends on CONFIG_SECURITY_DMESG_RESTRICT ;)
You might be able to make this an int type and do
int dmesg_restrict = CONFIG_SECURITY_DMESG_RESTRICT;
We did a trick like that with CONFIG_BASE_SMALL:
int whatever = CONFIG_BASE_SMALL ? 2 : 42;
otoh you might decide not to bother, in which case, this?
--- a/Documentation/sysctl/kernel.txt~restrict-unprivileged-access-to-kernel-syslog-fix
+++ a/Documentation/sysctl/kernel.txt
@@ -216,11 +216,14 @@ 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).
+This toggle indicates whether unprivileged users are prevented from using
+dmesg(8) to view messages from the kernel's log buffer. When
+dmesg_restrict is set to (0) there are no restrictions. When
+dmesg_restrict is set set to (1), users must have CAP_SYS_ADMIN to use
+dmesg(8).
+
+The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the default
+value of dmesg_restrict.
==============================================================
_
Greg KH
> CC: stable <sta...@kernel.org>
Like Andrew pointed out, this is not stable material. Please go read
Documentation/stable_kernel_rules.txt to explain what is acceptable for
the stable kernel trees (hint, new features like this one is not.)
thanks,
greg k-h
James Morris
> > +#ifdef CONFIG_SECURITY_DMESG_RESTRICT
> > +int dmesg_restrict = 1;
> > +#else
> > +int dmesg_restrict;
> > +#endif
>
> You might be able to make this an int type and do
>
> int dmesg_restrict = CONFIG_SECURITY_DMESG_RESTRICT;
This is cleaner, so if resending the patch, I'd prefer this version.
- James
--
James Morris
<jmo...@namei.org>
James Morris
security features.
Please cc the LSM list for security feature development.
i.e. linux-secu...@vger.kernel.org
- James
--
James Morris
<jmo...@namei.org>
Ingo Molnar
* Andrew Morton <ak...@linux-foundation.org> wrote:
> > CC: stable <sta...@kernel.org>
>
> hm. Reasons for this?
I dont think so. Can we still try it for .37 though?
Thanks,
Ingo
James Morris
>
> * Andrew Morton <ak...@linux-foundation.org> wrote:
>
> > > CC: stable <sta...@kernel.org>
> >
> > hm. Reasons for this?
>
> I dont think so. Can we still try it for .37 though?
I don't have any objections, but how about we give it a week in -next at
least?
--
James Morris
<jmo...@namei.org>
Pavel Machek
> On Mon, 08 Nov 2010 22:28:58 -0500
> Dan Rosenberg <drose...@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
Pavel Machek
> 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.
Ok, this is very very ugly.
You essentially create a bit to control what other bit does. Clean
solution would be CAP_SYS_DMESG, and make sure that is given to
processes by default...
...and that would be actually very good thing -- on cellphones, you
want some users without ability to connect to network, so you could
introduce CAP_NETWORK etc...
Pavel
Dan Rosenberg
> Hi!
>
> > 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.
>
> Ok, this is very very ugly.
>
> You essentially create a bit to control what other bit does. Clean
> solution would be CAP_SYS_DMESG, and make sure that is given to
> processes by default...
>
> ...and that would be actually very good thing -- on cellphones, you
> want some users without ability to connect to network, so you could
> introduce CAP_NETWORK etc...
>
> Pavel
The CONFIG was added on suggestion that it would make it easier for
distributions to enable this behavior by default. The patch was
modified to use CAP_SYSLOG, which seems in line with what you want.
Thanks,
Dan