> > The following patch was originaly for 2.0.32 by solar@false.com. I ported
> > it to 2.1.71 and separated it from another patch that came with it.
>
> This isnt a good fix in some ways. Firstly there are programs that depend upon
> symlinks in /tmp, secondly it doesnt seem to agree with the unix standard.
It does allow symlinks in /tmp. Which unix standard are you referring to?
> Thats not to say it isnt a good toy to have around on an insecure box, but
> it shouldnt be a standard thing.
I was thinking about it today and I think the way the problem is solved
right now is not good. A user can make an symlink intended for an attack
without any complaints by the kernel. Then if root tries to write to a
file in /tmp that has been redirected with a user symlink, a permission
denied results and the script to be run by root fails. Not good.
Maybe a better way to do things would be to not allow certain symlinks in
/tmp or other +t directories:
Symlinks in +t dirs must satisfy the following criteria if created by a
regular user not member of group root:
1. They cannot be absolute (i.e. they cannot begin with /)
2. They are not allowed to point to a higher directory
(Maybe forbid ".." in symlinks?)
Are there any reasons this would not work?
And maybe the functionality should be switchable on and off by writing to
a file in /proc/sys/kernel/xxxx ?