Re: [PATCH] selinuxfs to globally disable dontaudit rules

[Joshua Brindle <method@manicmethod.com>]

Daniel J Walsh wrote:
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> Stephen Smalley wrote:
>>>> On Thu, 2007-08-09 at 21:22 -0400, Joshua Brindle wrote:
>>>>  
>>>>> Joshua Brindle wrote:
>>>>>  
>>>>>> James Morris wrote:
>>>>>>    
>>>>>>> On Thu, 9 Aug 2007, Eric Paris wrote:
>>>>>>>
>>>>>>>  
>>>>>>>      
>>>>>>>> Currently to disable dontaudit rules best you can do it to load 
>>>>>>>> the
>>>>>>>> enableaudit.pp base policy.  Which still doesn't remove the 
>>>>>>>> dontaudit
>>>>>>>> rules from modules.
>>>>>>>>               
>>>>>>> Are we sure this can't be done in userspace?  Like, mangle all 
>>>>>>> the existing policy and reload it?
>>>>>>>
>>>>>>>           
>>>>>> I agree, the infrastructure is certainly in place to do it, just 
>>>>>> add something in the sepol_handle that says dontaudits should be 
>>>>>> discarded, then make an interface in libsemanage that uses that 
>>>>>> and rebuild the policy.
>>>>>>
>>>>>> If noone beats me to it I will see if my conclusions about it 
>>>>>> being fairly simple are accurate this weekend :)
>>>>>>
>>>>>>       
>>>>> I changed my mind, patch below
>>>>>
>>>>> it compiles and seems to work after semodule -DB:
>>>>>     
>>>>
>>>> Hmm...doing it this way means that the "disable_dontaudit" behavior
>>>> won't persist across subsequent policy changes, so if I e.g. then 
>>>> change
>>>> a boolean persistently, I'll get back all of the dontaudit rules too.
>>>>
>>>> Is that what you want, or do you want this flag saved in the policy
>>>> module store and settable/clearable via semanage to be applied to all
>>>> subsequent policy builds?
>>>>
>>>>   
>>> This looks great but it needs to survive a policy rebuild as Stephen 
>>> says.
>>>
>>
>> Hrm... I'm trying to figure out if that is really the behavior we 
>> want. The purpose of this was to let someone get some denials from 
>> (possibly) dontaudits hiding behavior. After switching dontaudits off 
>> the user will generate a module with the rules and insert it. 
>> Assuming they exercised enough of the app he won't want the 
>> dontaudits off anymore and will happily go about running the app. Are 
>> there other use cases where dontaudits should be persistently disabled?
>>
>> If dontaudits are to be persistently disabled I'd rather do it in the 
>> kernel with eric's patch, mainly because eric's will at least only 
>> persist until reboot whereas if I added something to libsemanage to 
>> make it persist it would last across reboots.
>>
> Actually I was thinking of the case where you would put an setsebool 
> in an init script and you might want to boot with enableaudit and this 
> would replace it, but you wouldn't put a setsebool -P in an init 
> script, so this is not a problem.  I would guess we would just have to 
> document that this is to temporarily disable dontaudit rules, until 
> the next time the policy is rebuilt.


So is there any consensus on which approach we want to go with? We have:

1) use conditionals, doesn't work with third party modules, could have 
mistakes where dontaudits aren't in conditionals, etc
2) use the kernel patch from Eric, makes it easier to turn it on and off 
without rebuilding/reloading policy, faster and some people worried 
about policy modification would be happier.
3) use my patch and do it from userland, puts the complexity in 
userspace, modifies the on-disk policy (persistent across reboots if 
policy isn't rebuild without the option, slower to use, not persistent 
across any options that rebuild policy such as persistent boolean 
changes, etc).



I'm split between 2 and 3, both have advantages and disadvantages, 
anyone else want to ring their opinion in?


--
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.