From owner-freebsd-security Wed Oct 13 18:57:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 249221536D for ; Wed, 13 Oct 1999 18:57:41 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id UAA14841; Wed, 13 Oct 1999 20:57:26 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-238.tnt1.rac.cyberlynk.net(209.224.182.238) by peak.mountin.net via smap (V1.3) id sma014837; Wed Oct 13 20:57:06 1999 Message-Id: <3.0.3.32.19991013205157.015e6910@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 13 Oct 1999 20:51:57 -0500 To: Robert Watson From: "Jeffrey J. Mountin" Subject: Re: FreeSSH Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:14 PM 10/13/99 -0400, Robert Watson wrote: >This actually raises another issue that is relevant to the >packages/ports/etc system--the addition of new users for services. Some >services (uucp, bind, postgres, www, etc..) require new services be added >to the system. Some consistency in the allocation of uid's, and a formal >policy for which uid's should be used might be nice :-). Maybe one exists >and I have missed it... But adding users is clearly relevant to a system >security policy. Removing users is also relevant--right now many ports >that require user modification don't get packages, perhaps for this >reason. But if more of the world uses packages, it would be nice to know >if, say, pkg_add will overwrite a current user, or end up with a uid that >already owns some files, and that pkg_delete would or would not remove the >user in a consistent and complete way. Right now we encourage the use of >uid's over 1000 for new users, but documenting this would be a good idea >"local users SHOULD be given a unique uid >= 1000 -- values less than 1000 >are reserved for built-in accounts, and for add-on packages" or the like. >For the purposes of NFS, it seems desirable that when a package is >installed, it use the same uid consistently? > >I'm not sure the correct course of action is clear in my mind, but >whatever it is, it is certainly security-relevant. Many of the "users" are nologin for shell and sometimes nonexistant for their home. What risk would there be with both? In most cases there would be no files owned by them. More importantly the package installer would not have to deal with trying to add a UID that might have been added manually. Adds a certain level of complexity to a distribution packaging system. I'm all for such a system to make things more flexible and easier for new/inexperienced users, but don't need it personally. Think that most of such work should be done before sysinstall is improved. Sure jkh will agree. ;0 First thing would be too add knobs for buildworld, which has been requested several times. Then registration via the package system. At the same time doing a buildworld should then do some checking with the listings in /var/db/pkg or var/db/pkg/system, interactively most likely - something like "you installed this" and the option to add or delete others before continuing. Once that works out then sysinstall is revamped. Additions could then be done at build time or via sysinstall and should be honored either way. Allow for a minimalist approach should also help security. Most servers don't need UUCP, NIS, lp, but there are many others like sendmail, DHCP, etc. Even the libraries could be broken down, but finer granularity adds complexity and the greater chance of dependancy problems. Maybe this should be started with the most commonly unused features that have few dependancies one bite at a time and not as some huge project. If we go the other route via sysinstall, building from source would clobber manually installed packages or add unwanted ones. Not to mention that the changes would affect many more users and not those that already customize things. We all should know what that means. my .02 Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message