Re: senlinux configuration, are you sure it's the right way?

Farkas Levente wrote:

> Daniel J Walsh wrote:
>
> > Farkas Levente wrote:
> >
> > > hi,
> > > after i having played a few days with selinux, apache and other 
> > > daemons and programs the whole selinux configuration seems to me a 
> > > bit confusing. if i found any kind of problem with the "default" 
> > > selinux setup which is not big thing since most systems are 
> > > different and there are a lots of program which are not included in 
> > > the core distro. i have to report it and the next update will 
> > > include it. my question why selinux include the default policies? 
> > > why selinux-policy-* contains the right acces rights for all 
> > > included deamons, programs? wouldn't it be much better to all 
> > > package include it's own policy and in the rpm postinstall session 
> > > reload/add/modify the new policies. this is something similar to the 
> > > libs. i only install only those lib which needed for me and at the 
> > > postinstall session run an ldconfig. i wouldn't like to install all 
> > > libs! why should i install policies for eg. apache when i don't run 
> > > apache? why should i update selinux-policy-* just because there was 
> > > a bug in the apache part of the policy when i don't run apache? the 
> > > current case is something one big monolitic policy configuration 
> > > which most of the time not suitable for anyone (anyone who run 
> > > anything else then the default need to modify it or run any 
> > > webscript or). of course my main problem not with apache policies 
> > > rather then the whole system and way of configuration of selinux. 
> > > wouldn't be any easier and modularized way to use selinux and 
> > > configure it for the needed thing. probably there is need for some 
> > > core policy but all others policy can be modularized. or do i missed 
> > > something?
> > > just my 2c.
> > > yours.
> > Yes this is something we are working on.  Currenly there are lots of 
> > interdendancies in policy that make separating them out difficult. 
> > Currently the only way to add or remove a policy, is via source 
> > code.  So if I want to remove apache policy, I need to install the 
> > policy sources and mv apache.te file out of the programs directory.  
> > Then recompile and reload the policy.
> > Tresys corporation is working on loadable modules that may be able to 
> > solve this problem.  We are working towards the point where you
> > would have an apache policy file that would get loaded and unloaded 
> > depending on whether you are running apache, and then the policy file 
> > could be supplied with the binaries.
> but until this happend wouldn't it be still better to always install 
> policy sources too, binaries install it's own policy source under 
> /etc/selinux/*/src/policy/ and postinstall run a make reload?
> even it's not the best why imho it's still better then the current 
> one. and the ploicy source not realy a big overhead.
> anyway my main problem not with the overhead of apache's policy if i 
> don't use policy rather then currently there is no proper way to 
> install/add any package/program/daemon which is not in the core distro 
> and required some policy changes. since it's obvious that you wouldn't 
> like to include and maintain policy for foobar when it's not in the 
> distro (and not even in extras). but if each package install it's own 
> policy the there can a common and working way to do so. what's if 
> there can be apache-policy...rpm then if i don't use selinux then i 
> shouldn't have to install apache-policy even if i install apache.
> > This is new technology and we are working to improve it.
> yes, i know that. so i wouldn't like to blame you since you i used to 
> got the quickest response from you:-) only try to suggest some 
> improvement to the current system.
Also from Red Hat's perspective having policy sources installed gives us 
major headaches for support.  If users start moving
files into/out of unused directories, things are going to start 
breaking.  We don't want some support call because someone decided
to try out the latest wizbang policy, and it broke their ABC 
Application.  Also policy sources requires a full build environment to work.
Make, M4, checkpolicy ...  On a minimal install machine this is a big 
overhead.
--