Binary policy modules

[Joshua Brindle]

Mike Hearn wrote:
> On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote:
> 
>>The format is versioned the same way the kernel binary format is, so any
>>changes to the format use a different version number, and backward
>>compatbility is retained.
> 
> 
> That's good, but it's not what I asked. What are the binary compatibility
> commitments you guys are making? Is it expected that the format will
> change in future? Was it designed to be extendable? Is there some kind of
> internal chunking system so new data can be added in a way that older
> versions of SELinux will ignore?
> 
Ok, my answer was about the module format. The module format is 
versioned so that older policies will work with newer selinux systems, 
but vice versa isn't automatic, the module would need to be downgraded 
(there is a similar discussion to this on the selinux list currently)

however, the package itself isn't versioned, if the format is changed 
older systems may not be able to cope with it. This is something we need 
to look at.

> 
>>only as neutral as policies are, which isn't all that neutral right now.
> 
> 
> Hmm, that sucks. For very simple policy like "this process can do XYZ"
> shouldn't it be independent of targeted vs strict/fedora vs gentoo?
> Are the capability names actually variable between distributions?
> 
in all of the mentioned policies types and attributes may or may not be 
present and may have different meanings; filesystem labels may also be 
different. modules have the ability to enable policy based on the 
presence of symbols (types, attributes, etc) and this may help some but 
probably not entirely.

> 
>>  Hopefully this will change when reference policy is used by everyone
>>and  optional tunables are built in to the language.
> 
> 
> OK, I'm glad there's a plan for this.
>  
> 
>>you might look at this thread:
>>http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more
>>information. Particularly the justification for building seperate packages
>>for policy and the application.
> 
> 
> OK. This doesn't affect autopackage so much as it's meant for third party
> packages, and therefore developers are expected to define their own policy
> which would be independent of strict/targeted. I question the solution
> given for RPM - why not simply fix RPM so it loads policy before
> installing files?

I think it is relavent because there are important concepts, proper 
integration with a package manager means several things:

The modules must be associated with the packages someway (I suggest 
dependancies)

The package manager must apply policy before installing an application, 
so that labeling will work correctly

The package manager should install policy modules to a directory it 
'owns' such as /usr/lib/selinux and then use libsemanage (semodule) to 
add modules.

The package manager should understand how policy transactions work, 
conflicting modules that must be removed/added within the same 
transaction (such targeted and strict variations of the same policy)

It should also fetch and install policy modules before installing a 
chain of applications, this way the policy isn't rebuilt/reloaded 
between every app that has a policy, which can lead to inconsistancies 
or worse, races.
> 
> thanks -mike
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>