linux-kernel - Re: symlinks with permissions

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:	Wed, 28 Oct 2009 09:34:26 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Pavel Machek <pavel@....cz>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Jan Kara <jack@...e.cz>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
	jamie@...reable.org
Subject: Re: symlinks with permissions

Pavel Machek wrote:
> On Tue 2009-10-27 21:15:54, Eric W. Biederman wrote:
>   
>> Pavel Machek <pavel@....cz> writes:
>>
>>     
>>> On Mon 2009-10-26 13:57:49, Trond Myklebust wrote:
>>>       
>>>> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote:
>>>>         
>>>>>   That's what I'd think as well but it does not as I've just learned and
>>>>> tested :) proc_pid_follow_link actually directly gives a dentry of the
>>>>> target file without checking permissions on the way.
>>>>>           
>>> It is weider. That symlink even has permissions. Those are not
>>> checked, either.
>>>  
>>>       
>>>> I seem to remember that is deliberate, the point being that a symlink
>>>> in /proc/*/fd/ may contain a path that refers to a private namespace.
>>>>         
>>> Well, it is unexpected and mild security hole.
>>>       
>> /proc/<pid>/fd is only viewable by the owner of the process or by
>> someone with CAP_DAC_OVERRIDE.  So there appears to be no security
>> hole exploitable by people who don't have the file open.
>>     
>
> Please see bugtraq discussion at
> http://seclists.org/bugtraq/2009/Oct/179 .
>
> (In short, you get read-only fd, and you can upgrade it to read-write
> fd. Yes, you are the owner of the process, but you are not owner of
> the file the fd refers to.)
>
>   
>>> Part of the problem is that even  if you have read-only
>>> filedescriptor, you can upgrade it to read-write, even if path is
>>> inaccessible to you.
>>>
>>> So if someone passes you read-only filedescriptor, you can still write
>>> to it.
>>>       
>> Openly if you actually have permission to open the file again.  The actual
>> permissions on the file should not be ignored.
>>     
>
> The actual permissions of the file are not ignored, but permissions of
> the containing directory _are_. If there's 666 file in 700 directory,
> you can reopen it read-write, in violation of directory's 700
> permissions.
> 									Pavel
>   

There is no security violation here. Consider the case where
the file is unlinked after it is opened. What directory permissions
would matter in that case? Or what about the case where the file
has a link count of 2, say /a/foo and /b/ish are hard links. If
/a is 777 and /b is 700 what would your position be regarding
the file descriptor obtained by opening /b/ish? The path name is
an ethereal convenience and once traversed has no bearing on the
security state of the object. You need to change the semantics
of Linux (and Unix) file systems for your concern to make any
sense at all.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/