Bugtraq mailing list archives

Re: /proc filesystem allows bypassing directory permissions on Linux


From: Anton Ivanov <arivanov () sigsegv cx>
Date: Sat, 24 Oct 2009 17:59:08 +0100

[snip]

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?

There have been cases and quite a few. 

My first thoughts were about Word Perfect. Actually it is just a
representative of a wider class of apps there. The semantics of locking
on Windows and Unix differ and when apps get ported (especially using a
toolkit) people do not account for the advisory nature of Unix flock().
As a result files that were reasonably safe in the original environment
due to OS-level exclusive locking stop being so on the Unix port. 

Also, while it is a wonderful position to stand up and proclaim that
application is broken in a commercial environment you quite often have
no choice but to bolt it down to the maximum extent possible until the
developers fix it and directory permissions is the valid way of doing
so.

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.

The perms are definitely broken and without a code audit on procfs I
would not bet that this is limited just to this rather obscure test
case. 

To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.

Cheers,

-- 
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aivanov () sigsegv cx
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov () sigsegv cx>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715



Current thread: