Date: Sun, 14 Mar 1999 15:55:41 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: patl@phoenix.volant.org Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990314154436.5121I-100000@fledge.watson.org> In-Reply-To: <ML-3.3.921443143.7515.patl@asimov>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999 patl@phoenix.volant.org wrote: > > 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? > > Sysadmins that aren't willing to spend a few seconds a day reading their > nightly security mailings deserve whatever they get. My point exactly :-). I want simple behavior that is consistent; something that doesn't require users to be familiar with the caveats of hard links to understand. I bet the majority of users have no idea that their old setuid binaries can be hijacked, even after the OS is upgraded. But they can, because the majority of users have home directories on their /usr partition. > > Recursive cp? (The intuitive, simple, *man page recommended* way to copy > > a directory from one hard disk to another?) > > Then the man page needs to be fixed to recommend something that actually > works correctly. It seems counter-intuitive that the copy utility with the recursive flag be the incorrect way to recursively copy :-). > > > 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'm surprised that nobody has suggested using 'rm -P' to overwrite > the file's contents. Nasty if it's mmap'd anywhere :-). Shared libraries aren't so happy, I think. :-) Probably the closest thing to the correct behavior is open() unlink() if (link count > 0) fchmod() to remove the setuid bit. > It seems like it might also be useful to have one or more new options > to rm related to link count checking. Perhaps one that will only > delete if the link count is 1, otherwise issue an error. (It can > detect a lost race condition by opening the file, doing the unlink, > then checking the link count on the open fd before closing.) Or perhaps > an option that will only do the overwrite if the link count was one. > (Otherwise issuing an error. Force overwrite via the -f option.) We already have multiply-hard-linked setuid binaries like passwd. This error would turn up whenever dealing with them. I think my conclusion is this: hard links are too burnt into the minds of my unix brethren to be removed today. Perhaps I'll bring it up in another year or two. In the mean time, I'll add a way to disable it (default to enabled), and advise that folks who want secure behavior, and don't want to rely on bizarre partitioning to guarantee that, use this flag. Is there any legitimate objection to this suggestion? The only one that comes to mind is the installworld behavior that hard links it in in the first place. I know of few people that actually even use hard links. :-) They're too non-portable due to directory/partition problems, especially in the world of scalable distributed file systems (AFS, Coda, DFS, etc) where two directories may rely on different servers, not just different partitions on the local system. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990314154436.5121I-100000>