Date: Wed, 07 Jun 2000 00:52:01 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: John Brazel <john@tellurian.com.au> Cc: Cy.Schubert@uumail.gov.bc.ca, freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <200006070752.e577qfD04339@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 07 Jun 2000 15:52:28 %2B0930." <200006070622.PAA25984@tellurus.tellurian.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006070622.PAA25984@tellurus.tellurian.com.au>, John Brazel write s: > > >From a security standpoint a shared temporary filesystem coupled with > > applications written as they are can be an invitation for compromise. > > Suggestions ranging from no temporary filesystem at all to > > subdirectories in /tmp for each user have been discussed on > > FreeBSD-security and BUGTRAQ for many years. Of course for root > > /var/run reduces the risk. The concept of a virtual temporary > > filesystem for each user, e.g. /tmp as and address space addressable by > > a single process group and only sharable by that process group or even > > a single process, might go a long way to mitigate some of the risk. > > What exactly ARE all the risks? At the risk of 'over-enthusiasm' > (for want of a better phrase), would a purpose-written, > security-oriented filesystem solve it? Symlinks, hard links, and race conditions are the risks. Mount flags for existing filesystems would another idea. > > Something like /tmp, but with an embedded sticky bit (permanently > set) and the inability to create symlinks (the symlink(2) syscall > would return ENOSYS for that filesystem). And, inability to create hard links, inability to execute, inability to create/use device files, pipes, sockets, etc. In short anything that could be used to "trick" an application to do anything or write to files it wasn't designed to do, would be required. This of course would limit the usefulness of /tmp and /var/tmp. Replacing /tmp & co. with a non-shared temporary filesystem approach (could be a tmp directory in the user's home directory) is the easiest and simplest approach to solve the /tmp problem. > > The question, of course, is, would this fix enough of the problems > to warrant all the effort? At the very least, backward compatibility > wouldn't be affected. Any solution would affect backward compatibility to one degree or another. For example, inability to create symlinks could be considered a compatibility issue for some applications -- limited compatibility issues. Limiting /tmp to only directories and non-executable regular files with only one link to them would have many more compatibility issues. Replacing /tmp with some other approach would have the most compatibility issues, none of which are insurmountable. As with many security models, it all depends on how much we're willing to give up to gain a secure system. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006070752.e577qfD04339>