VFS: Dynamic umask for the access rights of linked objects

From: Hauke Laging
Date: Tue Feb 28 2006 - 21:26:32 EST


Hello,

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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx).


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.


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.


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.


Best regards,

Hauke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/