Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [RFC][PATCH] procfs: add privacy options | Date | Mon, 24 Jul 2006 15:07:04 -0600 |
| |
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/
| |