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: <4AE32924.50103@lightwave.net.ru>
Date: Sat, 24 Oct 2009 20:19:48 +0400
From: Dan Yefimov <dan@...htwave.net.ru>
To: anton.ivanov@...-begemot.co.uk
Cc: Matthew Bergin <matt.bergin@...mail.com>,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on	Linux

On 24.10.2009 10:47, Anton Ivanov wrote:
> Following your logic we should all abandon directory permissions and
> stick to file-only ones. Hmm... Dunno, probably the blood level in my
> coffee subsystem is too high this morning, but I do not quite relish
> that idea.
>
I didn't affirm that. I only told, that directory permissions can't in fact 
restrict access to the file it contains, they can only hamper accessing that 
file via that directory.

> There is a very valid case of trying to restrict access via directory
> permissions. Suppose you have a binary program that uses its own
> directory but for whatever reason keeps scribbling in files with wrong
> permission in it. While I cannot think of a current example, out of the
> older ones at least one of the Word Perfect versions for linux used to
> do that.
>
> By tightening up the protection on the directory the sysadmin can
> mitigate the problem. It is in fact the standard way of doing this.
>
If the application sets wrong permissions on files, it is by definition broken. 
Yes, setting more restrictive directory permissions can to some extent mitigate 
the problem, but not really fix it. What if that application is used by multiple 
users?
The problem raised in the original mail is to some extent artificial, as the 
only users able to access /proc/<PID>/fd/ are the user with the same UID, as the 
process EUID, and root, and if the process is either setuid or setgid, 
/proc/<PID>/fd of that process is accessible only by root. Not to tell about 
that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't 
understand, how the original reporter managed to gain access to the file in the 
restricted directory using that symlink.
-- 

Sincerely Your, Dan.