linux-kernel - Re: [RFC][PATCH] procfs: add privacy options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jul 2006 15:07:04 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Rene Scharfe <rene.scharfe@...fire.ath.cx>
Cc:	linux-kernel mailing list <linux-kernel@...r.kernel.org>,
	Andrew Morton OSDL <akpm@...l.org>,
	Albert Cahalan <albert@...rs.sourceforge.net>,
	Wolfgang Draxinger <Wolfgang.Draxinger@...pus.lmu.de>,
	Bodo Eggert <7eggert@....de>,
	Al Viro <viro@...celfarce.linux.theplanet.co.uk>
Subject: Re: [RFC][PATCH] procfs: add privacy options

Rene Scharfe <rene.scharfe@...fire.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/