From owner-freebsd-security Sun Mar 14 11: 8:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 93F1F153E9 for ; Sun, 14 Mar 1999 11:08:11 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA05643; Sun, 14 Mar 1999 14:07:03 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 14:07:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: James Wyatt 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, 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. > 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? 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. 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. > > > Also, since directory permissions act as a cumlative masks on the > > > permissions of files held in them, it can be hard to revoke access to a > > > file you own--someone else may have hard linked it elsewhere in the fs > > > without your knowledge (something they can do as long as they own the > > > 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?) > > 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... > > 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. > > 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'm just not sure that the consistency issues raised by hard links justify the meager benefits. > > 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. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message