Help with SELinux Policy for Usability Study

Daniel J Walsh dwalsh at redhat.com
Thu Jul 30 14:09:39 UTC 2009


On 07/30/2009 05:15 AM, Dominick Grift wrote:
> On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote:
> 
>> So I am not sure why opera seams to be unconfined, or if removing the
>> permissive line was on the right track. Any advice?
> permissive domains can be used to troubleshoot/develop policy, without
> exposing the whole system.
> 
> eventually, after you've completed the development of your policy , and
> before you deploy your policy you should remove the permissive domain.
> 
> But in development stages a permissive domain makes it easier to debug
> your policy since everything is allowed but would be denials are logged.
> 
> 
>> Thank you,
>>
>> Cliffe.
>>
>> --
>> fedora-selinux-list mailing list
>> fedora-selinux-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>> ------------------------------------------------------------------------
>>
>> --
>> fedora-selinux-list mailing list
>> fedora-selinux-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash.

We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules.  Sort of a learning mode.

I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers.  They are too integrated into the system.  You end up basically creating a usr role since the web browser tends to need to do everything the user can do.




More information about the fedora-selinux-list mailing list