Per Domain Permissive Mode

Per Domain Permissive Mode

[Daniel J Walsh]

Steven mentioned in another conversion the idea of a Per Domain 
Permissive Mode.  This is something our customers are looking for. 

A few customers want to write policy to confine an application but they 
are afraid of releasing it in enforcingmode to hundreds/thousands of 
machines, and then finding out they missed a crucial code path.  The 
would like to be able to write the policy distribute it and gather AVC 
messages in for a couple of months, until they fail confident that the 
policy will work.  Currently they would have to turn all the machines to 
permissive mode or take there chances.  

Having a simple domain that would run in permissive mode while the rest 
of the machine ran enforcing would satisfy this need.

Thoughts...

Dan

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

Re: Per Domain Permissive Mode

[Joshua Brindle]

Daniel J Walsh wrote:
> Steven mentioned in another conversion the idea of a Per Domain 
> Permissive Mode.  This is something our customers are looking for.
> A few customers want to write policy to confine an application but 
> they are afraid of releasing it in enforcingmode to hundreds/thousands 
> of machines, and then finding out they missed a crucial code path.  
> The would like to be able to write the policy distribute it and gather 
> AVC messages in for a couple of months, until they fail confident that 
> the policy will work.  Currently they would have to turn all the 
> machines to permissive mode or take there chances. 
> Having a simple domain that would run in permissive mode while the 
> rest of the machine ran enforcing would satisfy this need.
>
> Thoughts...

I don't think this should be done at the mechanism level. One can create 
a policy that allows everything and also audits it, and turns that into 
policy. This sounds like something SLIDE would be pretty good at (it 
already has a remote agent that monitors logs and pushes policy to 
remote machines).


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

Re: Per Domain Permissive Mode

[James Morris]

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.


-- 
James Morris
<jmorris@namei.org>

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

Re: Per Domain Permissive Mode

[James Morris]

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.

-- 
James Morris
<jmorris@namei.org>

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

Re: Per Domain Permissive Mode

[Karl MacMillan]

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


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

Re: Per Domain Permissive Mode

[Daniel J Walsh]

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.

Re: Per Domain Permissive Mode

[Stephen Smalley]

On Tue, 2007-06-19 at 11:44 -0400, 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.

Yes, while I've often suggested using auditallow+allow rules to yield
per-domain permissive mode in the past, I'm not sure it actually meets
the need fully.  Also, do we truly want per-domain or per-process
permissive mode?

Similar question applies to how we provide "unconfined" domains; to
date, we have done so by generating all of those allow rules, but that
is costly in policy (somewhat mitigated by use of attributes, but
limited especially as we add exception cases).

-- 
Stephen Smalley
National Security Agency


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

Re: Per Domain Permissive Mode

[James Morris]

On Wed, 20 Jun 2007, Stephen Smalley wrote:

> Similar question applies to how we provide "unconfined" domains; to
> date, we have done so by generating all of those allow rules, but that
> is costly in policy (somewhat mitigated by use of attributes, but
> limited especially as we add exception cases).

Do you know how much of the kernel memory we use for policy is used by 
this?


-- 
James Morris
<jmorris@namei.org>

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

Re: Per Domain Permissive Mode

[Stephen Smalley]

On Wed, 2007-06-20 at 07:48 -0400, James Morris wrote:
> On Wed, 20 Jun 2007, Stephen Smalley wrote:
> 
> > Similar question applies to how we provide "unconfined" domains; to
> > date, we have done so by generating all of those allow rules, but that
> > is costly in policy (somewhat mitigated by use of attributes, but
> > limited especially as we add exception cases).
> 
> Do you know how much of the kernel memory we use for policy is used by 
> this?

Not offhand.  As an experiment, I tried building policy with and without
the unconfined module, but that doesn't seem to make a large difference
in the policy file size, so perhaps it isn't so significant anymore.

-- 
Stephen Smalley
National Security Agency


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