OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubertuumail.gov.bc.ca)
Date: Tue Jun 06 2000 - 23:24:34 CDT

In message <NDBBJDFPGLMLFHLNEEOMCEIGFMAA.usebsdfree.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.Schubertosg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message