Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Oct 1999 20:51:57 -0500
From:      "Jeffrey J. Mountin" <jeff-ml@mountin.net>
To:        Robert Watson <robert+freebsd@cyrus.watson.org>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: FreeSSH
Message-ID:  <3.0.3.32.19991013205157.015e6910@207.227.119.2>
In-Reply-To: <Pine.BSF.3.96.991013170937.22726D-100000@fledge.watson.org >
References:  <Pine.BSF.4.10.9910131307410.60569-100000@bsdie.rwsystems.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19991013205157.015e6910>