Date: Sun, 14 Mar 1999 13:39:48 -0800 (PST) From: patl@phoenix.volant.org To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <ML-3.3.921447588.1051.patl@asimov> In-Reply-To: <Pine.BSF.3.96.990314154436.5121I-100000@fledge.watson.org>
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. No, that's not my point. My point is that anyone who is going to admin a system that other users can log into had damn well better learn some minimal security precautions. Like reading and understanding the nightly security report. Holding their hand by duct-taping foam rubber over a couple of sharp edges isn't doing them any favors at all. It's just giving them a false sense of security while removing a -very- useful and long-standing feature from the OS. My further point is that no sysadmin who has the slightest concern about security can simply rely on the system to keep them safe. Monitoring the logs and reports is a vital part of the sysadmin's job. Any admin who ignores the logs and reports is asking for a breach; and deserves whatever hardship that breach generates. > > > 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 :-). Most of life is counter-intuitive. > > 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. Of course it zaps anything that had the file open. That's part of the idea. It ensures that the file can't be resurrected elsewhere by some program hanging around with it open just to keep the inode alive. > > 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. That's why it's an optional flag. > 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. Hard links solve various problems in a fairly reasonable manner. The potential for their abuse is no excuse for the loss of functionality that would come from removing them. Removing hard link capability just isn't an elegant solution. The schg/uchg flags prevent hard links on a file-by file bases. That is a much more elegant approach. You might argue that it would be even better to have a separate no-links flag. > 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. You must have a unique set of unix-using associates... I'd also like to point out that hard links are primarily used within a single directory; or within sibling directories. -Pat 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?ML-3.3.921447588.1051.patl>