Change the rights in /proc to limit exploits.

[theLOICofFRANCE]

Hi,

The linux kernel symbols /proc/kallsyms is regularly used in exploits. Example: nelson, linux-rds-exploit, cheddar_bay, therebel, wunderbar_emporium, robert-you-suck, linux-rds-exploit etc...

Although the CONFIG_KALLSYMS option can be disabled, this is very rare in distributions. Changing the access rights would therefore limit or complicate certain exploits that uses kernel symbols.

restrict-kallsyms.patch

Thanks

[theLOICofFRANCE]

Used in exploits this way: f = fopen("/proc/kallsyms", "r");

[thestinger]

The addresses are already shown as 0000000000000000 by default since kptr_restrict is set to 2 by default in linux-hardened and will be set to 3 once support for that lands upstream.

[theLOICofFRANCE]

Good. /proc/sched_debug can be interesting (example: floppy-disk-exploit). restrict-sched_debug.patch

[thestinger]

There's already a generic way to lock down access to procfs, sysfs, debugfs, etc. By changing APIs to only be accessible to root, you're increasing the amount of code that ends up needing to run as root. For these timing APIs, you would be forcing statistics logging / monitoring code that uses it to run as root.

The existing approach of using SELinux is more flexible and works for any /proc APIs:

diff --git a/genfs_contexts b/genfs_contexts
index c7900fab..53da7d37 100644
--- a/genfs_contexts
+++ b/genfs_contexts
@@ -12,6 +12,8 @@ genfscon proc /net/ipv6_route u:object_r:proc_net_devroute:s0
 genfscon proc /net/route u:object_r:proc_net_devroute:s0
 genfscon proc /net/xt_qtaguid/ctrl u:object_r:qtaguid_proc:s0
 genfscon proc /cpuinfo u:object_r:proc_cpuinfo:s0
+genfscon proc /sched_debug u:object_r:proc_timer:s0
+genfscon proc /schedstat u:object_r:proc_timer:s0
 genfscon proc /softirqs u:object_r:proc_timer:s0
 genfscon proc /stat u:object_r:proc_stat:s0
 genfscon proc /sysrq-trigger u:object_r:proc_sysrq:s0

I'm not interested in hard-wiring policies for this in the kernel. It needs to be more flexible than simply limiting everything to root which would either break existing code or force it to start running as root. If something can be done with SELinux it's not in scope for copperhead/linux-hardened. If there's an access control feature that cannot be done by SELinux, it may be in-scope, but the best way to implement it may be extending SELinux upstream.