SELinux Module Packaging in FC5

[Paul Howarth]

Stephen Smalley wrote:
> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote:
>> It contains a policy module, but the module only includes file contexts.
> 
> Clarification:  it is a policy package (.pp), but the policy package
> only includes file contexts.  The module itself is just the .mod file
> created by checkmodule; it never includes file contexts.

Ah, right, thanks for the clarification.

> If this is going to be common, then semodule_package and libsemanage
> need to allow for policy packages that have no policy module.

I think it is, because changes to file contexts are much more easily 
managed using semodule, since the policy packages are versioned and 
semodule will always do the right thing when any newer version is installed.

The alternative, using semanage to tweak file contexts, could quickly 
become unmanageable. For example, suppose package foo went through some 
major revisions, moving files around the filesystem hierarchy that 
needed custom contexts. So the first version of the package would 
contain an semanage call to set contexts for say:

/var/www/foo/cache(/.*)

The next version moved the cache directory to /var/cache/foo, so a 
package upgrade would need to remove the context object set up in the 
first version and create a new one for:

/var/cache/foo(/.*)

There might then be an upstream name change from foo to bar, requiring 
contexts for:

/var/cache/bar(/.*)

The %post script for this package would need to identify the version of 
the package being upgraded (none, foo-1, foo-2, or bar), remove the 
appropriate context object (none, /var/www/foo/cache(/.*), 
/var/cache/foo(/.*)) if necessary and then install the new context object.

Using semanage, if the policy package remained as foo.pp throughout, 
"semodule -i foo.pp" would always do the right thing. If for the last 
version, the policy package changed to bar.pp, it could do "semodule -r 
foo.pp" first and discard any error messages or failure codes before 
running "semodule -i bar.pp". Much better I think.

>> The .te file is just:
>> ---------------------------------------------------------------------
>> # It's currently only necessary to set file contexts for the cache directory
>> # in this policy, but doing it in a module is easier from a package 
>> maintenance
>> # point of view than using semanage and chcon in scriptlets
>>
>> policy_module(contagged, 0.1)
> 
> This pulls in requires statements for the kernel classes and
> permissions.  Which it seems are being confused with an attempt to
> declare classes/permissions in the module by the older libsepol.
> 
>> The .fc file is:
>> ---------------------------------------------------------------------
>> /var/cache/contagged(/.*)? 
>> gen_context(system_u:object_r:httpd_cache_t,s0)
>> ---------------------------------------------------------------------
> 
> You can't use gen_context() there, can you?  I thought it had to be
> preprocessed already.

I just copied from other .fc files I found in the policy sources, and it 
seems to work (usually). If I'm wrong, what should I be using?

>> The module was built on a system with:
>> $ rpm -q selinux-policy-targeted libsepol libsemanage
>> selinux-policy-targeted-2.2.38-1.fc5
>> libsepol-1.12.6-1.fc5
>> libsemanage-1.6.2-2.fc5
>>
>> The error occurred when the package was installed on a system with:
>> $ rpm -q selinux-policy-targeted libsepol libsemanage
>> selinux-policy-targeted-2.2.34-3.fc5
>> libsepol-1.12.4-1.fc5
>> libsemanage-1.6.2-2.fc5
> 
> Hmmm...and what version of checkmodule was used to build it?

$ rpm -q checkpolicy
checkpolicy-1.30.3-1.fc5

Paul.