On Thu, 26 Apr 2001, Donaldson, Matthew wrote: > If each user has a separate /tmp directory, unwritable by anyone else, > this is no longer possible, so far as I can see. Just to let you know, there were a discussion about context-sensitive /tmp solutions something approx. two years ago on BUGTRAQ, with two suggested solutions (well, or "workarounds", as the solution is not to use /tmp in insecure way): - euid-sensitive /tmp pseudo-filesystem, redirected e.g. to ~/tmp (do not know if there were any implementations, but that is actually pretty neat idea to use fs driver similar to /proc) - euid-sensitive operations to redirect /tmp in the same manner (I even made some Linux 2.0 module do implement it; it was called redtmp and should be somewhere in archives) Both of them would break many programs, like X server-client connectivity, as mentioned in this thread. One of suggested workarounds was to redirect any operations that involve creating fs objects in per-user /tmp space, and handle all others (namely attempts to open w/o O_CREAT, connect etc) by doing lookup in per-user /tmp space, and, if not found there, in root /tmp space. It causes some risk that can be avoided by properly setting umask for root. There are some possible issues with using ~/tmp, as well - not every user has to have writable ~ directory, sometimes user home dirs are mounted via nfs and that would cause additional load, and so on. Moreover, it is hard to choose between using euid or uid for switching. Using euid would probably break even more setuid programs. But using uid would allow user to run setuid applications with /tmp redirected to a directory which has no sticky bit, and to perform nasty attacks. -- _______________________________________________________ Michal Zalewski [lcamtufat_private] | [security] [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};: =--=> Did you know that clones never use mirrors? <=--=
This archive was generated by hypermail 2b30 : Thu Apr 26 2001 - 16:52:00 PDT