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.
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.
This is new technology and we are working to improve it.
Dan
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.
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.
Daniel J Walsh wrote:
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
this can happend now with /etc/selinux directory too...
Application. Also policy sources requires a full build environment to work. Make, M4, checkpolicy ... On a minimal install machine this is a big overhead.
i see, that's a bigger problem:-((( so the only solution that package creator should have this enviroment and he has to include binary application specific policy in the binary rpm. which currently can't be added/loaded into the system (could it?). so we have to wait for trsys:-(((
Farkas Levente wrote:
Daniel J Walsh wrote:
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
this can happend now with /etc/selinux directory too...
Application. Also policy sources requires a full build environment to work. Make, M4, checkpolicy ... On a minimal install machine this is a big overhead.
i see, that's a bigger problem:-((( so the only solution that package creator should have this enviroment and he has to include binary application specific policy in the binary rpm. which currently can't be added/loaded into the system (could it?). so we have to wait for trsys:-(((
The only solution now would be to require policy-sources to be installed and then add their policy to it.
Dan
On Thu, 2005-03-31 at 17:59 +0200, Farkas Levente wrote:
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.
That idea has been considered in the past, but it has some issues, e.g. - The current policy doesn't provide a real module abstraction, and lacks a strong dependency model and a way to easily handle variations in the base policy when inserting a new policy "module". That is being addressed by recent work by Tresys Technology to create a real module abstraction for policy; that work should be upstreamed in the near future. - While some aspects of the policy are highly localized (e.g. least privilege requirements on a particular application), other aspects require a global view of the policy (e.g. information flow constraints to ensure confidentiality and integrity guarantees). Hence, it is difficult to truly modularize policy in the same manner as packages. - Policy is intended to organize the system into security equivalence classes, i.e. not every package should have its own policy, and multiple packages should share the same policy. Hence, you need a layer of indirection between the policies and the packages. - Policy should be defined by the security administrator, not by the application writer. The application writer can help by providing information about what resources an application needs in order to function, but ultimately the decision about how to allow the application to interact with the base system should be made by the security admin, sometimes even denying access to the application that may reduce its available functionality or force it to alternative code paths.
Stephen Smalley wrote:
On Thu, 2005-03-31 at 17:59 +0200, Farkas Levente wrote:
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.
That idea has been considered in the past, but it has some issues, e.g.
- The current policy doesn't provide a real module abstraction, and
lacks a strong dependency model and a way to easily handle variations in the base policy when inserting a new policy "module". That is being addressed by recent work by Tresys Technology to create a real module abstraction for policy; that work should be upstreamed in the near future.
- While some aspects of the policy are highly localized (e.g. least
privilege requirements on a particular application), other aspects require a global view of the policy (e.g. information flow constraints to ensure confidentiality and integrity guarantees). Hence, it is difficult to truly modularize policy in the same manner as packages.
the security administrator who create the xxx-policy packages should have to this "global view", but he can still create different packages for different application's policy. and as i said there can be one (some) global policy packages too.
- Policy is intended to organize the system into security equivalence
classes, i.e. not every package should have its own policy, and multiple packages should share the same policy. Hence, you need a layer of indirection between the policies and the packages.
more package can depend on on policy as more package can depend on one lib.
- Policy should be defined by the security administrator, not by the
application writer. The application writer can help by providing information about what resources an application needs in order to function, but ultimately the decision about how to allow the application to interact with the base system should be made by the security admin, sometimes even denying access to the application that may reduce its available functionality or force it to alternative code paths.
ok. but the current situation is the same there is one security administrator (called Dan:) who define the policy, and probably he can do the apache-policy package (and the local hacker admins can modify it). i don't assume apache developer should have to do this.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Farkas Levente -
Stephen Smalley