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]
Date: Sat, 24 Oct 2009 20:19:48 +0400
From: Dan Yefimov <dan@...htwave.net.ru>
To: anton.ivanov@...-begemot.co.uk
Cc: Matthew Bergin <matt.bergin@...mail.com>,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on	Linux

On 24.10.2009 10:47, Anton Ivanov wrote:
> Following your logic we should all abandon directory permissions and
> stick to file-only ones. Hmm... Dunno, probably the blood level in my
> coffee subsystem is too high this morning, but I do not quite relish
> that idea.
>
I didn't affirm that. I only told, that directory permissions can't in fact 
restrict access to the file it contains, they can only hamper accessing that 
file via that directory.

> There is a very valid case of trying to restrict access via directory
> permissions. Suppose you have a binary program that uses its own
> directory but for whatever reason keeps scribbling in files with wrong
> permission in it. While I cannot think of a current example, out of the
> older ones at least one of the Word Perfect versions for linux used to
> do that.
>
> By tightening up the protection on the directory the sysadmin can
> mitigate the problem. It is in fact the standard way of doing this.
>
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?
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.
-- 

Sincerely Your, Dan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ