Date: Wed, 1 Aug 2001 09:01:37 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Jeff Palmer <scorpio@drkshdw.org> Cc: stable@FreeBSD.org, arch@FreeBSD.org Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Message-ID: <Pine.NEB.3.96L.1010801084419.59100C-100000@fledge.watson.org> In-Reply-To: <20010801010958.X9176-100000@jeff.isni.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Aug 2001, Jeff Palmer wrote: > Pardon my newbieness.. > > Doesn't the 4.x branch have a dialog box at install time asking you what > security model you'd prefer.. if you select high security, 'inetd' > itself is even disabed.. (Your own post showed the dialog) The problem, in my view, with the current "security profile" behavior is that it has a lot of baggage: in order to disable inetd, you have to accept securelevels, for example. Likewise, selecting the default leaves you with settings that, in the case of the recent telnet and ftp vulnerabilities, left you vulnerable to remote exploits out of the box. Because many new users select the defaults during the install, assuming they're be moderately "right", our selection of defaults should be relatively conservative so as to protect those users. An appropriate security stance is one that consists of a set of choices made by an administrator who is aware of the ramifications of the choice: they balance knowledge about their environment, both requirements and risks, in selecting configuration options. For new users, it's important that we choose settings that mitigate risk, allowing them to adopt additional risk when they determine it is appropriate. I.e., if they don't know what telnet is, we have no business turning it on, especially if it's going to get them rooted. > In my opinion, security is up to each individual administrator. They > should enable and disable all services based on their own needs. I > rarely see a machine with a competent admin, running a nearly 100% > default install. Absolutely: the majority of the attached patch was a modification to sysinstall to make configuring services *more* accessible, not less. It provides an improved description of the ramifications of enabling inetd, and offers the opportunity to configure which services are enabled earlier. It selects a more conservative default (all off), and permits the administrator to selectively enable services that they believe they need, rather than asserting they need services that (to be honest) are becoming less and less useful over time. > Also, FreeBSD has been awesome at fixing security holes within minutes > or hours (and in extreme cases, a day or two). So the likelyhood of any > daemon being exploitable within the first 15 minutes of a fresh install > are pretty much zero. Generally, we have a pretty good track record with fixing security problems, once we're informed of them. However, the reality is that the application of security patches is something that is both admin-"hard", and admin-"time consuming". Conservative defaults allow us to protect those administrators who weren't using the services anyway, and make administrators who do use the service more aware of what services are enabled in the system. This will make it easier for them to understand what security fixes they require, and reduce the number of occurences of "I'm vulnerable by virtue of a service I don't use, and didn't realize was on by default". > Therefore, it doesn't matter what services are enabled/disabled in > inetd.conf as most administrators edit that file within a few minutes of > a default install anyway. The current model, you edit it to close some > ports. in the model you suggest, you edit it to open some ports. > Either way, it takes an entire 20 seconds (ok, 1 minute for the 'vi > newbie') to edit the file and HUP inetd. If it doesn't matter what services are enabled or disabled from your perspective, selecting a default that disables provides the security benefits for less knowledgeable users, without costing you anything. If anything, it may make your life easier by prompting you with this opportunity during install. You believe that the average user's first act on a system is to disable services they don't need--I suspect that instead, it's to install additional services they know they do need, and to leave other things enabled because they're already on, and harmless, or to leave them on because they don't realize they're enabled. > I'd prefer to see people spending their time auditing the code, so we > can be even more proactive about exploits and vulnerabilities than we > currently are, rather than wasting time talking about services enabled > in inetd. I'm sorry you feel that way: from a practical perspective, there are a number of components to making an operating system secure. This includes both programmatic tasks concerning correctness, development of security models, and also making sure the system is simple to both administer and secure. When evaluating the security of a system, a very large part of the work includes evaluating its configuration: helping administrators select the right configuration for them, and encouraging sensible configuration, plays an important role in making proper configuration possible. In practice, the changes here took about half an hour to develop, and are an explicit response to the recent vulnerabilities: we need to not just fix the bugs, but also figure out how to reduce the impact of inevitable bugs. The reality is that the bugs will exist: a complete operating system is simply too complex to be bug-free. We need to respond to that reality by modifying our software: we should continue to target "least privilege" by reducing the privilege required for applications, reducing the impact of successful compromise, and by reducing the opportunity for compromise by disabling features and services that are unnecessary in the environment where the system is operating. The TrustedBSD project seeks to address the "least privilege" issue by reducing dependance on privilege (commits by Thomas Moestl in -CURRENT almost eliminate the need for setgid kmem binaries, which offer substantial), and increasing the degree to which privilege can be delegated in a fine-grained manner through improved operating system policy mechanisms (capabilities, ACLs, mandatory access control). Improved documentation and administrative security tools are an important, but less visible, part of that. > Just my two cents. Feel free to CC: me unless it's a flame. If it's a > flame.. please add [FLAME] to the subject for the procmail filters. :-) I hope you don't consider this a flame, rather, an honest disagreement on a contentious topic. My main concern in posting, or I would just have committed the patch outright, was to make sure that by making these changes, I wouldn't *break* functionality for a class of users. For example, simply disabling telnet in inetd.conf would have caused problems for those who use serial console configuration followed by telnet to log in, but on a trusted network segment. To disable telnet, we first need to offer the opportunity to re-enable it in the install. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010801084419.59100C-100000>