[lkml]   [2006]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] procfs: add privacy options
    Rene Scharfe <> 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-24 23:11    [W:0.022 / U:2.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site