On Thu, 5 Aug 1999, Theo de Raadt wrote: > > Mike Frantzen (frantzenat_private), Kevin Kadow > > (kadokevat_private), 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:12 PDT