[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /proc filesystem allows bypassing directory permissions on Linux



[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@xxxxxxxxxx
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov@xxxxxxxxxx>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715