FC2 and FC1 and common home

[Jeremy Katz]

On Tue, 2004-04-06 at 17:26 -0400, Gene C. wrote:
> On Tuesday 06 April 2004 16:43, Colin Walters wrote:
> > > 5) Third-party daemons.  Looking at the current policy, a lot of
> > > services have their own domains, and for good reason.  However, in order
> > > to do this, every single Fedora service has to have it's domain
> > > information added to the policy source in a number of places.  And that
> > > information has to be present regardless of whether or not the service
> > > is actually installed.  Third-party daemons now must patch multiple
> > > files in the policy sources, compile and load the new policy, or just
> > > live with whatever domain options they are given (and live with the fact
> > > that they have only slightly more security than the simple
> > > user-group-other model).
> >
> > There are a few solutions to this.  One I've been thinking of is to have
> > an unlimited_t type (and corresponding unlimited_exec_t).  Then when you
> > install a third-party daemon, the system administrator could just run:
> >
> > chcon -t unlimited_exec_t /path/to/daemon
> >
> > As its name implies, unlimited_t would have all permissions.  Then you
> > could later create a policy and secure the daemon.  Or maybe we should
> > call it unsecured_t.
> 
> Whatever you want to call it but your idea sounds good to me.  The idea of a 
> third party package screwing with my security policy really bothers me.  The 
> third party package may want to make some suggestions as to what it needs but 
> it should be up to the administrator of the system to implement those.
> 
> As time progresses you (Red Hat) may be able to incorporate policy to handle 
> some of the more popular packages.  For example, this is already done to some 
> extent for vmware.

I actually pretty strongly disagree here.  I think that we need to move
to where policy for various daemons is included and maintained along
with the daemon.  Otherwise, we have a never-ending battle of one huge
monolithic package that will end up with bizarre dependencies on apps.
Managing that is going to be a nitemare in the long-term.  Think of the
situation where you want to upgrade your sendmail package, but to
upgrade your sendmail package, you need the new policy that has
information for the new way sendmail is split up but *that* requires you
to upgrade something else...  it can spiral out of control very very
quickly.

There's a reason we don't, eg, put all of the German translations for
everything we ship in, eg, a translations-german package.  It just
doesn't scale maintenance wise.  And that's completely disregarding
third party packaging.  You say that you don't want third party packages
screwing with your security policy, but the fact of the matter is that
they do so *right now*.  The onus is on the user to either investigate
the security implications of installing a particular package or trust
the developer to do so for you.  SELinux just adds another layer to
this.

Jeremy