Restrict unprivileged access to kernel syslog
Subsystems (4)
PATCH 1/1 Restrict unprivileged access to kernel syslog
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.
--- 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(-)
Documentation/sysctl/kernel.txt +11 -0
@@ -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
include/linux/kernel.h +1 -0
@@ -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):
kernel/printk.c +2 -0
@@ -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;
kernel/sysctl.c +9 -0
@@ -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),
security/commoncap.c +2 -0
@@ -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 ;
Quoted 7 lines · 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.
Quoted 6 lines
This patch, loosely based on grsecurity's
GRKERNSEC_DMESG, creates thedmesg_restrictsysctl. When set to "0", the default, no restrictions are enforced. When set to "1", only users withCAP_SYS_ADMINcan read the kernel syslog via dmesg(8) or other mechanisms.Signed-off-by Dan Rosenberg <[email protected]>
This looks good to me -- it leaves the /proc file access alone for priv-dropping ksyslogd implementations.
-Kees
Signature · 2 lines
Kees Cook Ubuntu Security Team
Eugene Teo
Acked-byQuoted 13 lines · Kees Cook
Quoted 12 lines · 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 thedmesg_restrictsysctl. When set to "0", the default, no restrictions are enforced. When set to "1", only users withCAP_SYS_ADMINcan read the kernel syslog via dmesg(8) or other mechanisms.
Quoted 6 lines
Quoted 1 line
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.
Looks good to me too. Thanks.
Eugene
Quoted 21 lines · 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 thedmesg_restrictsysctl. When set to "0", the default, no restrictions are enforced. When set to "1", only users withCAP_SYS_ADMINcan 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(-)
Quoted 1 line
+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
Quoted 4 lines
The initialization to zero is implicit, no need to write it out.
I'll resend after the first round of comments.
Quoted 3 lines
Also, it would also be useful to have a
CONFIG_SECURITY_RESTRICT_DMESG=yoption 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
Quoted 12 lines · On Tue, 09 Nov 2010 07:11:12 -0500 Dan Rosenberg <[email protected]>…
Quoted 4 lines
The initialization to zero is implicit, no need to write it out.
I'll resend after the first round of comments.
Quoted 4 lines
Also, it would also be useful to have a
CONFIG_SECURITY_RESTRICT_DMESG=yoption introduced by your patch as well, which flag allows a distro or user to disable unprivileged syslog reading via the kernel config.
Quoted 4 lines
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
Signature · 3 lines
Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Quoted 15 lines · Arjan van de Ven
Quoted 12 lines · On Tue, 09 Nov 2010 07:11:12 -0500 Dan Rosenberg <[email protected]>…
Quoted 4 lines
The initialization to zero is implicit, no need to write it out.
I'll resend after the first round of comments.
Quoted 4 lines
Also, it would also be useful to have a
CONFIG_SECURITY_RESTRICT_DMESG=yoption introduced by your patch as well, which flag allows a distro or user to disable unprivileged syslog reading via the kernel config.
Quoted 5 lines
Quoted 3 lines
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
Quoted 6 lines · On Mon, 08 Nov 2010 22:28:58 -0500 Dan Rosenberg <[email protected]>…
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.
Quoted 10 lines · Alan Cox
Quoted 6 lines · On Mon, 08 Nov 2010 22:28:58 -0500 Dan Rosenberg <[email protected]>…
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.
Quoted 4 lines
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_ADMINeither way.
/dev/vcsa is only protected by filesystem permissions IIRC.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html