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]

Message-ID: <m1hbtj7xgj.fsf@fess.ebiederm.org>
Date:	Wed, 28 Oct 2009 19:20:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pavel Machek <pavel@....cz>
Cc:	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 <pavel@....cz> writes:

> Hi!
>
>> >> > 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.)
>> 
>> Assuming you have permission to open it read-write.
>
> Please see the bugtraq discussion.
>
> It works even if you would not have permission to write to it with
> /proc unmounted.
>
>> >> 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.
>
> So, there's "surprise" that gives _you_ write access to my files. You
> agree that it is surprising, and you would not have write access to my
> file if /proc was not mounted.

I also find it a surprise you would ever make a file world writable.

I find it a surprise that in any application that cared you would allow the
file to be opened, or passed through a unix domain socket and then have
the permissions changed.

> Call it "security surprise" if you prefer. But many people call it
> "security hole".
>
>> Do you know of any cases where this difference matters in practice?
>
> No. Do you have a proof that it does not matter anywhere?
>
>> It looks to me like it has been this way for better than a decade
>> without problems so there is no point in changing it now.  
>
> Unix compatibility?

Thinking about this proc fundamentally gives you the ability to create
(via open) a new file descriptor for a file you already have open.

That is the design and things are working by design.

I do see a security issue in your example, but the security issue I
see is how you have chosen to use the linux facilities, that have been
there for ages.  Facilities cloned from plan 9 and apparently
available in slightly different forms on many unix variants existence.
/dev/fd/N is not a linuxism.

To close this whole would require some sort of stacking inode that
when opened opened the real fs inode.  With all kinds of convolutions
and complications.  Just to close the issue that some idiot might
give someone a fd to a world writeable file that they don't want
them to open.

Given this is an old well established facility with a long tradition,
that does not appear to be easy or simple to exploit.  I believe the burden
of proof has not been met to say the design has a security issue.

I certainly am not interested in debugging or maintaining the stacking
inode code that would be necessary to close this theoretical corner
case.  There are much more real bugs that need attention.

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