Date: Tue, 5 Nov 1996 20:34:32 +1030 (CST) From: newton@communica.com.au (Mark Newton) To: karpen@ocean.campus.luth.se (Mikael Karpberg) Cc: newton@communica.com.au, freebsd-security@freebsd.org Subject: Re: chroot() security Message-ID: <9611051004.AA21746@communica.com.au> In-Reply-To: <199611050017.BAA17765@ocean.campus.luth.se> from "Mikael Karpberg" at Nov 5, 96 01:15:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
Mikael Karpberg wrote: > > On the other hand, some kind of FAQ might be useful to make sure that > > people are aware of the potential that the presence of source code > > provides for them. If that's publicized then people are free to make > > their own hacks to enforce their own policies. > > "If you can't write a UNIX on your own, you shouldn't use our's either"? That's a rather extreme view, dear Sir -- I think both of us know that what I said has born absolutely no resemblance to this rather incandescent straw-man! > I think we should go the other way, making it easier to use FreeBSD. By all means, and I think it *is* easy to use. But we're not talking about something the standard Windows 95 user will be utilizing. Let's put this into perspective: The applications in which that compile-time option will be useful are quite specialized. To even know that chroot() exists requires a certain amount of sophistication as a user (let's face it, it is rather obscure, innit?). Such a specialist application cannot be made foolproof. Unfortunately, if it's easy enough for unsophisticated users (let's call them "plebs" or "peons" :-) to use then it stands a very realistic chance of lulling them into a false sense of security... which is often worse than no security at all. We cannot create the impression that a four-line patch makes FreeBSD "more secure" or "easier" because, put bluntly, it doesn't. For the overwhelming majority of users it'll make not a jot of difference; for those users who would benefit from the difference, they are hopefully sophisticated enough to know that the four-line patch isn't the answer to all their problems, and that they're going to have to invest a lot of time with a lot of source code whether they like it or not. And, if they require the added security and can't comprehend the source code then no accusations of intellectual snobbery will convince me that they are the *wrong* people to be looking after their security. Do you see my point? While it's all very well to make FreeBSD so easy that even a Win95 user can install it, it's something completely different to announce to the world that it's so easy that a Win95 user can be a security expert (god knows, we have enough NT advocates proclaiming themselves to be security experts already! :-) That is why I suggest putting it in the FAQ instead of putting it into the source tree (if you really want to, the patch itself could be put into the FAQ with the explanation). The explanation in the FAQ should make it clear that there is no such thing as a magic cure-all for security problems, and if the user *really* wants security then they should be using an air-gap firewall :-) > "We can not make FreeBSD perfect for all occations, so why even try?" is > not a good way to go, I think. Again, you're drawing out a straw man attack. I think we are trying. I have a patch here which I'm testing at the moment; I'll release it to this list later tonight if I'm happy with it. As well as actual code, we're talking about putting something in the security section of the FAQ and Handbook -- That's hardly "not even [trying]." We cannot allow people to think that they can solve all their security problems and implement all their security policies without exposure to source code, whether in the kernel or in userland. > The bloat is very small, and only a source-bloat. Not a kernel bloat. :-) And thus UNIX grew from a system which would fit onto 20Mb of disk with complete source code into the system we all know and love today <grin> > Hacking stuff in the kernel is much worse then crunching a userspace program > into exactly what you want it to. Things you do can affect stuff you didn't > even know existed, etc. That's exactly what we want this one to do :-) This is the kind of thing which is *intended* to break userland programs. It's *intended* to reduce functionality. It's a bit like removing the setuid bit from sendmail and running it as a non-root user: It provides a vast improvement in security for a severe degradation in functionality (local users can't send and receive mail, in that instance, and you have to run its "daemon" functionality out of inetd and cron). In almost all cases, increasing security reduces ease-of-use. It's one of those trade-offs which has had commercial firewall vendors battling with all kinds of user interface paradigms for years. It's the kind of thing that has left us entrenched with broken protocols like rlogin/rsh, disastrously unsecure and yet so enticingly *easy* to use! In general terms, you increase the security of an existing system by disabling or removing those parts of its functionality which are unsecure; yes, there are alternatives which preserve ease of use, but they generally decrease maintainability, which necessarily decreases security. I'm not a great fan of making security easy. I'd rather make it secure. I think I've been talking about two things -- Ease of making it secure and ease of using it afterwards. I hope I haven't obfuscated the issue too much... > I for one would be very careful about trying > to add something like this safer chroot patch. And I wouldn't know were to > start. With the option in I can go in and change my config file and try the > default. If it's not exactly what I want, then I can look through the files > for code that has ifdef for that option, and I can read the FAQ entry, and > maybe dare go in and do a small change to that, in it self, small patch > (you (?) said it was, at least). Ah. So you're saying that if it was nice and easy then you'd go out of your way to spend lots of time and effort on researching it before going ahead and implementing it? Excellent! You have met the prerequisites for using something like this. Yet you expect those who don't meet the prerequisites to just add "options FUNKY_CHROOT" to their kernel config file and "know" that it'll make their system more secure without having the benefit of knowing why? Don't you see the dangers inherent in that approach? > Do you see my point? Absolutely. Do you see mine? - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9611051004.AA21746>