bugtraq - Re: /proc filesystem allows bypassing directory permissions on Linux

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: <20091027203404.GE9883@dragontoe.org>
Date: Tue, 27 Oct 2009 15:34:04 -0500
From: Derek Martin <code@...zashack.org>
To: Ansgar Wiechers <bugtraq@...netcobalt.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
 Linux

On Mon, Oct 26, 2009 at 07:37:38PM +0100, Ansgar Wiechers wrote:
> On 2009-10-24 Derek Martin wrote:
> > 1. It circumvents the fact that to write to a file, you MUST be able
> > to write to its directory, so that the file attributes can be updated.
> 
> Wrong, because the file's attributes aren't stored in the directory, but
> in the respective inode.

Ah, sorry, you're right, but if (as in the example) the user has no
permissions on the directory, he normally won't be able to write to
the file:

$ mkdir foo
$ cd foo
$ echo hi > bar
$ ls -la
total 12
drwxr-xr-x  2 user1 group1 4096 2009-10-27 16:22 ./
drwx------ 57 user1 group1 4096 2009-10-27 16:22 ../
-rw-r--r--  1 user1 group1    3 2009-10-27 16:22 bar
$ chmod 000 .
$ echo bye > bar
-bash: bar: Permission denied

The problem with the /proc interface is:

 - it is automatic (if /proc is mounted)
 - its file access semantics are not identical to the rest of the file system
   (e.g. they are not really symlinks, and they are not really hard
   links, and the link count is not incremented, and the average
   person will have no idea about their semantics).
 - it creates a pseudo-link with permissions which do not regard the directory
   access controls the user had to pass authorization checks to gain access.

I still think it's not a huge deal, but I also do think it's not a
total non-issue.  The fix seems clear and obvious to me:  The files in
/proc/$pid are shown with the "real" path they refer to, so obviously
the kernel retains that information.  Access to those files should be
checked against that real path, rather than the /proc/$pid path.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


Content of type "application/pgp-signature" skipped