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] [day] [month] [year] [list]
Date: Tue, 27 Oct 2009 02:54:05 +0300
From: Dan Yefimov <dan@...htwave.net.ru>
To: isara.beaumont@...glemail.com
Cc: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

On 26.10.2009 23:05, Isara Beaumont wrote:
> Dan Yefimov said:
>
>>> I do not think mounting /proc should change access control semantics.
>>>
>> It didn't in fact change anything. If the guest created hardlink to that file in
>> a unrestricted location, what would you say? Procfs is in that respect just
>> another sort of hardlinks, whether you like that or not. If you didn't in fact
>> restrict an access to the file, you're on your own.
>
> (1) This is WRONG, and I find it interesting that nobody bothered to check
> or test this. The POSIX standard mandates that link() shall fail if
> the user has no search
> permission for any of the directories in the path prefix of oldpath or newpath.
>
> Therefore, setting the directory permission to 0700 protects from hardlink
> creation (read that again!) and this bug in the /proc filesystem
> indeed lead to a
> change in access control semantics. Under POSIX, the file IS unwriteable,
> because it is protected by the permissions on the parent directory.
>
> (2) While it's irrelevant for his argument, the script by Pavel Machek has a
> race condition. The 'chmod 700 /tmp/my_priv' should be done before the
> file is created, not
> afterwards. Otherwise there is a window where the file exists, but hardlink
> creation is not prevented by the directory permissions.
>
Your (2) contradicts to (1) and confirms what I told, if you didn't notice that.
-- 

Sincerely Your, Dan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ