lkml.org 
[lkml]   [2006]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: VFS: Dynamic umask for the access rights of linked objects
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-01 03:48    [W:0.051 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site