Re: Per Domain Permissive Mode

[Daniel J Walsh <dwalsh@redhat.com>]

Karl MacMillan wrote:
> On Tue, 2007-06-19 at 11:19 -0400, James Morris wrote:
>   
>> On Tue, 19 Jun 2007, James Morris wrote:
>>
>>     
>>> On Tue, 19 Jun 2007, Daniel J Walsh wrote:
>>>
>>>       
>>>> Thoughts...
>>>>         
>>> We can do this in policy: define a domain which runs with all accessess 
>>> allowed, and also optionally logged for profiling purposes.
>>>       
>> Actually, this is not entirely useful for development -- perhaps some kind 
>> of abstraction can be used to hide all of the allow rules, so it just 
>> appears to the policy developer that the domain is in permissive mode.
>>
>>     
>
> The complicated bit is actually the auditallow rules to get similar
> auditing to permissive. We only want to add auditallow rules for the
> extra access allowed to make the domain unconfined not for all access
> allowed by the domain. That basically means parsing the module, figuring
> out what was allowed, and adding auditallow for the difference between
> that access and unconfined.
>
> Sepolgen is almost at a point it can do this. Slide, as far as I know,
> doesn't parse the access in sufficient detail to do this yet.
>
> One downside to this approach is teaching policy generation tools to
> generate access for granted messages in the log. It also makes explicit
> auditallow somewhat useless.
>
> Karl
>
>   
One interesting twist would be if dontaudit rules were enforced.  For 
example when an app uses pam, it attempts to read/write /etc/shadow.
Most apps have this dontaudited so a different code path gets walked 
within pam.  If we just run the app totally in permissive mode, the app
will not hit this code path, until it gets out in the wild in enforcing 
mode.


So the algorithm should be something like the following

newallowrules = unconfined_domain - ( allowrules + dontauditrules )

permissiveconfineddomain = newallowrules + allowrules + dontauditrules + 
{ auditallow newallowrules }


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