SELinux Module Packaging in FC5

Paul Howarth paul at city-fan.org
Wed Jun 21 15:07:26 UTC 2006


Joshua Brindle wrote:
>> From: Paul Howarth [mailto:paul at city-fan.org] 
>>
>> Joshua Brindle wrote:
>>>> From: Paul Howarth [mailto:paul at city-fan.org]
>>>>
>>>> Joshua Brindle wrote:
>>>>>> From: Paul Howarth [mailto:paul at city-fan.org]
>>>>>>
>>>>>> On Tue, 2006-06-20 at 16:12 -0400, Christopher J. PeBenito wrote:
>>>>>>> On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote:
>>>>>>>> On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote:
>>>>>>>>> Paul Howarth wrote:
>>>>>>>>>> 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.
>>>>>>>>>>> If this is going to be common, then semodule_package and 
>>>>>>>>>>> libsemanage need to allow for policy packages that
>>>>>> have no policy module.
>>>>>>> [cut]
>>>>>>>> - Cleanly supporting policy packages that do not include
>>>> a binary
>>>>>>>> policy module in the tools (e.g. semodule_package) and
>>>>>> libraries (e.g.
>>>>>>>> libsemanage, libsepol), so that they can be used to ship
>>>>>> just file
>>>>>>>> contexts or other components.  I don't know of any work
>>>>>> in progress
>>>>>>>> yet on that issue, so it may make sense to bugzilla it,
>>>>>> although it
>>>>>>>> is really an upstream issue, and there isn't presently an
>>>>>> upstream
>>>>>>>> bugzilla for selinux (just the mailing list).
>>>>>>> I was looking at what it would take to support a package
>>>> without a
>>>>>>> module.  Without the binary policy, there is one problem of
>>>>>> where the
>>>>>>> module name and version will come from.  We could either
>>>>>> add this to
>>>>>>> the package itself (which would require a policy package format 
>>>>>>> change), or add a section to the package for module name
>>>>>> and version
>>>>>>> (which seems like a hack to me).
>>>>>> What I'm suggesting isn't a policy package with just file
>>>> contexts,
>>>>>> it's one with no allow/dontaudit rules in the policy, like this:
>>>>>>
>>>>>> ::::::::::::::
>>>>>> contagged.if
>>>>>> ::::::::::::::
>>>>>> # contagged.if
>>>>>> #
>>>>>> # This module has no interfaces
>>>>>> ::::::::::::::
>>>>>> contagged.fc
>>>>>> ::::::::::::::
>>>>>> /var/cache/contagged(/.*)?
>>>>>> gen_context(system_u:object_r:httpd_cache_t,s0)
>>>>>> ::::::::::::::
>>>>>> contagged.te
>>>>>> ::::::::::::::
>>>>>> # 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.3)
>>>>>>
>>>>>> ########################################
>>>>>> #
>>>>>> # Declarations
>>>>>> #
>>>>>>
>>>>>> require {
>>>>>>         type httpd_cache_t;
>>>>>> };
>>>>>>
>>>>>>
>>>>>> ########################################
>>>>>> #
>>>>>> # Local policy
>>>>>> #
>>>>>>
>>>>>> # (none needed)
>>>>>>
>>>>>>> More importantly, I believe a package without a module does
>>>>>> not make
>>>>>>> sense because the types and users used in the file
>>>> contexts should
>>>>>>> either be declared or required by the module in the package.
>>>>>>> Otherwise the transaction fails late when the file contexts are 
>>>>>>> validated, rather than early during linking.
>>>>>> I agree. It would make sense for compilation/linking of 
>> the module 
>>>>>> above to fail if the "require" wasn't present.
>>>>>> Currently that doesn't happen.
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>> Try putting a line with just ; where the rules would go 
>> and see if 
>>>>> that compiles.
>>>> What I'm saying is that the module compiles just fine without the 
>>>> "require" section, and I think it might be better if it 
>> didn't (or at 
>>>> least emitted a warning) since the .fc part references 
>> httpd_cache_t.
>>>> Paul.
>>>>
>>> Not necessarilly. For example, a policy that declares 2 
>> roles and does 
>>> a role allow between them, while not useful, is valid. No 
>> requirements 
>>> would be necessary then.
>> In the example I gave earlier, file context types were used 
>> in the .fc file; I just think it would make sense for these 
>> to be "required" in the same way that they would be if they 
>> were used in the .te file.
>>
>> We're getting away from the original issue here though, which 
>> was for clean support of policy module packages containing 
>> file contexts and no rules, to avoid issues like this:
>>
>> http://www.redhat.com/archives/fedora-selinux-list/2006-May/ms
>> g00104.html
>>
> 
> It would be non-trivial to change the linker to enforce requires in file
> contexts but I agree that it should at least be convention.
> 
> Back to the point, my email a few times back suggested putting a line
> with just ; where the rules would be in order to get a module without
> rules, have you tried that?

Is this with or without the requires clause?

With the requires clause, the semicolon doesn't seem to make any difference.

Paul.





More information about the fedora-selinux-list mailing list