Research Menu

.
Skip Search Box

SELinux Mailing List

Re: Where to specific the handling of unknown kernel classes and perms

From: Joshua Brindle <method_at_manicmethod.com>
Date: Thu, 03 May 2007 11:31:39 -0400


Stephen Smalley wrote:
> On Thu, 2007-05-03 at 09:20 -0400, Joshua Brindle wrote:
> 

>> Stephen Smalley wrote:
>>     
>>> On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
>>>   
>>>       
>>>> Eric Paris wrote:
>>>>     
>>>>         
>>>>> I just sent out a kernel patch with the tristate flag to change kernel
>>>>> handling of unknown classes and permissions.  The idea is that when the
>>>>> policy is created someone can set the flag to any of the three options
>>>>> (deny/reject/allow) and the kernel will act accordingly.  My problem is
>>>>> I don't understand the userspace tools which create policy.  I patched
>>>>> libsepol to support this new flag when it reads or writes a policydb,
>>>>> which allows me to edit my policy.21 by hand in hex and then call
>>>>> load_policy to test my kernel.  My problem now is that I don't know
>>>>> where a user should be specifying how they want the flags to be set.  To
>>>>> be perfectly honest after a bit of searching I'm not even sure where
>>>>> policy.21 gets created when I build a policy.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> It should be setable in semanage.conf or by checkpolicy if building a 
>>>> monolithic policy.
>>>>     
>>>>         
>>> Hmm...actually, I would have argued that it should only be settable by
>>> checkpolicy/checkmodule, and always inherited from the base module in
>>> the link/expand case.  That way we can always know what the kernel
>>> behavior is by looking at the base module, vs. having to separately look
>>> at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
>>> ease of customization
>>>       
>> Even if it is propagated from the base policy I think it should be 
>> overridable in semanage.conf. Propagating it from base means we'll have 
>> to extend the policy server object model to cover it but that is no big 
>> deal. The reason semanage.conf would be nice is to change the behavior 
>> locally on RH systems without rebuilding the base policy.
>>     
>

> I understand that, but as semanage.conf is not "managed" (just a config
> file to rpm and not managed by libsemanage itself) and changes to it are
> not audited, this means that you won't be able to tell easily what
> behavior was in effect at a given time. That's the tradeoff.
>

> Regardless, for Eric's purposes, it would be sufficient for basic
> operation to add a command line flag to checkpolicy and checkmodule to
> set these flags in monolithic policy and base modules, and to modify
> libsepol (in particular, expand_module()) to propagate the base flags in
> the same manner as it already does for the mls flag. Then he or we can
> separately add a libsepol interface to mutate the flag and modify
> libsemanage to use that interface and have a new semanage.conf setting.
>
>

Ok, I agree, we can work out how to change it on end systems without rebuilding the policy later. This should certainly be a managed setting so that we can enforce access control on it and audit if necessary. 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
Received on Thu 3 May 2007 - 11:31:53 EDT
 

Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009

  
bottom
National Security Agency / Central Security Service