Date: 19 Apr 2002 00:43:17 -0700 From: Ken McGlothlen <mcglk@artlogix.com> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip Message-ID: <87ads016cq.fsf@ralf.artlogix.com> In-Reply-To: <4.3.2.7.2.20020418202335.0229b540@nospam.lariat.org> References: <4.3.2.7.2.20020418143615.021a8460@nospam.lariat.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020417230144.032ad390@nospam.lariat.org> <200204171923.g3HJNga58899@freefall.freebsd.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020418143615.021a8460@nospam.lariat.org> <4.3.2.7.2.20020418202335.0229b540@nospam.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass <brett@lariat.org> writes: | I don't think so. They're real pitfalls for administrators. No, they're not. Most administrators don't modify stuff in /usr/src, and if they do, most of them understand that they're on their own when they do this. And if you want to modify the operating system (i.e., upgrade), you've got to drop SECURELEVEL, in the classic can't-have-your-cake-and-eat-it-too dilemma. I'm going to treat those as specious whines, and go back to the basic problem. You want to be able to roll out security patches, as I understand it, without doing buildworld/installworld/buildkernel/installkernel. Yes? Y'know, even Solaris didn't have this until the last few years. I admit it: in doing autoupdating, FreeBSD is a little behind the commercial curve. Which isn't surprising, given its lack of funding. Okay, so if I were administrating 1000 FreeBSD machines, and having to keep them up to date, how would I do it? I guess what I'd do is keep a reference machine around for starters. No matter what, I'd want a reference machine tracking -STABLE, so that if I was hit with a DoS attack that was already fixed in the sources, I would at least have access to the source code. The next thing I'd have to ask is how important it was that they were *all* running the same operating system. If it was critical to the mission, what I'd probably do is set up a rolling update system. I wouldn't use very many kernel configuration files; instead of individualizing them too much, I'd probably name them MAIL, WEB, or after whatever function they were fulfilling. Do the buildworld and the first kernel, and roll it out to, say, ten vanguard boxes by executing a command from the reference machine to tell the vanguard boxes (I can think of several ways to do this off the top of my head) to go to single-user mode and start the installworld and installkernel. When they reboot, they let the next batch know (say, 50 machines) that it's time for them to update. The vanguard machines would then serve as the second wave's reference machines (five apiece), which would then do the installworld, and then refer to the reference box for installkernel. And so on, until all the machines were updated within the day. Rolling blackouts, as it were, but wouldn't cut services entirely. Of course, I'd have to put it together myself. And if it was sufficiently clean and well-written, I might share it with the community. Might even become a nice general-usage tool. Of course, to me, that's sort of what sysadmins *do*. I don't see this as a weakness of the operating system per se; it's just that there's no tool that's going to help me run my particular shop quite as effectively as I'd like, because I'm the guy who knows what the requirements are for the shop, and I know how everything's put together. For example, on a server farm like the one I've been talking about, you might not even want to bother taking things down to single-user mode. Sure, it's safer that way, but when I know I'm the only user on a system, the only one with a password, I might want to take a shortcut. Again, test it on the reference box first, but if I felt it was safe enough. . . . On the other hand, if everything absolutely, positively had to be done NOW, with as little impact as possible, I'd have redundant boxes all over the place, doing distributed functions, so taking down a bunch of them would slow things down, but not make services completely unavailable. It goes without saying that downtime should be announced in advance. Take a different BSD operating system: Mac OS X. The System Update tool is quite nice. But the system still has to get bounced once in a while, and you still have to go from box to box updating the system. Last I checked, that was true of Solaris, too. I guess I look at it like this: There's an inherent tradeoff between flexibility and convenience, and another one between work and spending. I like the flexibility, and I like saving money, so I use FreeBSD. If convenience and not having as much work to do is more valuable to you, then Solaris or something like it is probably a better solution. I admit that FreeBSD (or Linux, or OpenBSD or NetBSD or HP/UX or AIX or whatever) isn't for everybody. Each shop's requirements has a hand in tipping the balance towards what OS is a preferable solution. If security and source auditing is your number one concern, then use OpenBSD, for heaven's sakes. If you want your operating system manufacturer to keep your systems updated for you conveniently and easily, then use Solaris or something like that. If you have a boss with a penguin fetish, then Linux may be what you want. No OS is going to be the end-all and be-all of the entire population. I think the FreeBSD core team knows that. I'm an agnostic on the issue of which is "best"---I just have a strong preference for FreeBSD, because of my *own* requirements. There are things I'd like to change about FreeBSD, and when I have the time, I might try to help change those things, or when I win the lottery, I might pay someone to help change those things. But I accept the limitations of a volunteer project: they don't have the manpower or monetary resources to do what Sun or Microsoft or IBM does. The FreeBSD core team is *dwarfed* by the number of paid full-time Solaris team developers, and I'm not even going to go *into* how many people Microsoft or IBM has banging away on their respective OSes on respectable salaries. FreeBSD might not be for your shop. It's okay. We can take it. But whinging that it's not Solaris is only going to wear at the hardworking and competent volunteers that have made FreeBSD as excellent as it is. The cardinal rule is, don't fix it if it ain't broke, but closely following *that* rule is this one: If you think it is, fix it. Do something to contribute---after all, none of us are getting paid to work on FreeBSD (with a very few notable exceptions, and nobody full-time to my knowledge). 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?87ads016cq.fsf>