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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ([email protected]).

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux