lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <4D741DF4-78F7-4531-A158-E8D82EE99AB3@zero-internet.org.uk> Date: Sat, 22 Oct 2011 10:14:34 +0100 From: James Condron <james@...o-internet.org.uk> To: raju@...ux-delhi.org Cc: full-disclosure@...ts.grok.org.uk Subject: Re: Symlink vulnerabilities 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/
Powered by blists - more mailing lists