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: <4AE5C41F.4040502@lightwave.net.ru>
Date: Mon, 26 Oct 2009 18:45:35 +0300
From: Dan Yefimov <dan@...htwave.net.ru>
To: Pavel Machek <pavel@....cz>
Cc: peak@...o.troja.mff.cuni.cz, psz@...hs.usyd.edu.au,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

On 26.10.2009 18:26, Pavel Machek wrote:
> On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
>> On 26.10.2009 18:06, Pavel Machek wrote:
>>> On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
>>>> 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.
>>>
>>> guest certianly does not have permission to ptrace() pavel's
>>> processes, so...
>>
>> But guest has permissions to ptrace() his own processes. If we
>> remember your original report, he abuses input redirection of bash
>> run by himself. So again, there's no real security hole here.
>
> guest abuses ptrace permissions on his own processes to write to
> pavel's files... no, that obviously is not security hole :-).
>
guest abuses ptrace permissions on his own processes to write to ANY file open 
by his processes, whose permissions explicitly allow writing to it. Doesn't it 
trouble you, that guest's processes still retain open file descriptors and hence 
access to files, that you believe should no longer be accessible to those 
processes due to permissions you set?
-- 

Sincerely Your, Dan.