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
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[email protected]>
---
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(-)
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Mon, 18 Apr 2005, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> - /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
The same "this forces people to run system monitoring tasks
as root, potentially opening themselves up to security holes"
comment applies to this patch.
--
"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
El lun, 18-04-2005 a las 15:27 -0400, Rik van Riel escribi?:
> 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,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Mon, 18 Apr 2005, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> 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.
--
"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
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribi?:
> On Mon, 18 Apr 2005, Lorenzo Hern?ndez Garc?a-Hierro wrote:
>
> > 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).
>
> There's no need to sprinkle security policy all over the
> kernel.
I completely agree.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Mon, 2005-04-18 at 22:18 +0200, Lorenzo Hernández García-Hierro
wrote:
> 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).
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).
--
Stephen Smalley <[email protected]>
National Security Agency