Am Mittwoch 01 März 2006 03:45 schrieb Sam Vilain:
> Of course this doesn't work if, like /tmp and /var/tmp are shipped as on
> every distribution, the directory has permissions 1777.
I had this idea after the announcement of such a security problem in an
antivirus software. The rpm package was buggy and set wrong rights for the
installation directory /usr/whatever. So this is a real-world problem.
In the German Usenet group for shell scripts this problem is mentioned from
time to time, too. It may arise if not so clever software works with "user
files" (e.g. in the home directories) and does not notice the symlinks.
> What problem you are trying to solve?
I want to prevent the case that superuser processes accidentally read or
write (system) files because they have been redirected there by a symlink
which has been created by a user who cannot access (or at least write)
these files hinself.
> Why does it matter what the ownership of the symlink is?
If the symlink has been created by root or the application itself then
there is no risk of abuse because both would have been able to cause the
intended damage themselves. The attacking user can create the symlink but
he cannot prevent his uid being stored with the link.
After all symlinks are not "bad by design" but can be dangerous under very
certain circumstances. These can be identified by the owner of the symlink
being less privileged than the accessing process.
> 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.
Your right with the fact but not with the conclusion: Because it is not
(reliably) possible to understand the situation after the hard link has
been created my approach for soft links does not work. Thus I had the idea
to solve this problem earlier, on link creation. At that moment you can
check what's up and disallow the operation if it looks strange.
> You should at least describe your envisioned scenario in a step
> by step basis, highlighting your concerns.
OK:
1) There is a process which superuser rights which will write to /foo/bar.
That may be a daemon writing its own file or some superuser/sudo process
which works on user files (and relies on the users to be nice - if aware
of the problem at all). The process may need superuser rights to collect
data for the user and stores it in the users home directory.
2) The attacking user need be able to write the target directory. This may
be due to a bug in the daemon software (or its installer) or even be
intended.
3) The user replaces the target file by a symlink to a file he cannot write
himself: ln -s /etc/passwd /foo/bar
4) The VFS determines that /foo/bar is a symlink and checks whether the
process may write to it. It may.
5) Under current circumstances the process would kill /etc/passwd now and
the system would be dead. In more complicated situations it may be
possible to make the process store certain data there or to read
unreadable files.
6) In my scenario the VFS would add a step after 4): It would check if the
symlink has been created by someone different from the process's uid and
from root. If so there is the risk of abuse and the access check would be
repeated for the symlink owner.
7) The VFS would find out that the symlink owner is not allowed to write
to /etc/passwd. Thus the write access is prohibited, even for a process
with superuser rights.
A part of this problem has to do with the "rm effect" but deleting
application files if the app's installer is to stupid to protect it is one
thing allowing to overwrite every system file by such a bug is something
different. The problem may be not very frequent but on the other hand the
implementation should be simple (steps 6 and 7).
Best regards,
Hauke
-
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]
