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.
-- Levente "Si vis pacem para bellum!"
