linux-kernel - Re: procfs: boot- and runtime configurable access mode for /proc/<pid> dirs

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] [day] [month] [year] [list]

Message-ID: <20110526105647.GD11521@ZenIV.linux.org.uk>
Date:	Thu, 26 May 2011 11:56:47 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Daniel Reichelt <debian@...htgeist.net>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: procfs: boot- and runtime configurable access mode for
 /proc/<pid> dirs

On Fri, Mar 25, 2011 at 02:24:48PM -0700, Christian Kujau wrote:
> 
> Not sure If I understand correctly, but:
> 
> On Thu, 24 Mar 2011 at 20:37, Al Viro wrote:
> > Bull.  /proc/<pid>/foo contents is sensitive, your patch doesn't do
> > you any good.  fork(), open /proc/<child's PID>/foo in parent, then
> > exec suid-root binary in child.
> 
> ...you would have to roll your own suid-root binary to be able to look 
> into other /proc/PID directories, no? But making a binary suid-root 
> requires root to begin with.

No.  You could look into /proc/PID/foo of process running a suid-root binary
that you have execve()'ed.  A binary that had been there legitimately.  If
these files have sensitive contents, you have a bad problem on hands (and we
had quite a few of those); IOW, you need to do checks at read(2) time, since
the identity of owner can change between open() and read().  And if you do
those checks there, you don't need to care about open-time checks at all,
since any attempt to do IO will be rejected anyway.
--
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/