From owner-freebsd-security Wed Aug 15 11:27:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from giganda.komkon.org (giganda.komkon.org [209.125.17.66]) by hub.freebsd.org (Postfix) with ESMTP id C9D1537B415; Wed, 15 Aug 2001 11:27:27 -0700 (PDT) (envelope-from str@giganda.komkon.org) Received: (from str@localhost) by giganda.komkon.org (8.11.3/8.11.3) id f7FIRQG13462; Wed, 15 Aug 2001 14:27:26 -0400 (EDT) (envelope-from str) Date: Wed, 15 Aug 2001 14:27:26 -0400 (EDT) From: Igor Roshchin Message-Id: <200108151827.f7FIRQG13462@giganda.komkon.org> To: rwatson@FreeBSD.ORG, steve@virtual-voodoo.com Subject: Re: cvs commit: src/etc inetd.conf Cc: security@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Wed, 15 Aug 2001 13:44:48 -0400 (EDT) > From: Robert Watson > > On Wed, 15 Aug 2001, Steven Ames wrote: > > > > I am not completely sure if this is a good idea or not, but I'd through it > > in. > > > How about having two menu options here, after offering to edit inetd.conf: > > > for `experts' (manual editing) and for `beginners' (menu-driven > > > configuration). > > > > 'sysinstall' already has a 'Security' menu under post configuration. > > Couldn't we just install from a fixed set of 2-3 different inetd.conf > > files? > > > > i.e. if the user selects 'moderate [default]' install > > src/etc/inetd.conf.moderate into /etc. If they select 'extreme' install > > the inetd.conf that has everything turned off. > > > > This is a short-term hackish solution but I believe it would suffice > > until we get a GUI up where we can select 'yes'/'no' for every line in > > the inetd.conf and have the ability to add in new lines. Good project > > for someone... the 'inetd editor'. > > One of the problems with this solution is that sites frequently modify > their inetd.conf to add services, such as pop or imap, and that if they > ran sysinstall to select a template, they would risk squashing their > current install. > > I agree with your thoughts on a menu-driven editor, but doing that > properly relies on having a machine-parsable file format that supports > in-band disabling of services. My feeling was that our current file > format didn't lend itself to that, and as such I went with the current > "spit the user a text editor" over implementing one before 4.4-RELEASE. > If someone would like to write an editor that understands the syntax and > semantics of inetd.conf, they should feel free. However, it needs to > handle the cases where users have custom comments (etc) properly, and be > able to handle the full scope of valid inetd.conf files, not just the set > of files it could possibly generate. > Comments and suggestions: Comments: -------- It sounds like such an editor is either impossible, or its abilities won't be "universal". This is due to the reachness of inetd.conf. You don't just enable or disable services in that file, but also can change many options. In order to cover all possibilities of the options inserted or edited by hand one would have, especially if we assume that there might be "new" services added locally. One thought I had is that such an editor can parse the existing inetd.conf (its commented lines) by searching for the known services names, which can be read in from /etc/services. However, this would fail if someone would make a comment like this: #telnet is temporarily disabled On another hand, if somebody has a bunch of services commented out by more then just "#", such approach (and many others) would fail. I sometimes disable a set of services altogether for a period of time by marking them with a specific comment, like this: #Down# telnetd stream tcp ... Parsing of such an unstructured text, as inetd.conf is, can produce erroneous results. Suggestions: ------------ Couple of ideas for a temporary `hack' for the 4.4-RELEASE: 1. "beginner" version of the inetd.conf editing via selecting/deselecting services in a check-mark-style menu should have a huge warning that all changes that had been made manually would be lost. So, sysinstall wouldn't parse the existing inetd.conf, but rather write out a new one. You may also add an option to enter one's own service. 2. Another additional possibility (also a `hack') is to have an additional copy of inetd.conf (say, /etc/inetd.conf.auto) saved by the menu-driven editor (that works as described in 1. above), so that every time sysinstall runs this editor again, the editor first runs diff(1) on both copies, and after the user's choice of services is completed, offers to make decisions on the lines that were added/edited manually since the last sysinstall run, somewhat similarly to what mergemaster does, with an option to abandon those new lines, to have them commented out, or to leave them intact. In all cases I assume an existance an alternative "expert" option to edit /etc/inetd.conf in an regular editor by hand. Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message