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

Message-ID: <20110324203758.GF22723@ZenIV.linux.org.uk>
Date:	Thu, 24 Mar 2011 20:37:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Daniel Reichelt <debian@...htgeist.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: procfs: boot- and runtime configurable access mode for
 /proc/<pid> dirs

On Thu, Mar 24, 2011 at 08:18:54PM +0100, Daniel Reichelt wrote:
> Well, my patch is about modes of the pid-dirs themselves, not their
> contents. And it changes procfs' behaviour about modes both on initial
> creation and during revalidation on access. However flattening all the
> piddir's entries DOES pose a security risk. Have a look at the
> "traditional behaviour": piddir world-readable, however e.g.
> <pid>/environ isn't. Often it's a workaround for broken software to
> specify a password within an environment variable instead of by cmdline.
> Since up until now all processes including their full cmdlines are
> visible to everyone, environ must be considered more sensitive than a
> cmdline.

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.  At that point mode_t of any files
or directories does not matter anymore.

You *must* do whatever access checks at read(2) time for these files.
And if you do that, the checks at open(2) time do not matter.

In particular, /proc/*/environ does ptrace_may_access() on read(2) (with
a race fixed by today's merge, BTW).  It could very well be r--r--r--;
having it r-------- does not increase security at all.
--
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/