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: <4AE5981E.10108@lightwave.net.ru>
Date: Mon, 26 Oct 2009 15:37:50 +0300
From: Dan Yefimov <dan@...htwave.net.ru>
To: psz@...hs.usyd.edu.au
Cc: bugtraq@...urityfocus.com, pavel@....cz
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

On 26.10.2009 13:54, psz@...hs.usyd.edu.au wrote:
> Dear Dan,
>
>> ... in authentic kernels /proc/<PID>/fd/<FD>  are symlinks ...
>
> They appear to /bin/ls as symlinks, but observation suggests that they
> "act" as hardlinks. Could that be fixed somehow? (I did look at the
> kernel fs/proc/base.c but did not make much sense to me...)
>
Just looked more carefully at fs/proc/base.c. That behavior is due to 
proc_fd_info() called from proc_fd_link() obtains file->f_path, that in turn 
contains the reference to the open file dentry and hence inode. That's exactly 
why those symlinks behave as hardlinks. This behavior assumes, that if you were 
able to open the file, you've all necessary transition permissions to access 
it's inode. But in order to follow them you need privileges to read the process 
memory, which hardly restricts the impact of this behavior. I don't think this 
should be fixed, since /proc/<PID>/fd/ is mainly for debugging purposes.
--

Sincerely Your, Dan.