procfs privacy
cover procfs privacy
As extracted from grsecurity's config. documentation: "non-root users will only be able to view their own processes, and restricts them from viewing network-related information, and viewing kernel symbol and module information."
This is a procfs "privacy" split-up patch based in grsecurity procfs restrictions
with some changes, more concretely, the restricted sections and entries are:
- /proc/bus
/pci
- /proc/net
- /proc/config.gz
- /proc/kallsyms
- /proc/ioports
- /proc/iomem
- /proc/devices
- /proc/cmdline
- /proc/version
- /proc/uptime
- /proc/cpuinfo
- /proc/partitions
- /proc/stat
- /proc/interrupts
- /proc/slabinfo
- /proc/diskstats
- /proc/modules
- /proc/schedstat
---
linux-2.6.11-lorenzo/drivers/pci/proc.c | 4 ++-- linux-2.6.11-lorenzo/fs/proc/base.c | 10 +++++++++- linux-2.6.11-lorenzo/fs/proc/proc_misc.c | 25 +++++++++++++------------ linux-2.6.11-lorenzo/fs/proc/root.c | 4 ++-- linux-2.6.11-lorenzo/kernel/configs.c | 2 +- linux-2.6.11-lorenzo/kernel/kallsyms.c | 2 +- linux-2.6.11-lorenzo/kernel/resource.c | 4 ++-- 7 files changed, 30 insertions(+), 21 deletions(-)
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Quoted 6 lines · Lorenzo Hernández García-Hierro
-
/proc/ioports
-/proc/iomem
-/proc/devices
-/proc/cmdline
-/proc/version
-/proc/uptime
Quoted 8 lines
-
/proc/cpuinfo
-/proc/partitions
-/proc/stat
-/proc/interrupts
-/proc/slabinfo
-/proc/diskstats
-/proc/modules
-/proc/schedstat
The same "this forces people to run system monitoring tasks as root, potentially opening themselves up to security holes" comment applies to this patch.
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 3 lines · Rik van Riel
The same "this forces people to run system monitoring tasks as root, potentially opening themselves up to security holes" comment applies to this patch.
That's because the patch is split up, those bits are on the proc_misc one.
I agree, btw. ;)
Adding a "trusted user group"-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks.
Cheers,
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Quoted 4 lines · Lorenzo Hernández García-Hierro
Adding a "trusted user group"-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks.
I'd rather see something like this implemented as an LSM module - or better yet, an SELinux security policy.
There's no need to sprinkle security policy all over the kernel.
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 9 lines · Rik van Riel
Quoted 4 lines · Lorenzo Hernández García-Hierro
Adding a "trusted user group"-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks.
I'd rather see something like this implemented as an LSM module - or better yet, an SELinux security policy.
For this purpose I (re)submitted a patch originally made by Serge E. Hallyn that adds a hook in order to catch task lookups, thus, providing an easy way to handle and determine when a task can lookup'ed.
It's at:
http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch
vSecurity currently provides support for it (optional).
SELinux policy can handle in a much more fine-grained these restrictions, just that it's still something that not all people can deploy without some special effort and "tweak up" (if their system doesn't provide support for it, of course, currently Red Hat has done a great job in that terms).
Quoted 3 lines
There's no need to sprinkle security policy all over the kernel.
I completely agree.
Cheers,
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Quoted 7 lines · Lorenzo Hernández García-Hierro
For this purpose I (re)submitted a patch originally made by Serge E. Hallyn that adds a hook in order to catch task lookups, thus, providing an easy way to handle and determine when a task can lookup'ed.
It's at:
http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch
Quoted 7 lines
vSecurity currently provides support for it (optional).
SELinux policy can handle in a much more fine-grained these restrictions, just that it's still something that not all people can deploy without some special effort and "tweak up" (if their system doesn't provide support for it, of course, currently Red Hat has done a great job in that terms).
To be precise, SELinux assigns security labels to /proc inodes (/proc/pid inodes are labeled based on the associated task label, and other /proc inodes are labeled based on the policy configuration), and controls access based on the policy. It can e.g. prevent a process in one security domain from accessing anything under /proc/<pid> for a process in a different domain, but not from seeing the top-level entry in /proc itself (as it doesn't do any kind of directory filtering).
Signature · 2 lines
Stephen Smalley <[email protected]> National Security Agency