lkml.org 
[lkml]   [2006]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH] procfs: add privacy options
Date
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Roughly a year ago I sent out a few patches intended to give normal
> users a bit of privacy in their parts the /proc filesystem. The first
> incarnations were described as rootkits, later ones met a bit less
> resistance. :-D Then I got distracted; the patches never went anywhere.
> Now that Wolfgang Draxinger asked about something like it, I think it's
> time to revive the thing.
>
> So I dusted off the last version and ported it to 2.6.18-rc2. It's
> inspired by the Openwall kernel option CONFIG_HARDEN_PROC. The patch
> introduces two kernel boot options, proc.privacy and proc.gid. They
> can be used to restrict visibility of process details for regular users.
>
> Setting proc.privacy to 2 let's users only enter their own /proc/<pid>
> directories, while a setting of 1 allows them to enter root's process
> dirs, too. In this way tools like pstree keep working, because all
> parents of a user process up to init (e.g. sshd, getty, init itself)
> keep being visible. It's a rough heuristic, but I think it makes sense:
> root can alway see you, and in turn you can see root. If root is shy he
> can set proc.privacy=2; the price is that his users get slightly strange
> results from pstools etc.
>
> proc.gid is the GID of the group that has read and execute access to
> all /proc/<pid> dirs, regardless what the file mode and group ownership
> says. Unlike in Openwall and in my previous attempts I implemented it
> as a .permission function this time. That means owner and group
> attributes of /proc/<pid> dirs are not changed; tools like top and ps
> can still gather euid and egid that way.
>
> Normally .permission functions are not the way to implement access
> control in procfs, because the condition on which to grant/deny access
> could change between open and actual access (think setuid). This is of
> no concern in the case of this patch, because the it unconditionally
> grants some access to the members of one group, independent from /proc
> data or meta-data.
>
> I briefly tested the patch on a Fedora Core 6 test1 system on top of
> a vanilla 2.6.18-rc2 kernel and it seems to work as described here: it
> boots, it restricts, and if I'm in the right group I see every process
> in ps' output again.
>
> Questions, suggestions or even flames are very much welcome. Did I
> manage to do something stupid in these few lines of code?


I don't really like filesystem magic options as kernel boot time options.
Mount time or runtime options are probably more interesting.

How is it expected that users will use this?

A lot of the privacy you are talking about is provided by the may_ptrace
checks in the more sensitive parts of proc so we may want to extend
that.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-24 23:11    [from the cache]
©2003-2011 Jasper Spaans