Re: VFS: Dynamic umask for the access rights of linked objects

[Sam Vilain <sam@vilain.net>]

Hauke Laging wrote:
> I tried to send this to the VFS maintainer but the address I found on 
> http://www.kernelnewbies.org/maintainers/ and in 
> my /usr/src/linux/MAINTAINERS seems not to exist any more 
> (viro@parcelfarce.linux.theplanet.co.uk).
> 
> The complete version of the following text ist avaiable at 
> http://www.hauke-laging.de/ideen/symlink-umask/konzept_en.html
> 
> the problem
> (At least) If applications store data in directories which are 
> write-accessible by other users then symlink attacks become possible. A 
> file is erased and replaced by a symlink. The (buggy) application can be 
> abused if it can read or write the linked-to file but the abusing user 
> cannot. These attacks are mostly denial of service attacks.

Of course this doesn't work if, like /tmp and /var/tmp are shipped as on 
every distribution, the directory has permissions 1777.

But go on...

> Solution
> The kernel should be extended by a function (which can be enabled and 
> disabled) which would solve the problem. The access rights of a symlink 
> are ignored but its creator is stored. The kernel should do additional 
> checks when determining whether a file system object can be accessed in 
> the requested way:
> 
> - Is the accessed object a symlink?
> 
> - Has the creator of the symlink got the access rights which the respective 
> process is requesting?
> 
> If the situation turns out to be critical then the kernel would deny the 
> respective rights. The process cannot access the file via the symlink 
> though it could have if it had tried to access it directly. The access 
> rights of the symlink creator (through the whole path, not just for the 
> file) would be used as a mask for the applications rights.

What problem you are trying to solve?  Why does it matter what the 
ownership of the symlink is?

> This approach does not solve every kind of this problem but should be quite 
> easy to implement. I don't want this mail to get too long so I have left 
> out some considerations about hard links. See the URL.

Reading the page, the considerations about hard links seem quite off the 
mark.  If somebody creates a hard link to one of your files, it *is* the 
same file, just with a different name.  So it becomes the same problem 
as the first one.

That is, if I understand what you're saying correctly.  It's not very 
clear.  You should at least describe your envisioned scenario in a step 
by step basis, highlighting your concerns.

But frankly, see the FAQ answer to "I have discovered a huge security 
hole in rm!"

Sam.