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

Farkas Levente lfarkas at
Thu Mar 31 16:32:39 UTC 2005

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.

   Levente                               "Si vis pacem para bellum!"

More information about the fedora-selinux-list mailing list