Date: Tue, 06 Jun 2000 21:24:34 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: "mouss" <usebsd@free.fr> Cc: "Matthew Dillon" <dillon@apollo.backplane.com>, "Peter van Dijk" <petervd@vuurwerk.nl>, freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <200006070424.e574Od303232@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 07 Jun 2000 05:33:20 %2B0200." <NDBBJDFPGLMLFHLNEEOMCEIGFMAA.usebsd@free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <NDBBJDFPGLMLFHLNEEOMCEIGFMAA.usebsd@free.fr>, "mouss" writes: > > Matthew Dillon wrote > > > > It should be /var/tmp. > > yes. and if ever someone thinks it should go to /usr/tmp, then I see > no reason to have a /var. /usr/tmp has been historically (recent history) symlinked to /var/tmp. Agreed, why have another temporary directory? > > also, the BSD/OS mfs proposal is not that god. This limits the size of /tmp, > and uses mfs for things that do not need to be in mfs. > the first thing I used to do on BSD/OS was to remove the mfs mount and to > softlink /var/tmp to /tmp. I disagree with this. /tmp is cleared at boot while /var/tmp is not. The reason for this is to have files remain across boot. mfs is generally (arguably on some O/S's) faster than writing data to disk. (If writing to disk is faster than using mfs, assuming there's enough memory to support a decently sized mfs, then there's something seriously wrong with the O/S). Some operating systems by default, e.g. Solaris, use mfs (tmpfs) for /tmp. I happen to like the separation of the two. Having more temporary filesystems than we already have is obviously ridicules. 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. That being said, compatibility with legacy applications will be broken so once again we're stuck with a shared temporary filesystem. But I digress. > > > > It's bad enough that some bozo created two > > standard locations for temporary files (/tmp and /var/tmp), we don't > > want to add a third. > > and may be someday, we'll have a /usr/local/tmp, /usr/src/tmp, ... > yes, ther's an opportunity for a tmp dir in every directory, but that's > not a sufficient reason to create it. one could also say that many tmp dirs > are needed, > just to "organize" that tmp stuff. then you'll see /TMP, /Tmp, ... /TEMP, > /WINDOWS/TEMP. > and why not /*/"temporary internet files"... > > only one tmp dir is needed, and it's called a tmp dir. ther's no need for > "find / |grep tmp" > to find temporary files. I don't think anyone is suggesting this. If they are, then they need to see a good psychiatrist or stop using mind altering drugs. Anyone in their right mind would make a mess like this. I think that the person who originally started this thread was ignorant and didn't understand the difference between /tmp and /var/tmp. Users on the other hand can set environment variables to put temporary files to anywhere they have write access to. If a user is afraid of some shared temporary filesystem race condition in an application or a symlink exploit they can already create a ~/tmp and set TMP, TMPDIR, or any other environment variable to anything they want, assuming they can write to it. In short, you may have this problem and not even realize it. > > > > Frankly, it makes no sense to have more then one. > > I fully, completely, infinitely, ..., agree. Unless you want to have temporary files to be saved across boot. Now if they're not removed at boot, what makes them temporary? In the case of /var/tmp, if they're older than N days or haven't been access for N days, they're nuked. This of course raises other security issues. > > >In every machine I've ever configured for the last umpteen years I've > created > > a /var/tmp partition and softlinked /tmp to it. > > so did I. I even think this should be the default... for me /var is the > partition > that contains the "other" stuff, and thus the "remaining" space. From a security standpoint there should be no world writable directories whatsoever, even with the sticky bit turned on, however in today's environment, given that compatibility with other unixces might be desireable, this may be unreasonable. At the very least root and semi-privileged accounts, e.g. oracle, should absolutely never use a directory that other users can write to. In the long term I think an admirable goal would be to eliminate /tmp and /var/tmp forever. I believe Theo and co. at OpenBSD are working toward this ultimate goal. If anyone thinks I've contradicted myself in this note, my intention was to open the discussion to a wider range of possibilities than is currently being discussed. On one hand we have compatibility with other UNIX systems out there and in the other extreme we have a more secure solution. Then of course there's the middle ground, wherever that may be. 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?200006070424.e574Od303232>