FC2 and FC1 and common home

Colin Walters walters at redhat.com
Wed Apr 7 18:21:25 UTC 2004


On Wed, 2004-04-07 at 13:30, Jeremy Katz wrote:

> This could be argued for a lot of other things too.  It's completely
> unscalable, though.  I'll reference specspo again.  Also, it means that
> whenever something new is added, either
> a) the person adding the package has to analyze it and then add to the
> policy package (which they don't own) and make the changes
> or

They could write a proposed policy and submit a patch.  Or just send a
description of what the program does to a policy editor team, who could
then write policy.

> Right now we have policy dependent on a new enough kernel. 

Yeah, but ideally things will stabilize there :)

>  I'm willing
> to bet that we'll get an application behavior change at some point
> that's going to end up making the policy require a specific version of
> some program. 

Why not have the package depend on a particular version of policy?

> I don't think that they're really any more independent than the policy
> _should_ be.  The policy for sendmail should have no relation to the
> policy for httpd.  The two are orthogonal to each other. 

Not completely.  Both of them use mta.te.  If a security administrator
wanted to change how mta.te worked, and the policies were all maintained
centrally, they could modify both the sendmail.te and httpd.te files as
necessary before actually installing the packages.  Otherwise they have
to wait to install the package to get the policy, and installing it
might fail due to the policy not compiling or something due to changes
in mta.te.

A security administrator might also want to know if there is any
information flow from apache to sendmail before actually installing
sendmail.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040407/acd1d34a/attachment-0002.bin 


More information about the devel mailing list