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

[strange () CULTURAL COM (Strange)]

On Thu, 5 Aug 1999, Theo de Raadt wrote:
> > Mike Frantzen (frantzen () expert cc purdue edu), Kevin Kadow
> > (kadokev () msg net), and I were discussing the implications of the above
> > revision to vfs_syscalls.c and realized it must be that root does not
> > automatically override user-set flags -- root must first unset the flag.

> That is correct.

> That would count for all writeable directories, which basically comes
[...]

I agree -- I should have been more clear when I said all /tmp type
directories.  Issues abound, ranging from many ISPs' delete-the-user
scripts to other kinds of system cleanup.  The issue is worthy of
4.4-lite-BSD-derivative-wide resolution.

[sample motd issue]

> This problem was actually fixed earlier on today, after it was pointed
> out by Hugh Graham a few days ago:

[...]

> Sorry, you but weren't first ;-)

Rats.

Er, I mean, raadts.  (Keeping with the pun theme, here.)

Actually, we were pretty darn sure we would not be the first to see the
implications, which is part of why we decided to summarize our thoughts
and try to bring the issue to broader debate (apart from OS-specific
discussions).

> You may want to check their implementations of locate.updatedb(8).  We
> found relevant /tmp races in there before, as well.

Your point highlights that the issue is worthy of debate across all
4.4-lite derived OSes -- any real solution that will provide software
authors a degree of something to rely on across the *BSD spectrum is
likely to be something akin to a change in the user flags' workings either
in the fs generally (perhaps via mount options) or per run level, or
generally across run levels for some flags (your nodump example noted).
Not an undertaking for hasty decision-making, as your discussion makes
clear.

> > Possible long-term fixes we've theo-rized:

> A strange pun.

Yes, well, touche'...

[Getting the root user (and other users) out of the predictable-file
in tmp habit]

> 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.

*yes*

Mudge's watch (see <http://www.l0pht.com/advisories/watch.txt> ) reveals a
lot of these in action (not to mention one can read many packages' source
and one is likely to find some unnecessarily predictable use of a file in
a world-writable temp directory).

>       http://www.openbsd.org/cgi-bin/man.cgi?query=mkstemp&format=html
>       http://www.openbsd.org/cgi-bin/man.cgi?query=mktemp&format=html 
>
> Go check them out... we're trying to teach people.

:-)  I've been a convert for a while.  Anyhow, to the meat:

> > b) In rm(1), make the -f option clear user flags when rm -f is called
> > by root (not a bad workaround).
>
> Hugh recommended the same.  Considering the find /tmp stuff that
> happens in /etc/rc, I have been giving thought to adding a -F flag
> which would do that.  Unfortunately, from a system perspective, this
> is gross too.

Yes -- though the -F is a nice idea it just cures the rm(1) issue, leaving
other kinds of unlink, and chmods and so on around.  So it cures some --
but not all -- scripts with this problem, and does nothing for other kinds
of programs that make the same assumption about root's abilities.

The problem is that, as lumpy said, programmers are relying on root being
all-powerful, and that's not a good assumption.  The question is, should
the affected OSes adjust to be in line with that assumption generally for
some flags?  In some secure/runlevels?  On some mounted filesystems?
Should they not change, and programmers be pushed to check return values?
Portability (and security) will be helped greatly if the decision is made
across the 4.4-lite-ish BSDs.

> > c) Make root automatically override user-set flags (possibly will
> > create other complications for user-land programs relying on root
> > passing over such files).  This would be akin to Solaris 2.51 and 2.6's
> > ACLs.
>
> This should also probably be looked into a bit more, but currently I
> am leaning away from this being right.  It's a rather large change to
> the way flags work.  Do we also then make dump not honour user
> nodump.. oh, wait, dump is run by root.... no, that would not make
> sense, would it.  So it becomes somewhat inconsistant.  To some
> degree, securelevels are trying to make root more equal to users.

I agree, though there is a point where any *NIX OS remains at core the
superuser.  Perhaps user flags could be ignored in runlevel 0?  Perhaps
all but user nodump?  Inconsistent, as you say, and again, this seems
worthy of discussion across the BSDs.

> > d) Modify vfs_syscalls.c to disallow user-set flags on files in
> > directories the user does not own.
>
> This cannot work.  The user simply links the file into his own
> directory, sets the flag on the file, and deletes his link.  You've
> forgotten about the directory-entry vs. inode split that Unix has in
> it's filesystem.

Well, ok, we all had a nice set of synchronized head slaps after reading
that.

Now I just lean towards a variant of option c.  Root really should be
allowed to rely on being able to transparently override certain user flags
if root can remove those flags anyhow.  Not true of the user nodump flag,
I agree.  Nevertheless, I am not sure that such user flags should wag the
discussion of how root should handle user flags generally.  Possibly what
should happen does need to be examined per flag, messy as that seems?

I am expecting that our gracious moderator will be asking this discussion
to move to some general BSD development discussion forum soon.  Is there
an appropriate one?  comp.security.unix?

      -M