linux-kernel - Re: symlinks with permissions (fwd)

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: <4AE922F9.5020506@schaufler-ca.com>
Date:	Wed, 28 Oct 2009 22:07:05 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Pavel Machek <pavel@....cz>
CC:	kernel list <linux-kernel@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: symlinks with permissions (fwd)

Pavel Machek wrote:
> (I forgot to cc the list)
>
> From: Pavel Machek <pavel@....cz>
> To: "Eric W. Biederman" <ebiederm@...ssion.com>
> Subject: Re: symlinks with permissions
> X-Warning: Reading this can be dangerous to your mental health.
>
> Hi!
>
>   
>>>>> 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.
>>>       
>> I can see how all of this can come as a surprise.  However I don't see
>> how any coder who is taking security seriously and being paranoid about
>> security would actually write code that would have a problem with this.
>>
>> Do you know of any cases where this difference matters in practice?
>>     
>
> Actually yes, see the bugtraq post. guest was able to write to my file
> when I expected that file to be protected.
>
> According to the bugtraq discussion, people expect directory
> permissions to work.

Gawd, I hate to say this, but people have been improperly educated
if they expect directory permissions to behave thusly. You can not
count on the permissions on a directory to protect access on a file
that the directory contains a reference to. Hard links. Mount points.
/proc/8675309/fd. Passing file descriptors over sockets. Fork, for
heaven's sake. That's not how Linux directories really work.


>  /proc currently breaks that. I bet there are few
> systems in the wild that have permissions set up like that, but it is
> not easy to actually find such systems.
>
> Better fix it...
> 								Pavel
>   


Well, /proc/8675309/fd is a silly notion, but it's been around
long enough that you are going to have trouble getting rid of it
and doing so wouldn't solve the "problem" in any case.

--
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/