Restrict unprivileged access to kernel syslog
Subsystems (4)
PATCH v3 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.
v3 sets a default for the config, renames to CONFIG_SECURITY_DMESG_RESTRICT to be consistent with the sysctl name, and adds Acks.
--- 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(-)
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 +6 -0
@@ -261,6 +261,12 @@ static inline void boot_delay_msec(void) }#endif +#ifdef CONFIG_SECURITY_DMESG_RESTRICT +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;
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/Kconfig +12 -0
@@ -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
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 · On Wed, 10 Nov 2010 18:28:55 -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 9 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.v3 sets a default for the config, renames to
CONFIG_SECURITY_DMESG_RESTRICTto be consistent with the sysctl name, and adds Acks.
The patch adds trailing whitespace. checkpatch detects it.
Quoted 1 line
CC stable <[email protected]>
hm. Reasons for this?
Review
Quoted 9 lines
...
(quoted diff) +7
-0+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 ;)
Quoted 22 lines
+==============================================================
(quoted diff) +1
-0+ domainname & hostname: These files can be used to set the NIS/YP domainname and theinclude/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 +0
-0
kernel/printk.c static inline void boot_delay_msec(void) · line 268
Quoted 8 lines
kernel/printk.c +5
-0@@ -261,6 +261,12 @@ static inline void boot_delay_msec(void) }#endif +#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;
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?
Documentation/sysctl/kernel.txt renamed from Documentation/sysctl/kernel.txt~restrict-unprivileged-access-to-kernel-syslog-fix +8 -5
@@ -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. ==============================================================
_
Quoted 1 line · Dan Rosenberg
CC stable <[email protected]>
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
maintainerQuoted 9 lines · Andrew Morton
Review
Quoted 5 lines
(quoted diff) +5
-0+#ifdef CONFIG_SECURITY_DMESG_RESTRICT +int dmesg_restrict = 1; +#else +int dmesg_restrict; +#endifYou 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
Signature · 2 lines
James Morris <[email protected]>
James Morris
maintainerAlso, [email protected] is for security response, not for submitting security features.
Please cc the LSM list for security feature development.
i.e. [email protected]
- James
Signature · 2 lines
James Morris <[email protected]>
Quoted 3 lines · Andrew Morton
Quoted 1 line
CC stable <[email protected]>hm. Reasons for this?
I dont think so. Can we still try it for .37 though?
Thanks,
Ingo
James Morris
maintainerQuoted 8 lines · Ingo Molnar
Quoted 3 lines · Andrew Morton
Quoted 1 line
CC stable <[email protected]>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?
Signature · 2 lines
James Morris <[email protected]>
Hi!
Quoted 11 lines
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.
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
Quoted 20 lines · Pavel Machek
Hi!
Quoted 11 lines
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.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...
Quoted 5 lines
...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_NETWORKetc...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