[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Symlink vulnerabilities
- To: raju@xxxxxxxxxxxxxxx
- Subject: Re: [Full-disclosure] Symlink vulnerabilities
- From: James Condron <james@xxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 22 Oct 2011 10:14:34 +0100
On 22 Oct 2011, at 07:06, Raj Mathur (राज माथुर) wrote:
>
>
> At first sight, the best option from that point of view seems to be a
> per-user tmp under /tmp/$USER/ and mount /tmp noexec, nosuid. If you
> choose the ~$USER/tmp option, you'll probably have to do some userfs
> jugglery to achieve the same objective.
Actually, no; per user /tmp could only be accomplished, without a major
redesign and without breaking almost every application, by turning /tmp into a
pseudofilesystem a la procfs. Consider /proc/self for instance, accessing it
runs a subroutine which first must get the PPID of the stat() to work out which
information the user wants.
As such /tmp must stay where it is to ensure backwards compat (Otherwise you
introduce a new /tmp directory with no benefit) but where the UID of the caller
determines to where the actual /tmp directory links to. Dynamic symlinking, if
you've ever done any fuse programming. In which case from a security point of
view we use ~/.tmp or similar.
This solves a couple fo problems further; it allows for greater control of what
can and cannot be done, nosuid is effectively covered, noexec can be enforced,
and only root can see other people's /tmp if we implement it correctly.
As an aside; we generally mount /tmp over the loopback for obvious reasons.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/