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
([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.
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
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.
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
On Feb 28, 2006, at 22:54:15, Hauke Laging wrote:
> 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.
Feel free to write an LSM to do this, but it breaks POSIX specs a bit
and could cause problems with some programs, so it's not likely to
become the default behavior.
Cheers,
Kyle Moffett
* Kyle Moffett ([email protected]) wrote:
> On Feb 28, 2006, at 22:54:15, Hauke Laging wrote:
> >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.
>
> Feel free to write an LSM to do this, but it breaks POSIX specs a bit
> and could cause problems with some programs, so it's not likely to
> become the default behavior.
Solar Designer's Openwall Linux patch contains code for these types of
restrictions (at least since 2.2 if not earlier). Idea was stolen and
made into an LSM smth like 4 or 5 years ago. Neither of these have made
it upstream. Attempts have also been made to codify such restrictions
in SELinux policy. Polyinstantiation and per-process namespaces can be
done effectively with code that's now in mainline, and can mitigate much
of this risk.
thanks,
-chris
Hauke Laging <[email protected]> wrote:
> 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.
Right, some programs are broken.
[...]
> > 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.
Don't do that then. Programs running as superuser should always be extra
careful. Nothing (or nearly) should ever be run as "normal user" root.
Yes, root can shoot its feet at will. Always has been able to. Doing it by
blindly following a symlink planted in her home or in /tmp by the local
cracker-wannabe is just one (very minor) more way of doing so.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Tue, 28 Feb 2006, Chris Wright wrote:
> Solar Designer's Openwall Linux patch contains code for these types of
> restrictions (at least since 2.2 if not earlier). Idea was stolen and
> made into an LSM smth like 4 or 5 years ago. Neither of these have made
> it upstream. Attempts have also been made to codify such restrictions
> in SELinux policy. Polyinstantiation and per-process namespaces can be
> done effectively with code that's now in mainline, and can mitigate much
> of this risk.
Just to make the discussion complete, I point out to the paper about a
thing called RaceGuard, presented at USENIX some time ago -
http://www.usenix.org/events/sec01/full_papers/cowanbeattie/cowanbeattie.pdf
--
JiKos.