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]

Date: Wed, 28 Oct 2009 22:31:54 +0000
From: Glynn Clements <glynn@...ements.plus.com>
To: psz@...hs.usyd.edu.au
Cc: dot@...at.at, matthew@...psky.org, bugtraq@...urityfocus.com,
	pavel@....cz
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

psz@...hs.usyd.edu.au wrote:

> > According to POSIX, if you open the directory with O_SEARCH then openat()
> > does not re-check search (+x) permissions.
> 
> My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
> But anyway... even if openat() does not re-check permissions, it should
> surely fail when in fact it does not have permissions? Surely, directory
> contents are not cached? Or, do you have an example (of a running OS)
> where openat() succeeds without permissions?

Linux 2.6.29.5 checks the directory permissions in openat(), but I can
believe that other platforms (particularly those with an O_SEARCH
flag) may not.

For files, permissions are checked during open(); they don't get
re-checked during subsequent operations on the returned descriptor.

E.g. if you successfully open() a file O_RDWR, the permissions aren't
re-checked for every read() and write(). If the permissions are
removed, read() and write() won't suddenly fail (note that neither
read() nor write() can fail with EPERM).

open() checks that the user has the necessary privilege, then records
that information in the descriptor for use by subsequent operations.

For consistency, I would expect directory descriptors to behave
similarly, i.e. open()ing a directory with O_SEARCH would check that
the user has search (+x) permission on the directory then record this
in the descriptor. A subsequent openat() would simply check the
descriptor, not the inode.

That Linux doesn't behave like this is an inconsistency, and is
probably related to the lack of an O_SEARCH flag, i.e. descriptors
only have flags for read and write permission, not directory search
permission.

AFAICT, there is no way to use open()+openat() for a directory with
mode 0111 (d--x--x--x) as you can't open() the directory (O_RDONLY
fails with EPERM, anything else fails with EISDIR).

-- 
Glynn Clements <glynn@...ements.plus.com>