[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <hcbicj$qm4$2@taverner.cs.berkeley.edu>
Date: Thu, 29 Oct 2009 08:05:39 +0000 (UTC)
From: daw@...berkeley.edu (David Wagner)
To: linux-kernel@...r.kernel.org
Subject: Re: symlinks with permissions (fwd)
Casey Schaufler wrote:
>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.
1) Pavel's script takes care of hard links. I'm not familiar with
the mount points issue. I don't see how passing file descriptors over
sockets or fork() is relevant.
Pavel shows how a process can create its own directory, create a file
in that directory, and set up file permissions in such a way that it can
have a reasonable expectation that others will not be able to gain write
access to that file. As far as I can tell, that expectation was met,
up until the /proc mechanism under question was introduced. But the
/proc mechanism violates this expectation. Yes, Pavel's method does
protect against hard links.
2) If you think folks have been improperly educated, can you point to
the Linux documentation that says not to rely upon directory permissions
for security purposes?
There's plenty of stuff that relies upon directory permissions for
security, and it's important that they be able to do so.
Do you mean to suggest that having root do a massive "chmod a+rx" on
every directory on the filesystem can never introduce security holes?
That sounds to me like it would be an absurd statement, yet it seems to
follow logically from your claim about directory permissions. If one's
premises lead to absurd conclusions, perhaps the flaw is in the premises.
--
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/
Powered by blists - more mailing lists