[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC2 and FC1 and common home



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.

>
> > 6) NIS/LDAP user information.  If giving all users the user_u identity
> > and just living with that is acceptable, that's one thing, but if the
> > "standard practice" is expected to be adding every system user into
> > users.te and recompiling/reloading the policy, it's more than simply
> > impractical.
>
> Having all users be user_u and just relying on DAC should be sufficient
> for most sites.  But I don't see why having a script to add users to
> users.te would be so impractical.

Actually, I believe that system-config-users should be enhanced to handle 
policy updating for sysadm users.  To some extent, setools' seuser can also 
be used.

>
> > I'm sure most of these are already being considered and worked on, but
> > from where things stand currently, the above problems prevent reasonable
> > deployment of FC2 in a number of different, but common, scenarios.
>
> We're going to try to make it workable for as many of those before the
> release as possible :)

This is going to take time and we (Red Hat and users) need some experience 
with running systems that have selinux to develop the policies that we need.  
Right now, IMHO, we need something that works out of the box with 
enforcing=1.  The system may not be as locked down as we all would like but 
that can wait for later refinements.  If we need to run enforcing=0 or 
(worse) selinux=0, then users will not pay much attention to it.
-- 
Gene



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]