VFS: Dynamic umask for the access rights of linked objects

VFS: Dynamic umask for the access rights of linked objects

[Hauke Laging]

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


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

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

[Sam Vilain]

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.

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

[Hauke Laging]

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

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

[Kyle Moffett]

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

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

[Chris Wright]

* Kyle Moffett (mrmacman_g4@mac.com) 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

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

[Jiri Kosina]

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.

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

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

Hauke Laging <mailinglisten@hauke-laging.de> 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