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 19:44:51 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Pavel Machek <pavel@....cz>,
	"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
Subject: Re: symlinks with permissions

Casey Schaufler wrote:
> Pavel Machek wrote:
> > 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?

That's an even worse security violation.

If you have a file opened read-only which is unlinked (and there's no
other file descriptors to it), it is impossible to modify the file
except through this quirk of /proc/NN/fd.  In traditional unix, it is
impossible to modify full stop.  Even root can't write to it.

Paths are in this discussion as an *example* of something that cannot
be done except through /proc/NN/fd.  Paths are not the issue.

As you've noticed, the same security hole occurs for files which have
been unlinked and don't have any path.

The real issue is gaining more access to an open file than you had before.

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

It depends on the flag passed to open() when the file descriptor is
obtained.  That's where the pseudo-symlink permission comes from,
which is what Pavel is getting it.

> The path name is an ethereal convenience and once traversed has no
> bearing on the security state of the object.

That's right.  The security state should depend _only_ on the
file open mode, that is O_RDONLY/WRONLY/RDWR/APPEND.

That is more or less what Pavel is saying too, because the
pseudo-symlink permission is calculated from the file open mode
(except for O_APPEND, which is why it shouldn't be done using the
pseudo-symlink permission).  Ignore the path aspect, it's just a distraction.

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