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: <4AE5C9C8.5000403@lightwave.net.ru>
Date: Mon, 26 Oct 2009 19:09:44 +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:58, Pavel Machek wrote:
>>>>> 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
>
> I repeat: Show me how to gain write access without using /proc, and
> I'll agree with you.
>
By using hardlinks, as you were already told by two different persons.

> (To recap:
>
> While file permissions allow writing, directory permissions do not
> allow any access at all.
>
> guest has open file descriptor for reading.
>
> Trouble is that guest can upgrade file descriptor to one that allows
> writing.)
>
Enough substituting terms. guest doesn't upgrade file descriptors, he only gets 
new ones by using debugging features on his own processes.

> Can we continue on lkml?
>
No, I'm not in that list. The more, that Linux maintainers, AFAIK, already 
expressed their opinion. Thus continuing this discussion there can be considered 
importunate. If you want them to change their opinion, demonstrate the real, not 
artificially invented problem, that in fact demonstrates only file owner negligence.
-- 

Sincerely Your, Dan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ