From owner-freebsd-security Sun Mar 14 19:47:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id A97ED14DFB for ; Sun, 14 Mar 1999 19:47:09 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (9857 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 21:15:41 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 21:15:40 -0600 (CST) From: James Wyatt To: Robert Watson Cc: The Unicorn , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Robert Watson wrote: > On Sun, 14 Mar 1999, James Wyatt wrote: > > > On Sun, 14 Mar 1999, The Unicorn wrote: > > > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > > > BTW, I'd really like to get rid of hard links -- they allow users to > > > > retain copies of setuid files after the owner thinks they are deleted. > > > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > > > removed the risk of the now known buggy somesetuidbin. > > > > To quote Bill The Cat: Ack! Phht! > > No! Please, No! I use arg0 in a lot of my programming when it's useful to > > have common code that does related, but different, things. (Please look at > > the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc, > > compress/uncompress, etc...) If you want to find more, just try: > > > > find / -links +1 -type f -print | xargs ls -l | more > > symlinks, when executed, pass the symlink name as arg0. True, they just take extra space, reads, cache, etc... but not much. > > This is just too useful to most folks to save the sysadmin who doesn't > > read their nightly security mailings. It is also why I like a /tmp filesys > > (as well as a /home) filesys on machines with real users. Don't let them > > link on drives w/important binaries and don't let them vi ~/bigfile to > > fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that > > ~ftp/incoming is a separate filesys too. 8{) > > There seems to be some contradiction here: you want users without > extensive security experience and unwilling to look at nightly security > mailings to know how to partition systems in the manner you describe? I expect admins who don't usually exhaustively check files before deleting them to read mail sent to them every night. Backup admins who also get the mail (we get our customers security mail) can also read it. > What about users who use setuid so that their CGI scripts execute as their > own UID? This means having more than one user per partition is a bad > idea. No, it doesn't: we just don't have user cgi running in the same partition as the system binaries - that can be a bad idea too. No can hard link to *anything* systemwise. If I have suid-root stuff in my web tree, I should be *very* careful of it anyway as there is no retry limit or delay like telnetd. Of course I can't prevent them from symlinking to /usr/bin/su and brute forcing a crack. I get logs of that, though. > The merits of a MFS /tmp (cleared at boot, restricted in size, etc) should > not be confused with the merits of secure file system behavior. All I > want is for it to be safe for me to have a setuid binary on the same file > system as a temporary directory. File systems were not intended to be the > partitioning points for security domains -- they are for file storage as > binary blobs :-). Don't overload security characteristics onto local hard > disk arrangement. I know that this already happens somewhat, but I'd like > to try and reduce it in the name of KISS and consistency. > > Especially given how many people run with so many different partition > arrangements. Personally, on notebooks, I like to have everything except > tmp on one partition, and have tmp on MFS. This means that the slack > space from each partition is not wasted in places where it won't be needed > (not much mail delivery on my notebook). On the other hand, it doesn't > meet the requirement that each user home directory, world-writable > directory (*/tmp, texmf, etc), etc, be on a different partion :-). And it > does end up being a multi-user machine (a poor distinction except from the > point of view of performance operation in my view) because sometimes I > need to access it remotely, or give other people access to files on it. I theory, I like the idea of /tmp on a(n) MFS. It comes up clean and saves a partition. In practice, I usually have to enlarge swap about exactly as much as I saved on /tmp. I don't usually have to worry about suid programs in /tmp, or need them. In fact, prefer noexec on /tmp when I can get it... When filesystem support RO, noexec, etc. it tells me someone else must think partitioning of security by filesystem was intended - if not optimal. /tmp is used for intermediate files and scratch data as I don't do much mail routing on the laptop either - it's address changes too much. As my laptop is not usually a security risk, so I usually use just root and swap as well. I also find that I like /tmp hanging around more on the laptop than a server when I forget to save the more important intermediate files. 8{( I also don't have to hunt down users if something fills it up. > > > > target directory). Given that hard links already cause inconsistent > > > > semantics in the name space for users, and aren't properly preserved in > > > > tar, etc, I think they don't contribute much. > > Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets > > it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{) > Recursive cp? (The intuitive, simple, *man page recommended* way to copy > a directory from one hard disk to another?) Good point, though I'd never noticed the recommendation, I've always used: (cd /here && tar cf - .) | ( cd /there && tar xvf - ) I don't know if it is as efficient, but it works well for everything but devs on about everything I've been on. Just different approaches, I guess. > > > They cause inconsistent semantics, but they are recorded in the inode as > > > the number of links to the file the inode holds information on. Therefor > > > any admin who is worth the money they receive for doing their task will > > > know that if the number of links to a file is greater than one another > > > hard link must exist. Searching the filesystem for another name > > > referring the same inode is then not a really hard thing to do... But it can be time consuming. (esp on laptops w/just root filesystem) > > Uh, I know a lot of admins that I consider 'worth their salt' who don't > > check link counts (or maybe even notice them in an 'ls -l') before > > removing a file. I don't think system upgrade scripts do it either. > > And "checking" still allows for race conditions. Especially when > automated. And I agree that checking should not be necessary. I don't trust it either since a friend showed me how to break some of the race conditions. (Interestingly enough with symlink() on a Tandy 6000) > > > Have a look at ls -l `which vi view ex` and think again about what hard > > > links contribute (then again similar functionality might be constructed > > > using soft-links; but they are much harder to administrate (read: keep > > > under control)) > > > > Symlinks do not prevent the original binary from being unavailable. Please > > remember that files don't really go away until all links are zero and no > > more filedescs are open on them. Hey, if 'the founders' had meant for > > symlinks to be used over hard links, there would have been an 'ls -h' > > flag, right? 8{) > > Symlinks don't prevent the filedesc behavior from happening. They do not > allow for the refcount, but the solution that comes to mind is actually > more intuitive: > > mv vi vi-bin > ln -s vi-bin vi > ln -s vi-bin view > > Now you replace the one vi-bin binary and all of vi is upgraded. And it's > easy to see what files are linked to other files--with hard links it can > be quite hard. I can't easily tell what is symlinked-to, if I understand this. I can do things like 'ls -li' to get the inode number and 'find /fs -inum %d -xdev' to find all the bits. I also like the handy ref counter to cross-check. How do I find what is linked to vi (esp. in various filesys /usr/bin, /usr/sbin, /usr/local/bin, ...)? How do I *know* I have all of them with out a ref count cross-check? I can also typo 'ln -s vi-bim ex' and be confused for a few minutes by the 'ex: No such file or directory' when I can see it, but don't recognize the 'ls -l ex' output as another typo. > I'm just not sure that the consistency issues raised by hard links justify > the meager benefits. Please don't "gore my ox" as meager; It's not polite. 8{) Remember that "Meager benefits" is a *very* relative term. As I said before, I did a lot of work on systems without symlinks. Took some getting used-to and resulted in a few extra files (like /bin/rmail was a copy of sendmail), but wasn't too bad. The designers there thought symlinks were of meager benefit. They also thought that more than 64K inodes per filesystem was of meager benefit. 8{( Really, FreeBSD seems to provide every benefit we both feel we need. > > > Just my 0.02 euro. > > > > This means it's euro-pinion? What's the conversion rate? - Jy@ > > Damned if I know, and I'm English. (Of course, I'm English but living in > the US :-). But clearly a European point is far better.. or something. Better than an English or American one? 8{) Or something... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message