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: 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

Powered by blists - more mailing lists