[PATCH 0/7] procfs privacy

[PATCH 0/7] procfs privacy

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

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 <lorenzo@gnu.org>
---

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 <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/7] procfs privacy

[Rik van Riel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 678 bytes --]

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

Re: [PATCH 0/7] procfs privacy

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

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 <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/7] procfs privacy

[Rik van Riel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 686 bytes --]

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

Re: [PATCH 0/7] procfs privacy

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

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 <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/7] procfs privacy

[Stephen Smalley]

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 <sds@tycho.nsa.gov>
National Security Agency