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.
Description: This is a digitally signed message part