Re: user flags in public temp space (was Re: chflags() [heads up])

[deraadt () CVS OPENBSD ORG (Theo de Raadt)]

> In some mail from Theo de Raadt, sie said:
> [...]
> > > a) Root should not use /tmp.  Root is root and, as the proverbial
> > > 800-pound gorilla, can make temporary files wherever it pleases.
> > > FreeBSD, for example, seems to be doing a lot in /var/run, which is
> > > root-owned, and not world-writable.  At least root should use
> > > subdirectories of /tmp and test to see if it can mkdir(1) them before use
> > > (see OpenBSD2.5's /etc/security, for example).
> >
> > As much as possible, we've now killed almost all of the /tmp races in
> > the system, so root is as safe as any other user.  Even gcc now plays
> > things safe, it appears.  But /tmp problems keep occuring in packages
> > which people add to the system.
>
> If you're designing a software package, want to use temporary files and
> directories but you need the names to be the same every time, where do
> you put them ?

Not in a world-writeable directory.  I declare that almost always a
poor design choice in new software.  Instead, use a .* file or
directory in the user's home directory for that, but key the files
with with a hostname and a pid or such so that things are safe in a
network filesystem environment.

In general however, directories are rarely a problem, since mkdir(2)
is atomic.  But watch your permissions; do not make the same mistake
made with /tmp/.X11-unix.

> Are you required to use open(O_CREAT|O_EXCL) for files
> in /tmp ?

In any directory which a possible attacker could write files, this is
the only safe way to play.  Sorry.  /tmp isn't the only one; go look
at /usr/local/lib/emacs/lock (which doesn't even have the t bit set...)

> Apart from the ability to exchange files between users with
> /tmp, having private /tmp's for each uid using the system (with a non-
> world writeable /tmp) has a lot of merit which I hope someone will someday
> properly explore - i.e. there exist programming languages in which the
> buffer overflow is a non-event, now we need an operating system design
> where the /tmp file race-condition is a non-event.

Perhaps.  But watch what you ask for, because there is software out
there that by itself that swaps uid's while playing (safely) in /tmp.
Any change like this can cause new problems to crop up...