concept of a permissive domain

concept of a permissive domain

[Eric Paris]

So there was a brief conversation between dan, karl, and myself today
about implementing a permissive subject domain.  Basically there would
be some new language construct possibly "permissive httpd_t true;" which
would then set a flag.  If this flag was set, all denials would be
logged but the operation would be permitted.  This would make it
possible to create a type_exec_t and type_t for your new domain, mark it
as permissive/unconfined and run it as long as you like.  Once you get
all your new allow rules you just remove the permissive bit.  You didn't
have to setenforce the whole system.

First thought from Karl was to use the 'char primary' field of the
struct type_datum.  Seems reasonable enough, after we have that
information in kernel it shouldn't take me too much playing around in
avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
think slowing down the denial path a little by having to call back in to
see if this flag was set for a given source sid is that big of deal.
Maybe I could keep it just about as fast by adding more flags
audit_allow_once (can't really reuse audit_allow) to the avd or
something like that, but it seems like a large waste of space to carry
another set of audit flags that won't be used much.

Thoughts?  Other ways to implement this?  Problems with the basic premis
of an unconfined domain?

-Eric


--
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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> So there was a brief conversation between dan, karl, and myself today
> about implementing a permissive subject domain.  Basically there would
> be some new language construct possibly "permissive httpd_t true;" which
> would then set a flag.  If this flag was set, all denials would be
> logged but the operation would be permitted.  This would make it
> possible to create a type_exec_t and type_t for your new domain, mark it
> as permissive/unconfined and run it as long as you like.  Once you get
> all your new allow rules you just remove the permissive bit.  You didn't
> have to setenforce the whole system.
> 
> First thought from Karl was to use the 'char primary' field of the
> struct type_datum.  Seems reasonable enough, after we have that
> information in kernel it shouldn't take me too much playing around in
> avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> think slowing down the denial path a little by having to call back in to
> see if this flag was set for a given source sid is that big of deal.
> Maybe I could keep it just about as fast by adding more flags
> audit_allow_once (can't really reuse audit_allow) to the avd or
> something like that, but it seems like a large waste of space to carry
> another set of audit flags that won't be used much.
> 
> Thoughts?  Other ways to implement this?  Problems with the basic premis
> of an unconfined domain?
> 
> -Eric
> 
> 
> --
> 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.

Lets not call it an unconfined domain.   This is a permissive domain.
The idea is to collect avc messages as if it was confined, and allow me
to write policy based on this.

This would solve several problems.

1. Customers want to be able to write policy and distribute it within
their environments and let it run for a couple of months in permissive
mode,  Continuously gathering AVC messages and updating policy.  When
they are satisfied that the policy works as defined.  They can turn off
the permissive mode and have a feeling of confidence that the policy
will not break their application.  They fear that putting  out too
restrictive of a policy will cause them to loose money.
2. Customers are upset that they lost disable_trans, because they
sometimes want to say just let a domain run and don't care about it.
So if they could turn that domain to permissive they could maintain
their security on other domains.  Currently they have to put the machine
in permissive mode or become policy writers.  (chcon -t bin_t works but
does not survive a relabel)

3 When writing policy we currently tell people to turn their machine to
permissive, which is a security risk.  If we could just run the domain
in permissive mode, we would not decrease the overall security of the
system.

4 Finally as we introduce the concept of confined user domains, it would
be interesting to apply a confined admin domain to a admin user and then
record the avc's he generates while in permissive mode.  It would allow
us to better understand the needs of a admin user.

One other feature/requirement would be to not override dontaudit rules.
So if I have a domain in permissive mode and I have a dontaudit rule  on
reading /etc/shadow.  The app should still be denied reading
/etc/shadow.  (This is not a show stopper, but would allow us to force
apps to take the code paths they will take in enforcing mode.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG5vslrlYvE4MpobMRAphWAKDrykJk05Y3gUT+8zB9ZLJGtp8c/QCfXRoh
pzE/k8a/YDqE/FIKadMDxy0=
=GtJx
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Karl MacMillan]

On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
[...]
> One other feature/requirement would be to not override dontaudit rules.
> So if I have a domain in permissive mode and I have a dontaudit rule  on
> reading /etc/shadow.  The app should still be denied reading
> /etc/shadow.  (This is not a show stopper, but would allow us to force
> apps to take the code paths they will take in enforcing mode.)

This isn't specific to per-domain permissive, right? It would be useful
in general for permissive.

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: concept of a permissive domain

[Eric Paris]

On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> [...]
> > One other feature/requirement would be to not override dontaudit rules.
> > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > reading /etc/shadow.  The app should still be denied reading
> > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > apps to take the code paths they will take in enforcing mode.)
> 
> This isn't specific to per-domain permissive, right? It would be useful
> in general for permissive.

You know, I'm quite happy that setenforce=0 ALWAYS means 'not selinux
fault'   not sure I'm comfortable with changing that, although I have no
problem with dan's suggestion....


--
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: concept of a permissive domain

[Joshua Brindle]

Eric Paris wrote:
> So there was a brief conversation between dan, karl, and myself today
> about implementing a permissive subject domain.  Basically there would
> be some new language construct possibly "permissive httpd_t true;" which
> would then set a flag.  If this flag was set, all denials would be
> logged but the operation would be permitted.  This would make it
> possible to create a type_exec_t and type_t for your new domain, mark it
> as permissive/unconfined and run it as long as you like.  Once you get
> all your new allow rules you just remove the permissive bit.  You didn't
> have to setenforce the whole system.
>
> First thought from Karl was to use the 'char primary' field of the
> struct type_datum.  Seems reasonable enough, after we have that
> information in kernel it shouldn't take me too much playing around in
> avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> think slowing down the denial path a little by having to call back in to
> see if this flag was set for a given source sid is that big of deal.
> Maybe I could keep it just about as fast by adding more flags
> audit_allow_once (can't really reuse audit_allow) to the avd or
> something like that, but it seems like a large waste of space to carry
> another set of audit flags that won't be used much.
>
> Thoughts?  Other ways to implement this?  Problems with the basic premis
> of an unconfined domain?
>   

This is asking for all kinds of problems. Writes to directories without 
type transitions means after a policy is written, if the correct 
refpolicy interface is used that defines a transition, then any files 
written during 'permissive mode' won't be accessible. Domain transitions 
are in the same boat, imagine what domains processes could end up 
running in during this. We need to tread very carefully here, and there 
are interesting ramifications to transitioning to and from the 
permissive domains during runtime. If an application has a transition to 
the permissive domain a new attack vector was just introduced. I know 
this can be helpful and its better than running the entire system in 
permissive but it can also be dangerous.


--
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: concept of a permissive domain

[Karl MacMillan]

On Tue, 2007-09-11 at 18:57 -0400, Joshua Brindle wrote:
> Eric Paris wrote:
> > So there was a brief conversation between dan, karl, and myself today
> > about implementing a permissive subject domain.  Basically there would
> > be some new language construct possibly "permissive httpd_t true;" which
> > would then set a flag.  If this flag was set, all denials would be
> > logged but the operation would be permitted.  This would make it
> > possible to create a type_exec_t and type_t for your new domain, mark it
> > as permissive/unconfined and run it as long as you like.  Once you get
> > all your new allow rules you just remove the permissive bit.  You didn't
> > have to setenforce the whole system.
> >
> > First thought from Karl was to use the 'char primary' field of the
> > struct type_datum.  Seems reasonable enough, after we have that
> > information in kernel it shouldn't take me too much playing around in
> > avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> > think slowing down the denial path a little by having to call back in to
> > see if this flag was set for a given source sid is that big of deal.
> > Maybe I could keep it just about as fast by adding more flags
> > audit_allow_once (can't really reuse audit_allow) to the avd or
> > something like that, but it seems like a large waste of space to carry
> > another set of audit flags that won't be used much.
> >
> > Thoughts?  Other ways to implement this?  Problems with the basic premis
> > of an unconfined domain?
> >   
> 
> This is asking for all kinds of problems. Writes to directories without 
> type transitions means after a policy is written, if the correct 
> refpolicy interface is used that defines a transition, then any files 
> written during 'permissive mode' won't be accessible.

The type transitions should continue to occur just like in global
permissive.

>  Domain transitions 
> are in the same boat, imagine what domains processes could end up 
> running in during this.

Again, the domain transitions should happen normally. How is this
different from using global permissive for policy development?

>  We need to tread very carefully here, and there 
> are interesting ramifications to transitioning to and from the 
> permissive domains during runtime. If an application has a transition to 
> the permissive domain a new attack vector was just introduced. I know 
> this can be helpful and its better than running the entire system in 
> permissive but it can also be dangerous.
> 

Of course it could be dangerous - but it would also be incredibly
useful. And how is it worse than an unconfined domain?

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: concept of a permissive domain

[Karl MacMillan]

On Tue, 2007-09-11 at 17:47 -0400, Eric Paris wrote:
> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > [...]
> > > One other feature/requirement would be to not override dontaudit rules.
> > > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > > reading /etc/shadow.  The app should still be denied reading
> > > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > > apps to take the code paths they will take in enforcing mode.)
> > 
> > This isn't specific to per-domain permissive, right? It would be useful
> > in general for permissive.
> 
> You know, I'm quite happy that setenforce=0 ALWAYS means 'not selinux
> fault'   not sure I'm comfortable with changing that, although I have no
> problem with dan's suggestion....
> 

Well, there are very rare circumstances where permissive can still cause
problems, but your general point is well taken.

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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl MacMillan wrote:
> On Tue, 2007-09-11 at 17:47 -0400, Eric Paris wrote:
>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>> [...]
>>>> One other feature/requirement would be to not override dontaudit rules.
>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
>>>> reading /etc/shadow.  The app should still be denied reading
>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>> apps to take the code paths they will take in enforcing mode.)
>>> This isn't specific to per-domain permissive, right? It would be useful
>>> in general for permissive.
>> You know, I'm quite happy that setenforce=0 ALWAYS means 'not selinux
>> fault'   not sure I'm comfortable with changing that, although I have no
>> problem with dan's suggestion....
>>
> 
> Well, there are very rare circumstances where permissive can still cause
> problems, but your general point is well taken.
> 
> Karl
> 
I agree, the precedence has been set, so I think we need to leave
setenforce 0 as is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG5/BZrlYvE4MpobMRAp4hAKC+Agh5M+6stj+8OPTi0G1i1iy1BACglHMO
PVW9eHNHj9ww+VMXTG/N0nY=
=zoo4
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Stephen Smalley]

On Tue, 2007-09-11 at 15:13 -0400, Eric Paris wrote:
> So there was a brief conversation between dan, karl, and myself today
> about implementing a permissive subject domain.  Basically there would
> be some new language construct possibly "permissive httpd_t true;" which
> would then set a flag.  If this flag was set, all denials would be
> logged but the operation would be permitted.  This would make it
> possible to create a type_exec_t and type_t for your new domain, mark it
> as permissive/unconfined and run it as long as you like.  Once you get
> all your new allow rules you just remove the permissive bit.  You didn't
> have to setenforce the whole system.
> 
> First thought from Karl was to use the 'char primary' field of the
> struct type_datum.  Seems reasonable enough, after we have that
> information in kernel it shouldn't take me too much playing around in
> avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> think slowing down the denial path a little by having to call back in to
> see if this flag was set for a given source sid is that big of deal.
> Maybe I could keep it just about as fast by adding more flags
> audit_allow_once (can't really reuse audit_allow) to the avd or
> something like that, but it seems like a large waste of space to carry
> another set of audit flags that won't be used much.
> 
> Thoughts?  Other ways to implement this?  Problems with the basic premis
> of an unconfined domain?

I used to argue that we didn't need it because you could make a domain
unconfined in policy and then add auditallow statements to generate avc:
granted messages, and then generate policy from those messages.  But it
isn't quite the same thing, as permissive mode does nice things like
only auditing the first occurrence of the denial (otherwise we flood the
audit system), and existing tools only look at avc:  denied messages.
So I'm not fundamentally opposed to the idea.

Is it truly something we want expressed in policy, or something that
should just be controlled via selinuxfs (i.e. create
a /selinux/permissive directory with one node per domain, and let you
write a 0 or 1 to those nodes to make them permissive or enforcing)?
The latter would be more akin to the existing permissive mode and avoid
needing to change anything in policy.  Should be subject to a kernel
config option too, so we can still build kernels with no permissive
support at all.

-- 
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: concept of a permissive domain

[Karl MacMillan]

On Thu, 2007-09-13 at 09:11 -0400, Stephen Smalley wrote:
> On Tue, 2007-09-11 at 15:13 -0400, Eric Paris wrote:
> > So there was a brief conversation between dan, karl, and myself today
> > about implementing a permissive subject domain.  Basically there would
> > be some new language construct possibly "permissive httpd_t true;" which
> > would then set a flag.  If this flag was set, all denials would be
> > logged but the operation would be permitted.  This would make it
> > possible to create a type_exec_t and type_t for your new domain, mark it
> > as permissive/unconfined and run it as long as you like.  Once you get
> > all your new allow rules you just remove the permissive bit.  You didn't
> > have to setenforce the whole system.
> > 
> > First thought from Karl was to use the 'char primary' field of the
> > struct type_datum.  Seems reasonable enough, after we have that
> > information in kernel it shouldn't take me too much playing around in
> > avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> > think slowing down the denial path a little by having to call back in to
> > see if this flag was set for a given source sid is that big of deal.
> > Maybe I could keep it just about as fast by adding more flags
> > audit_allow_once (can't really reuse audit_allow) to the avd or
> > something like that, but it seems like a large waste of space to carry
> > another set of audit flags that won't be used much.
> > 
> > Thoughts?  Other ways to implement this?  Problems with the basic premis
> > of an unconfined domain?
> 
> I used to argue that we didn't need it because you could make a domain
> unconfined in policy and then add auditallow statements to generate avc:
> granted messages, and then generate policy from those messages.  But it
> isn't quite the same thing, as permissive mode does nice things like
> only auditing the first occurrence of the denial (otherwise we flood the
> audit system), and existing tools only look at avc:  denied messages.
> So I'm not fundamentally opposed to the idea.
> 
> Is it truly something we want expressed in policy, or something that
> should just be controlled via selinuxfs (i.e. create
> a /selinux/permissive directory with one node per domain, and let you
> write a 0 or 1 to those nodes to make them permissive or enforcing)?
> The latter would be more akin to the existing permissive mode and avoid
> needing to change anything in policy.  Should be subject to a kernel
> config option too, so we can still build kernels with no permissive
> support at all.
> 

I suggested the policy option because:

* it needs to persist across reboots and putting it in the policy makes
that simple.
* some of our customers want this to be used on production systems, so
the ability to analyze policy taking into account permissive domains
seems desirable.

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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 09:19 -0400, Karl MacMillan wrote:
> On Thu, 2007-09-13 at 09:11 -0400, Stephen Smalley wrote:
> > On Tue, 2007-09-11 at 15:13 -0400, Eric Paris wrote:
> > > So there was a brief conversation between dan, karl, and myself today
> > > about implementing a permissive subject domain.  Basically there would
> > > be some new language construct possibly "permissive httpd_t true;" which
> > > would then set a flag.  If this flag was set, all denials would be
> > > logged but the operation would be permitted.  This would make it
> > > possible to create a type_exec_t and type_t for your new domain, mark it
> > > as permissive/unconfined and run it as long as you like.  Once you get
> > > all your new allow rules you just remove the permissive bit.  You didn't
> > > have to setenforce the whole system.
> > > 
> > > First thought from Karl was to use the 'char primary' field of the
> > > struct type_datum.  Seems reasonable enough, after we have that
> > > information in kernel it shouldn't take me too much playing around in
> > > avc_has_perm_noaudit to check if this flag is set on a denial.  I don't
> > > think slowing down the denial path a little by having to call back in to
> > > see if this flag was set for a given source sid is that big of deal.
> > > Maybe I could keep it just about as fast by adding more flags
> > > audit_allow_once (can't really reuse audit_allow) to the avd or
> > > something like that, but it seems like a large waste of space to carry
> > > another set of audit flags that won't be used much.
> > > 
> > > Thoughts?  Other ways to implement this?  Problems with the basic premis
> > > of an unconfined domain?
> > 
> > I used to argue that we didn't need it because you could make a domain
> > unconfined in policy and then add auditallow statements to generate avc:
> > granted messages, and then generate policy from those messages.  But it
> > isn't quite the same thing, as permissive mode does nice things like
> > only auditing the first occurrence of the denial (otherwise we flood the
> > audit system), and existing tools only look at avc:  denied messages.
> > So I'm not fundamentally opposed to the idea.
> > 
> > Is it truly something we want expressed in policy, or something that
> > should just be controlled via selinuxfs (i.e. create
> > a /selinux/permissive directory with one node per domain, and let you
> > write a 0 or 1 to those nodes to make them permissive or enforcing)?

On second thought, that should likely instead be a /selinux/domains
directory with one subdirectory per domain and an "enforce" node in each
subdirectory, so that it more closely matches the
existing /selinux/enforce interface and so that we can later add other
domain-related state and settings there.

> > The latter would be more akin to the existing permissive mode and avoid
> > needing to change anything in policy.  Should be subject to a kernel
> > config option too, so we can still build kernels with no permissive
> > support at all.
> > 
> 
> I suggested the policy option because:
> 
> * it needs to persist across reboots and putting it in the policy makes
> that simple.

Put:
echo -n 0 > /selinux/domains/httpd_t/enforce
in the /etc/init.d/httpd script and you're done.
But I'm not sure when/why you want that anyway.

> * some of our customers want this to be used on production systems, so
> the ability to analyze policy taking into account permissive domains
> seems desirable.

I don't quite follow that - if you are enabling permissive mode (whether
system-wide or per-domain) in production use, what can you meaningfully
say anyway in terms of "analysis" - all information flow is possible
through that domain, period. 

Also, consider the parallel with the system-wide enforcing mode or with
non-persistent boolean settings.

Analysis tools can of course read the current settings from selinuxfs if
they want to assess the current state of the machine.

-- 
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: concept of a permissive domain

[Eric Paris]

On Thu, 2007-09-13 at 09:25 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 09:19 -0400, Karl MacMillan wrote:

> > > Is it truly something we want expressed in policy, or something that
> > > should just be controlled via selinuxfs (i.e. create
> > > a /selinux/permissive directory with one node per domain, and let you
> > > write a 0 or 1 to those nodes to make them permissive or enforcing)?
> 
> On second thought, that should likely instead be a /selinux/domains
> directory with one subdirectory per domain and an "enforce" node in each
> subdirectory, so that it more closely matches the
> existing /selinux/enforce interface and so that we can later add other
> domain-related state and settings there.
> 
> > > The latter would be more akin to the existing permissive mode and avoid
> > > needing to change anything in policy.  Should be subject to a kernel
> > > config option too, so we can still build kernels with no permissive
> > > support at all.
> > > 
> > 
> > I suggested the policy option because:
> > 
> > * it needs to persist across reboots and putting it in the policy makes
> > that simple.
> 
> Put:
> echo -n 0 > /selinux/domains/httpd_t/enforce
> in the /etc/init.d/httpd script and you're done.
> But I'm not sure when/why you want that anyway.

I, the IT guy, just wrote policy for my large trading application.  Here
on my machine/test environment I tried to test it every way I could to
exercise all of the code but I probably missed something.  If I break
this application in production we lose X amount of money and I'm out of
a job.  How many such people would pull that application out from
unconfined_t ???

How many would be willing to run the application in a permissive domain
for 3 months to see how many code paths they missed?  Only then removing
the permissive portion of that domain and 'using' selinux.
Maybe they could do it in their init script, but now they have to
somehow manage their initscripts and their policy together.  Its never
easy to make sure that multiple packages are updated at the same time,
we've seen that over and over.  On an application like this, I wouldn't
even be surprised if they couldn't add such a thing to startup due to
some arcane requirement from the propietary vendor or just their own in
shop policies.  

Then again do we really want to give initscripts the power to decide
themselves if they are going to be confined or not?  /me doesn't think
giving initscripts loadpolicy permissions is a very good idea, nor does
giving a domain permission to turn on/off its own permissiveness....

> 
> > * some of our customers want this to be used on production systems, so
> > the ability to analyze policy taking into account permissive domains
> > seems desirable.
> 
> I don't quite follow that - if you are enabling permissive mode (whether
> system-wide or per-domain) in production use, what can you meaningfully
> say anyway in terms of "analysis" - all information flow is possible
> through that domain, period. 
> 
> Also, consider the parallel with the system-wide enforcing mode or with
> non-persistent boolean settings.
> 
> Analysis tools can of course read the current settings from selinuxfs if
> they want to assess the current state of the machine.

Wow, I can't believe I just heard that after being railed on for
considering using selinuxfs for things like handle_unknown (something
which specifically doesn't have large atomicity issues like compat_net)
Wasn't your main argument post analysis tools?  I can't imagine anything
worse than this to see how the system was set up.  Now when you do
analysis you need to look at 'setenforce' 'compat_net' 'the booleans'
and 'every single friggin type on the whole system.'  Your list of
things to look at in selinuxfs just got a bit larger....

I guess I'm in favor of doing it in policy...

-Eric


--
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: concept of a permissive domain

[Stephen Smalley]

On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> [...]
> > One other feature/requirement would be to not override dontaudit rules.
> > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > reading /etc/shadow.  The app should still be denied reading
> > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > apps to take the code paths they will take in enforcing mode.)
> 
> This isn't specific to per-domain permissive, right? It would be useful
> in general for permissive.

I would be opposed to such a change, as it is a semantic change to what
dontaudit means.

Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
independent of one another today and none of them imply the other, e.g.
	allow a b:file read;
	auditallow a b:file *;
	dontaudit a b:file *;
is perfectly valid and means:
- Let a read files labeled b,
- Audit all permission grantings from a to files labeled b,
- Don't audit any permission denials from a to files labeled b.

-- 
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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 09:59 -0400, Eric Paris wrote:
> On Thu, 2007-09-13 at 09:25 -0400, Stephen Smalley wrote:
> > On Thu, 2007-09-13 at 09:19 -0400, Karl MacMillan wrote:
> 
> > > > Is it truly something we want expressed in policy, or something that
> > > > should just be controlled via selinuxfs (i.e. create
> > > > a /selinux/permissive directory with one node per domain, and let you
> > > > write a 0 or 1 to those nodes to make them permissive or enforcing)?
> > 
> > On second thought, that should likely instead be a /selinux/domains
> > directory with one subdirectory per domain and an "enforce" node in each
> > subdirectory, so that it more closely matches the
> > existing /selinux/enforce interface and so that we can later add other
> > domain-related state and settings there.
> > 
> > > > The latter would be more akin to the existing permissive mode and avoid
> > > > needing to change anything in policy.  Should be subject to a kernel
> > > > config option too, so we can still build kernels with no permissive
> > > > support at all.
> > > > 
> > > 
> > > I suggested the policy option because:
> > > 
> > > * it needs to persist across reboots and putting it in the policy makes
> > > that simple.
> > 
> > Put:
> > echo -n 0 > /selinux/domains/httpd_t/enforce
> > in the /etc/init.d/httpd script and you're done.
> > But I'm not sure when/why you want that anyway.
> 
> I, the IT guy, just wrote policy for my large trading application.  Here
> on my machine/test environment I tried to test it every way I could to
> exercise all of the code but I probably missed something.  If I break
> this application in production we lose X amount of money and I'm out of
> a job.  How many such people would pull that application out from
> unconfined_t ???
> 
> How many would be willing to run the application in a permissive domain
> for 3 months to see how many code paths they missed?  Only then removing
> the permissive portion of that domain and 'using' selinux.
> Maybe they could do it in their init script, but now they have to
> somehow manage their initscripts and their policy together.  Its never
> easy to make sure that multiple packages are updated at the same time,
> we've seen that over and over.  On an application like this, I wouldn't
> even be surprised if they couldn't add such a thing to startup due to
> some arcane requirement from the propietary vendor or just their own in
> shop policies.  
> 
> Then again do we really want to give initscripts the power to decide
> themselves if they are going to be confined or not?  /me doesn't think
> giving initscripts loadpolicy permissions is a very good idea, nor does
> giving a domain permission to turn on/off its own permissiveness....
> 
> > 
> > > * some of our customers want this to be used on production systems, so
> > > the ability to analyze policy taking into account permissive domains
> > > seems desirable.
> > 
> > I don't quite follow that - if you are enabling permissive mode (whether
> > system-wide or per-domain) in production use, what can you meaningfully
> > say anyway in terms of "analysis" - all information flow is possible
> > through that domain, period. 
> > 
> > Also, consider the parallel with the system-wide enforcing mode or with
> > non-persistent boolean settings.
> > 
> > Analysis tools can of course read the current settings from selinuxfs if
> > they want to assess the current state of the machine.
> 
> Wow, I can't believe I just heard that after being railed on for
> considering using selinuxfs for things like handle_unknown (something
> which specifically doesn't have large atomicity issues like compat_net)
> Wasn't your main argument post analysis tools?  I can't imagine anything
> worse than this to see how the system was set up.  Now when you do
> analysis you need to look at 'setenforce' 'compat_net' 'the booleans'
> and 'every single friggin type on the whole system.'  Your list of
> things to look at in selinuxfs just got a bit larger....
> 
> I guess I'm in favor of doing it in policy...

Permissive mode (system-wide or per-domain) means that there is no
meaningful analysis possible.  It is purely a development tool for
helping to discover an application's behavior as input into creating a
policy.

In your scenario, the same person supplying the application and its
policy is likely also supplying its init script.  Thus, allowing them to
make their domain permissive in policy isn't substantively different
than allowing them to make it permissive in their init script (which
should not be running in the same domain as the application itself -
init scripts generally require different sets of permissions).

I see permissive mode (system-wide or per-domain) as purely as
development tool.  Certain users may choose to employ it in production
systems as you say, but those users aren't going to be the ones worried
about analyzable or certifiable policy, eh?

-- 
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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 10:23 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 09:59 -0400, Eric Paris wrote:
> > On Thu, 2007-09-13 at 09:25 -0400, Stephen Smalley wrote:
> > > On Thu, 2007-09-13 at 09:19 -0400, Karl MacMillan wrote:
> > 
> > > > > Is it truly something we want expressed in policy, or something that
> > > > > should just be controlled via selinuxfs (i.e. create
> > > > > a /selinux/permissive directory with one node per domain, and let you
> > > > > write a 0 or 1 to those nodes to make them permissive or enforcing)?
> > > 
> > > On second thought, that should likely instead be a /selinux/domains
> > > directory with one subdirectory per domain and an "enforce" node in each
> > > subdirectory, so that it more closely matches the
> > > existing /selinux/enforce interface and so that we can later add other
> > > domain-related state and settings there.
> > > 
> > > > > The latter would be more akin to the existing permissive mode and avoid
> > > > > needing to change anything in policy.  Should be subject to a kernel
> > > > > config option too, so we can still build kernels with no permissive
> > > > > support at all.
> > > > > 
> > > > 
> > > > I suggested the policy option because:
> > > > 
> > > > * it needs to persist across reboots and putting it in the policy makes
> > > > that simple.
> > > 
> > > Put:
> > > echo -n 0 > /selinux/domains/httpd_t/enforce
> > > in the /etc/init.d/httpd script and you're done.
> > > But I'm not sure when/why you want that anyway.
> > 
> > I, the IT guy, just wrote policy for my large trading application.  Here
> > on my machine/test environment I tried to test it every way I could to
> > exercise all of the code but I probably missed something.  If I break
> > this application in production we lose X amount of money and I'm out of
> > a job.  How many such people would pull that application out from
> > unconfined_t ???
> > 
> > How many would be willing to run the application in a permissive domain
> > for 3 months to see how many code paths they missed?  Only then removing
> > the permissive portion of that domain and 'using' selinux.
> > Maybe they could do it in their init script, but now they have to
> > somehow manage their initscripts and their policy together.  Its never
> > easy to make sure that multiple packages are updated at the same time,
> > we've seen that over and over.  On an application like this, I wouldn't
> > even be surprised if they couldn't add such a thing to startup due to
> > some arcane requirement from the propietary vendor or just their own in
> > shop policies.  
> > 
> > Then again do we really want to give initscripts the power to decide
> > themselves if they are going to be confined or not?  /me doesn't think
> > giving initscripts loadpolicy permissions is a very good idea, nor does
> > giving a domain permission to turn on/off its own permissiveness....
> > 
> > > 
> > > > * some of our customers want this to be used on production systems, so
> > > > the ability to analyze policy taking into account permissive domains
> > > > seems desirable.
> > > 
> > > I don't quite follow that - if you are enabling permissive mode (whether
> > > system-wide or per-domain) in production use, what can you meaningfully
> > > say anyway in terms of "analysis" - all information flow is possible
> > > through that domain, period. 
> > > 
> > > Also, consider the parallel with the system-wide enforcing mode or with
> > > non-persistent boolean settings.
> > > 
> > > Analysis tools can of course read the current settings from selinuxfs if
> > > they want to assess the current state of the machine.
> > 
> > Wow, I can't believe I just heard that after being railed on for
> > considering using selinuxfs for things like handle_unknown (something
> > which specifically doesn't have large atomicity issues like compat_net)
> > Wasn't your main argument post analysis tools?  I can't imagine anything
> > worse than this to see how the system was set up.  Now when you do
> > analysis you need to look at 'setenforce' 'compat_net' 'the booleans'
> > and 'every single friggin type on the whole system.'  Your list of
> > things to look at in selinuxfs just got a bit larger....
> > 
> > I guess I'm in favor of doing it in policy...
> 
> Permissive mode (system-wide or per-domain) means that there is no
> meaningful analysis possible.  It is purely a development tool for
> helping to discover an application's behavior as input into creating a
> policy.
> 
> In your scenario, the same person supplying the application and its
> policy is likely also supplying its init script.  Thus, allowing them to
> make their domain permissive in policy isn't substantively different
> than allowing them to make it permissive in their init script (which
> should not be running in the same domain as the application itself -
> init scripts generally require different sets of permissions).
> 
> I see permissive mode (system-wide or per-domain) as purely as
> development tool.  Certain users may choose to employ it in production
> systems as you say, but those users aren't going to be the ones worried
> about analyzable or certifiable policy, eh?

I suppose part of the question is what constitutes a property or
requirement of the policy itself.  compat_net is a property of the
policy - does the policy rely on legacy network controls or secmark to
meet its requirements?  allow_unknown is a property of the policy - does
the policy rely on complete control of all kernel operations in order to
meet its requirements (actually, it doesn't even fully meet that, as an
completely unchecked kernel operation won't show up - we are only
determining whether all controlled operations are subjected to policy or
not)?

Permissive mode in contrast has been independent of policy, and it has
always been implicit that using it invalidates the assumptions of the
policy.

If per-domain permissive mode is equivalent to an unconfined domain from
an analysis point of view, then I suppose you might argue that it is a
property of the policy, just as making a domain unconfined is a property
of the policy.  That might have merit.

-- 
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: concept of a permissive domain

[Karl MacMillan]

On Thu, 2007-09-13 at 10:23 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 09:59 -0400, Eric Paris wrote:
> > On Thu, 2007-09-13 at 09:25 -0400, Stephen Smalley wrote:

[...]

> > Wow, I can't believe I just heard that after being railed on for
> > considering using selinuxfs for things like handle_unknown (something
> > which specifically doesn't have large atomicity issues like compat_net)
> > Wasn't your main argument post analysis tools?  I can't imagine anything
> > worse than this to see how the system was set up.  Now when you do
> > analysis you need to look at 'setenforce' 'compat_net' 'the booleans'
> > and 'every single friggin type on the whole system.'  Your list of
> > things to look at in selinuxfs just got a bit larger....
> > 
> > I guess I'm in favor of doing it in policy...
> 
> Permissive mode (system-wide or per-domain) means that there is no
> meaningful analysis possible.

Minor detail!

>   It is purely a development tool for
> helping to discover an application's behavior as input into creating a
> policy.
> 

Well - a development tool that will be deployed on production systems.

> In your scenario, the same person supplying the application and its
> policy is likely also supplying its init script.

The world is not that simple - often people writing selinux policy in
large organizations are not the same people packaging / maintaining the
software. Not only that, selinux is _always_ an easier sell if it is
entirely self-contained.

So I'm fine if we do this via semanage and a config file that sets
permissive domains via selinuxfs on boot, but there is no way we can
sell changing init scripts by hand. Honestly, policy just seems so much
easier.

>   Thus, allowing them to
> make their domain permissive in policy isn't substantively different
> than allowing them to make it permissive in their init script (which
> should not be running in the same domain as the application itself -
> init scripts generally require different sets of permissions).
> 

See above - that is not the case.

> I see permissive mode (system-wide or per-domain) as purely as
> development tool.

You are, obviously, free to view it however you want. That doesn't
change the fact that the impetus for this feature is customers that
requested it for production systems. We should design the feature with
that use in mind.

>   Certain users may choose to employ it in production
> systems as you say, but those users aren't going to be the ones worried
> about analyzable or certifiable policy, eh?
> 

You're probably right as things are today, but why force them into
different camps?

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: concept of a permissive domain

[Karl MacMillan]

On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > [...]
> > > One other feature/requirement would be to not override dontaudit rules.
> > > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > > reading /etc/shadow.  The app should still be denied reading
> > > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > > apps to take the code paths they will take in enforcing mode.)
> > 
> > This isn't specific to per-domain permissive, right? It would be useful
> > in general for permissive.
> 
> I would be opposed to such a change, as it is a semantic change to what
> dontaudit means.
> 
> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> independent of one another today and none of them imply the other, e.g.
> 	allow a b:file read;
> 	auditallow a b:file *;
> 	dontaudit a b:file *;
> is perfectly valid and means:
> - Let a read files labeled b,
> - Audit all permission grantings from a to files labeled b,
> - Don't audit any permission denials from a to files labeled b.
> 

I agree that changing the dontaudit semantic has problems - however the
reason Dan suggested is still valid. Currently, generating policy in
permissive mode can lead to bogus or overly permissive policy. It would
be nice to have some solution to that problem.

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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> > On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > > On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > > [...]
> > > > One other feature/requirement would be to not override dontaudit rules.
> > > > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > > > reading /etc/shadow.  The app should still be denied reading
> > > > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > > > apps to take the code paths they will take in enforcing mode.)
> > > 
> > > This isn't specific to per-domain permissive, right? It would be useful
> > > in general for permissive.
> > 
> > I would be opposed to such a change, as it is a semantic change to what
> > dontaudit means.
> > 
> > Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> > independent of one another today and none of them imply the other, e.g.
> > 	allow a b:file read;
> > 	auditallow a b:file *;
> > 	dontaudit a b:file *;
> > is perfectly valid and means:
> > - Let a read files labeled b,
> > - Audit all permission grantings from a to files labeled b,
> > - Don't audit any permission denials from a to files labeled b.
> > 
> 
> I agree that changing the dontaudit semantic has problems - however the
> reason Dan suggested is still valid. Currently, generating policy in
> permissive mode can lead to bogus or overly permissive policy. It would
> be nice to have some solution to that problem.

Can't you handle that in the tool, by giving matching interfaces with
dontaudit rules precedence over ones with allow rules and asking the
user?

I'd actually rather see an improved capability for (more easily)
generating policy incrementally in enforcing mode.  That would make it
more suitable for production use and avoid the problem above.

-- 
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: concept of a permissive domain

[Karl MacMillan]

On Thu, 2007-09-13 at 10:57 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> > On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> > > On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > > > On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > > > [...]
> > > > > One other feature/requirement would be to not override dontaudit rules.
> > > > > So if I have a domain in permissive mode and I have a dontaudit rule  on
> > > > > reading /etc/shadow.  The app should still be denied reading
> > > > > /etc/shadow.  (This is not a show stopper, but would allow us to force
> > > > > apps to take the code paths they will take in enforcing mode.)
> > > > 
> > > > This isn't specific to per-domain permissive, right? It would be useful
> > > > in general for permissive.
> > > 
> > > I would be opposed to such a change, as it is a semantic change to what
> > > dontaudit means.
> > > 
> > > Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> > > independent of one another today and none of them imply the other, e.g.
> > > 	allow a b:file read;
> > > 	auditallow a b:file *;
> > > 	dontaudit a b:file *;
> > > is perfectly valid and means:
> > > - Let a read files labeled b,
> > > - Audit all permission grantings from a to files labeled b,
> > > - Don't audit any permission denials from a to files labeled b.
> > > 
> > 
> > I agree that changing the dontaudit semantic has problems - however the
> > reason Dan suggested is still valid. Currently, generating policy in
> > permissive mode can lead to bogus or overly permissive policy. It would
> > be nice to have some solution to that problem.
> 
> Can't you handle that in the tool, by giving matching interfaces with
> dontaudit rules precedence over ones with allow rules and asking the
> user?
> 

Somewhat - that's been something I've been wanting to implement for a
while. The real problem, though, is applications that follow different
code paths depending on whether an operation was allowed.

> I'd actually rather see an improved capability for (more easily)
> generating policy incrementally in enforcing mode.  That would make it
> more suitable for production use and avoid the problem above.
> 

The large sepolgen patch I'm working on now will allow you to
incrementally update policy, including intelligent updates of interface
calls. So if you have an application with a good test suite this might
be possible.

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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>> [...]
>>>>> One other feature/requirement would be to not override dontaudit rules.
>>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>>> apps to take the code paths they will take in enforcing mode.)
>>>> This isn't specific to per-domain permissive, right? It would be useful
>>>> in general for permissive.
>>> I would be opposed to such a change, as it is a semantic change to what
>>> dontaudit means.
>>>
>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>> independent of one another today and none of them imply the other, e.g.
>>> 	allow a b:file read;
>>> 	auditallow a b:file *;
>>> 	dontaudit a b:file *;
>>> is perfectly valid and means:
>>> - Let a read files labeled b,
>>> - Audit all permission grantings from a to files labeled b,
>>> - Don't audit any permission denials from a to files labeled b.
>>>
>> I agree that changing the dontaudit semantic has problems - however the
>> reason Dan suggested is still valid. Currently, generating policy in
>> permissive mode can lead to bogus or overly permissive policy. It would
>> be nice to have some solution to that problem.
> 
> Can't you handle that in the tool, by giving matching interfaces with
> dontaudit rules precedence over ones with allow rules and asking the
> user?
> 
> I'd actually rather see an improved capability for (more easily)
> generating policy incrementally in enforcing mode.  That would make it
> more suitable for production use and avoid the problem above.
> 
Said large financial institution rols out policy for managing huge money
transactions in permissive mode.   Policy build with a pam for verifying
users.

Users selected app_uses_pam in policy design tool.

Tool adds

dontaudit financeapp_t shadow_t:file r_file_perms;

App in permissive mode reads shadow perms.  Dontaudit covers it up.

App runs for three months.  policy writer sees no avc messages for a
long time,  Thinks everything is fine.

Turns on enforcing mode, app tries to authenticate on mysql, gets
denials apps blow up, millions lost, people say selinux sucks, policy
writer is fired.

If I want the current behavior to see full permissive mode, I can
semodule -DB or build my policy without dontaudit.

permissive mode not following code path of dontaudit would causes major
problems.


fired.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG6Y6TrlYvE4MpobMRAgbeAJ9xunutSHL4xFXLEW8NznOnt0FjDgCdFo8s
py7sQ0X7vnGeGSp9GIHr+7E=
=io/Y
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> >> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> >>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> >>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> >>>> [...]
> >>>>> One other feature/requirement would be to not override dontaudit rules.
> >>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
> >>>>> reading /etc/shadow.  The app should still be denied reading
> >>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
> >>>>> apps to take the code paths they will take in enforcing mode.)
> >>>> This isn't specific to per-domain permissive, right? It would be useful
> >>>> in general for permissive.
> >>> I would be opposed to such a change, as it is a semantic change to what
> >>> dontaudit means.
> >>>
> >>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> >>> independent of one another today and none of them imply the other, e.g.
> >>> 	allow a b:file read;
> >>> 	auditallow a b:file *;
> >>> 	dontaudit a b:file *;
> >>> is perfectly valid and means:
> >>> - Let a read files labeled b,
> >>> - Audit all permission grantings from a to files labeled b,
> >>> - Don't audit any permission denials from a to files labeled b.
> >>>
> >> I agree that changing the dontaudit semantic has problems - however the
> >> reason Dan suggested is still valid. Currently, generating policy in
> >> permissive mode can lead to bogus or overly permissive policy. It would
> >> be nice to have some solution to that problem.
> > 
> > Can't you handle that in the tool, by giving matching interfaces with
> > dontaudit rules precedence over ones with allow rules and asking the
> > user?
> > 
> > I'd actually rather see an improved capability for (more easily)
> > generating policy incrementally in enforcing mode.  That would make it
> > more suitable for production use and avoid the problem above.
> > 
> Said large financial institution rols out policy for managing huge money
> transactions in permissive mode.   Policy build with a pam for verifying
> users.

Note that I said it would be better to provide a capability to let
people develop policy incrementally while in enforcing mode, not
permissive mode.

> Users selected app_uses_pam in policy design tool.
> 
> Tool adds
> 
> dontaudit financeapp_t shadow_t:file r_file_perms;
> 
> App in permissive mode reads shadow perms.  Dontaudit covers it up.

So don't do that.  Don't include new dontaudit rules while generating
policy in permissive mode, and let the user decide whether to select the
dontaudit branch or the allow branch in the final form of the generated
policy.  For that matter, we should really minimize use of dontaudit
rules whenever possible - if we can fix the code to _default_ to the
less privileged code path and only try the more privileged code path if
it truly needs it, then we should do that.

> App runs for three months.  policy writer sees no avc messages for a
> long time,  Thinks everything is fine.
> 
> Turns on enforcing mode, app tries to authenticate on mysql, gets
> denials apps blow up, millions lost, people say selinux sucks, policy
> writer is fired.
> 
> If I want the current behavior to see full permissive mode, I can
> semodule -DB or build my policy without dontaudit.
> 
> permissive mode not following code path of dontaudit would causes major
> problems.

Let me say it again - dontaudit rules don't affect whether or not
something is allowed in SELinux today; they are NOT deny rules.  If you
want deny rules, add those (gasp).  Permissive mode is simply following
the code path of allowing everything, as requested.

> fired.

You can't fire me that easily.

-- 
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: concept of a permissive domain

[Eric Paris]

On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stephen Smalley wrote:
> > > On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> > >> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> > >>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > >>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > >>>> [...]
> > >>>>> One other feature/requirement would be to not override dontaudit rules.
> > >>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
> > >>>>> reading /etc/shadow.  The app should still be denied reading
> > >>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
> > >>>>> apps to take the code paths they will take in enforcing mode.)
> > >>>> This isn't specific to per-domain permissive, right? It would be useful
> > >>>> in general for permissive.
> > >>> I would be opposed to such a change, as it is a semantic change to what
> > >>> dontaudit means.
> > >>>
> > >>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> > >>> independent of one another today and none of them imply the other, e.g.
> > >>> 	allow a b:file read;
> > >>> 	auditallow a b:file *;
> > >>> 	dontaudit a b:file *;
> > >>> is perfectly valid and means:
> > >>> - Let a read files labeled b,
> > >>> - Audit all permission grantings from a to files labeled b,
> > >>> - Don't audit any permission denials from a to files labeled b.
> > >>>
> > >> I agree that changing the dontaudit semantic has problems - however the
> > >> reason Dan suggested is still valid. Currently, generating policy in
> > >> permissive mode can lead to bogus or overly permissive policy. It would
> > >> be nice to have some solution to that problem.
> > > 
> > > Can't you handle that in the tool, by giving matching interfaces with
> > > dontaudit rules precedence over ones with allow rules and asking the
> > > user?
> > > 
> > > I'd actually rather see an improved capability for (more easily)
> > > generating policy incrementally in enforcing mode.  That would make it
> > > more suitable for production use and avoid the problem above.
> > > 
> > Said large financial institution rols out policy for managing huge money
> > transactions in permissive mode.   Policy build with a pam for verifying
> > users.
> 
> Note that I said it would be better to provide a capability to let
> people develop policy incrementally while in enforcing mode, not
> permissive mode.

A fine goal, but not really feasible ATM.  It also doesn't allow for
going live and testing in production at the same time.  This is still a
'must have perfect coverage before usage' model.  Just because you
develop you way means we don't have to worry about the permissive-denial
issue but it doesn't solve the 'you are fired' issue.  Great in theory,
but when talking about some ginormous app that noone fully understands I
wouldn't want to be the one who sticks his neck out.

> 
> > Users selected app_uses_pam in policy design tool.
> > 
> > Tool adds
> > 
> > dontaudit financeapp_t shadow_t:file r_file_perms;
> > 
> > App in permissive mode reads shadow perms.  Dontaudit covers it up.
> 
> So don't do that.  Don't include new dontaudit rules while generating
> policy in permissive mode, and let the user decide whether to select the
> dontaudit branch or the allow branch in the final form of the generated
> policy.  For that matter, we should really minimize use of dontaudit
> rules whenever possible - if we can fix the code to _default_ to the
> less privileged code path and only try the more privileged code path if
> it truly needs it, then we should do that.

You rule out the possibility of running in production without enforcing.
Obviously your customers would never do that, but a customer going from
no MAC to some non-enforcing MAC to enforcing MAC, would like to
actually test things along the way.  Its a different customer base.  And
we don't have to harm one to help the other.

Fixing the code is always the better way to go than dontaudit,
thankfully they exist because that isn't always possible.  Good thing we
were thinking about this issue before.

> > App runs for three months.  policy writer sees no avc messages for a
> > long time,  Thinks everything is fine.
> > 
> > Turns on enforcing mode, app tries to authenticate on mysql, gets
> > denials apps blow up, millions lost, people say selinux sucks, policy
> > writer is fired.
> > 
> > If I want the current behavior to see full permissive mode, I can
> > semodule -DB or build my policy without dontaudit.
> > 
> > permissive mode not following code path of dontaudit would causes major
> > problems.
> 
> Let me say it again - dontaudit rules don't affect whether or not
> something is allowed in SELinux today; 

correct

> they are NOT deny rules.  If you
> want deny rules, add those (gasp).  Permissive mode is simply following
> the code path of allowing everything, as requested.

it's not following ANY code path now.  enforcing=0 is following the path
you describe.

Start looking at this as a whole new type of domain, not just some
extension of enforcing=X (although I do plan to tie them into each other
at some level in the code since they provide similar features).

We need denial rules, we just don't have to call them that.  We just
need to define how dontaudit and auditallow rules work in this new type
of domain.  Then decide if that somehow interferes if the domain is not
a permissive domain.  Aside from Karl's little flub, noone is arguing we
should change anything having to do with enforcing=0 or enforcing=1 and
a non-permissive-domain.  We don't need to rewrite how dontaudit rules
affect enforcing domains or non-enforcing-systems, we just need an
extended definition for permissive domains.  Seems dontaudit and
auditallow can work very nicely to solve real practical problems
constraining large applications in environments which may not be friends
to problems introduced by SELinux.  Everyone agrees running an
application and just allowing whatever it asks for isn't the best way to
write policy, but when it's all you have, and all you are going to
reasonably have I'm not hearing a argument why we can't do what Dan
wants, other than 'that's not what it means today.'

dontaudit as an 'implicit denial in permissive domains' isn't what we
have today, but then again, we don't have permissive domains today.

-Eric


--
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: concept of a permissive domain

[Karl MacMillan]

On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:

[...]

> > > 
> > Said large financial institution rols out policy for managing huge money
> > transactions in permissive mode.   Policy build with a pam for verifying
> > users.
> 
> Note that I said it would be better to provide a capability to let
> people develop policy incrementally while in enforcing mode, not
> permissive mode.
> 

That may be a good idea, but it doesn't solve this problem. These
customers are concerned that they can't fully exercise their
applications in a testing environment and are, therefore, hesitant to
deploy these policies in enforcing mode. This, to me, is a reasonable
concern given the importance of these applications.

They would therefore prefer to deploy in permissive mode for some period
of time and see if any other denials pop out. Again - this seems
reasonable.

The only concern here is that permissive is not exactly the same as
enforcing. This problem can't be fixed entirely, but we can at least
chip away at some known problems.

> > Users selected app_uses_pam in policy design tool.
> > 
> > Tool adds
> > 
> > dontaudit financeapp_t shadow_t:file r_file_perms;
> > 
> > App in permissive mode reads shadow perms.  Dontaudit covers it up.
> 
> So don't do that.  Don't include new dontaudit rules while generating
> policy in permissive mode, and let the user decide whether to select the
> dontaudit branch or the allow branch in the final form of the generated
> policy.

That's not a bad idea.

>   For that matter, we should really minimize use of dontaudit
> rules whenever possible - if we can fix the code to _default_ to the
> less privileged code path and only try the more privileged code path if
> it truly needs it, then we should do that.
> 

Also a good idea.

> > App runs for three months.  policy writer sees no avc messages for a
> > long time,  Thinks everything is fine.
> > 
> > Turns on enforcing mode, app tries to authenticate on mysql, gets
> > denials apps blow up, millions lost, people say selinux sucks, policy
> > writer is fired.
> > 
> > If I want the current behavior to see full permissive mode, I can
> > semodule -DB or build my policy without dontaudit.
> > 
> > permissive mode not following code path of dontaudit would causes major
> > problems.
> 
> Let me say it again - dontaudit rules don't affect whether or not
> something is allowed in SELinux today; they are NOT deny rules. 

Agreed.

>  If you
> want deny rules, add those (gasp).

Well - maybe we should explore that concept despite the problems it
raises.

>   Permissive mode is simply following
> the code path of allowing everything, as requested.
> 

Yeah - which is the problem.

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: concept of a permissive domain

[James Carter]

On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stephen Smalley wrote:
> > > On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> > >> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> > >>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > >>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > >>>> [...]
> > >>>>> One other feature/requirement would be to not override dontaudit rules.
> > >>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
> > >>>>> reading /etc/shadow.  The app should still be denied reading
> > >>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
> > >>>>> apps to take the code paths they will take in enforcing mode.)
> > >>>> This isn't specific to per-domain permissive, right? It would be useful
> > >>>> in general for permissive.
> > >>> I would be opposed to such a change, as it is a semantic change to what
> > >>> dontaudit means.
> > >>>
> > >>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> > >>> independent of one another today and none of them imply the other, e.g.
> > >>> 	allow a b:file read;
> > >>> 	auditallow a b:file *;
> > >>> 	dontaudit a b:file *;
> > >>> is perfectly valid and means:
> > >>> - Let a read files labeled b,
> > >>> - Audit all permission grantings from a to files labeled b,
> > >>> - Don't audit any permission denials from a to files labeled b.
> > >>>
> > >> I agree that changing the dontaudit semantic has problems - however the
> > >> reason Dan suggested is still valid. Currently, generating policy in
> > >> permissive mode can lead to bogus or overly permissive policy. It would
> > >> be nice to have some solution to that problem.
> > > 
> > > Can't you handle that in the tool, by giving matching interfaces with
> > > dontaudit rules precedence over ones with allow rules and asking the
> > > user?
> > > 
> > > I'd actually rather see an improved capability for (more easily)
> > > generating policy incrementally in enforcing mode.  That would make it
> > > more suitable for production use and avoid the problem above.
> > > 
> > Said large financial institution rols out policy for managing huge money
> > transactions in permissive mode.   Policy build with a pam for verifying
> > users.
> 
> Note that I said it would be better to provide a capability to let
> people develop policy incrementally while in enforcing mode, not
> permissive mode.
> 
> > Users selected app_uses_pam in policy design tool.
> > 
> > Tool adds
> > 
> > dontaudit financeapp_t shadow_t:file r_file_perms;
> > 
> > App in permissive mode reads shadow perms.  Dontaudit covers it up.
> 
> So don't do that.  Don't include new dontaudit rules while generating
> policy in permissive mode, and let the user decide whether to select the
> dontaudit branch or the allow branch in the final form of the generated
> policy.  For that matter, we should really minimize use of dontaudit
> rules whenever possible - if we can fix the code to _default_ to the
> less privileged code path and only try the more privileged code path if
> it truly needs it, then we should do that.
> 
> > App runs for three months.  policy writer sees no avc messages for a
> > long time,  Thinks everything is fine.
> > 
> > Turns on enforcing mode, app tries to authenticate on mysql, gets
> > denials apps blow up, millions lost, people say selinux sucks, policy
> > writer is fired.
> > 
> > If I want the current behavior to see full permissive mode, I can
> > semodule -DB or build my policy without dontaudit.
> > 
> > permissive mode not following code path of dontaudit would causes major
> > problems.
> 
> Let me say it again - dontaudit rules don't affect whether or not
> something is allowed in SELinux today; they are NOT deny rules.  If you
> want deny rules, add those (gasp).  Permissive mode is simply following
> the code path of allowing everything, as requested.
> 

If this was called a debug domain instead of a permissive domain, would
it be acceptable to change the behavior of dontaudit and other things as
needed to assist in debugging?  

If there were debug domains, however, it is not hard to imagine that
soon people would be declaring how much easier it is to just run an
application as a debug domain and add dontaudit rules to deny what the
application isn't suppose to do.  

The problem that does need to be addressed is how to prevent certain
code paths from being followed in permissive/debug mode.  Maybe deny
rules are the best answer.


-- 
James Carter <jwcart2@epoch.ncsc.mil>
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: concept of a permissive domain

[Joshua Brindle]

James Carter wrote:
> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
>   
>> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Stephen Smalley wrote:
>>>       
>>>> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>>>>         
>>>>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>>>>           
>>>>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>>>>             
>>>>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>>>>> [...]
>>>>>>>               
>>>>>>>> One other feature/requirement would be to not override dontaudit rules.
>>>>>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
>>>>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>>>>>> apps to take the code paths they will take in enforcing mode.)
>>>>>>>>                 
>>>>>>> This isn't specific to per-domain permissive, right? It would be useful
>>>>>>> in general for permissive.
>>>>>>>               
>>>>>> I would be opposed to such a change, as it is a semantic change to what
>>>>>> dontaudit means.
>>>>>>
>>>>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>>>>> independent of one another today and none of them imply the other, e.g.
>>>>>> 	allow a b:file read;
>>>>>> 	auditallow a b:file *;
>>>>>> 	dontaudit a b:file *;
>>>>>> is perfectly valid and means:
>>>>>> - Let a read files labeled b,
>>>>>> - Audit all permission grantings from a to files labeled b,
>>>>>> - Don't audit any permission denials from a to files labeled b.
>>>>>>
>>>>>>             
>>>>> I agree that changing the dontaudit semantic has problems - however the
>>>>> reason Dan suggested is still valid. Currently, generating policy in
>>>>> permissive mode can lead to bogus or overly permissive policy. It would
>>>>> be nice to have some solution to that problem.
>>>>>           
>>>> Can't you handle that in the tool, by giving matching interfaces with
>>>> dontaudit rules precedence over ones with allow rules and asking the
>>>> user?
>>>>
>>>> I'd actually rather see an improved capability for (more easily)
>>>> generating policy incrementally in enforcing mode.  That would make it
>>>> more suitable for production use and avoid the problem above.
>>>>
>>>>         
>>> Said large financial institution rols out policy for managing huge money
>>> transactions in permissive mode.   Policy build with a pam for verifying
>>> users.
>>>       
>> Note that I said it would be better to provide a capability to let
>> people develop policy incrementally while in enforcing mode, not
>> permissive mode.
>>
>>     
>>> Users selected app_uses_pam in policy design tool.
>>>
>>> Tool adds
>>>
>>> dontaudit financeapp_t shadow_t:file r_file_perms;
>>>
>>> App in permissive mode reads shadow perms.  Dontaudit covers it up.
>>>       
>> So don't do that.  Don't include new dontaudit rules while generating
>> policy in permissive mode, and let the user decide whether to select the
>> dontaudit branch or the allow branch in the final form of the generated
>> policy.  For that matter, we should really minimize use of dontaudit
>> rules whenever possible - if we can fix the code to _default_ to the
>> less privileged code path and only try the more privileged code path if
>> it truly needs it, then we should do that.
>>
>>     
>>> App runs for three months.  policy writer sees no avc messages for a
>>> long time,  Thinks everything is fine.
>>>
>>> Turns on enforcing mode, app tries to authenticate on mysql, gets
>>> denials apps blow up, millions lost, people say selinux sucks, policy
>>> writer is fired.
>>>
>>> If I want the current behavior to see full permissive mode, I can
>>> semodule -DB or build my policy without dontaudit.
>>>
>>> permissive mode not following code path of dontaudit would causes major
>>> problems.
>>>       
>> Let me say it again - dontaudit rules don't affect whether or not
>> something is allowed in SELinux today; they are NOT deny rules.  If you
>> want deny rules, add those (gasp).  Permissive mode is simply following
>> the code path of allowing everything, as requested.
>>
>>     
>
> If this was called a debug domain instead of a permissive domain, would
> it be acceptable to change the behavior of dontaudit and other things as
> needed to assist in debugging?  
>
> If there were debug domains, however, it is not hard to imagine that
> soon people would be declaring how much easier it is to just run an
> application as a debug domain and add dontaudit rules to deny what the
> application isn't suppose to do.  
>
> The problem that does need to be addressed is how to prevent certain
> code paths from being followed in permissive/debug mode.  Maybe deny
> rules are the best answer.
>   

Since we moved to a avtab datum that is only 1 vector and are now 
packing different avtab entry types into the key we could easily make a 
new kind of entry, I suggest we call it "reallydontaudit"

Seriously though, FWIW I like Steves idea of setting permissive on a 
domain via selinuxfs (in fact I had a similar idea on my own before he 
posted it here). It wouldn't be appropriate to put permissive in the 
policy and load it so why would it be to do so at a higher granularity? 
Also this would let you easily put something into permissive 
temporarilly without reloading the policy over and over. Nothing 
prevents us from adding functionality to semanage and putting an init 
script in place for boot time permissive (though doing so does have some 
atomicity issues, just like compat_net and friends :\)


--
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: concept of a permissive domain

[Karl MacMillan]

On Fri, 2007-09-14 at 10:45 -0400, Joshua Brindle wrote:
> James Carter wrote:
> > On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:

[...]

> >
> > If this was called a debug domain instead of a permissive domain, would
> > it be acceptable to change the behavior of dontaudit and other things as
> > needed to assist in debugging?  
> >
> > If there were debug domains, however, it is not hard to imagine that
> > soon people would be declaring how much easier it is to just run an
> > application as a debug domain and add dontaudit rules to deny what the
> > application isn't suppose to do.  
> >
> > The problem that does need to be addressed is how to prevent certain
> > code paths from being followed in permissive/debug mode.  Maybe deny
> > rules are the best answer.
> >   
> 
> Since we moved to a avtab datum that is only 1 vector and are now 
> packing different avtab entry types into the key we could easily make a 
> new kind of entry, I suggest we call it "reallydontaudit"
> 
> Seriously though, FWIW I like Steves idea of setting permissive on a 
> domain via selinuxfs (in fact I had a similar idea on my own before he 
> posted it here). It wouldn't be appropriate to put permissive in the 
> policy and load it so why would it be to do so at a higher granularity? 

Why wouldn't it be appropriate to put permissive in the policy?

> Also this would let you easily put something into permissive 
> temporarilly without reloading the policy over and over. Nothing 
> prevents us from adding functionality to semanage and putting an init 
> script in place for boot time permissive (though doing so does have some 
> atomicity issues, just like compat_net and friends :\)
> 

Why cause all of these problems and require building all of this extra
functionality when you can just put this in the policy? I really don't
get why we want to put some data in the policy and communicate some
through other means.

Even booleans at this point - there is almost no reason to set those via
selinuxfs. I'd rather just focus on making loading policy more efficient
and communicate all of that state that way.

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: concept of a permissive domain

[Stephen Smalley]

On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
> > On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Stephen Smalley wrote:
> > > > On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
> > > >> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
> > > >>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
> > > >>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
> > > >>>> [...]
> > > >>>>> One other feature/requirement would be to not override dontaudit rules.
> > > >>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
> > > >>>>> reading /etc/shadow.  The app should still be denied reading
> > > >>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
> > > >>>>> apps to take the code paths they will take in enforcing mode.)
> > > >>>> This isn't specific to per-domain permissive, right? It would be useful
> > > >>>> in general for permissive.
> > > >>> I would be opposed to such a change, as it is a semantic change to what
> > > >>> dontaudit means.
> > > >>>
> > > >>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
> > > >>> independent of one another today and none of them imply the other, e.g.
> > > >>> 	allow a b:file read;
> > > >>> 	auditallow a b:file *;
> > > >>> 	dontaudit a b:file *;
> > > >>> is perfectly valid and means:
> > > >>> - Let a read files labeled b,
> > > >>> - Audit all permission grantings from a to files labeled b,
> > > >>> - Don't audit any permission denials from a to files labeled b.
> > > >>>
> > > >> I agree that changing the dontaudit semantic has problems - however the
> > > >> reason Dan suggested is still valid. Currently, generating policy in
> > > >> permissive mode can lead to bogus or overly permissive policy. It would
> > > >> be nice to have some solution to that problem.
> > > > 
> > > > Can't you handle that in the tool, by giving matching interfaces with
> > > > dontaudit rules precedence over ones with allow rules and asking the
> > > > user?
> > > > 
> > > > I'd actually rather see an improved capability for (more easily)
> > > > generating policy incrementally in enforcing mode.  That would make it
> > > > more suitable for production use and avoid the problem above.
> > > > 
> > > Said large financial institution rols out policy for managing huge money
> > > transactions in permissive mode.   Policy build with a pam for verifying
> > > users.
> > 
> > Note that I said it would be better to provide a capability to let
> > people develop policy incrementally while in enforcing mode, not
> > permissive mode.
> 
> A fine goal, but not really feasible ATM.  It also doesn't allow for
> going live and testing in production at the same time.  This is still a
> 'must have perfect coverage before usage' model.  Just because you
> develop you way means we don't have to worry about the permissive-denial
> issue but it doesn't solve the 'you are fired' issue.  Great in theory,
> but when talking about some ginormous app that noone fully understands I
> wouldn't want to be the one who sticks his neck out.
> 
> > 
> > > Users selected app_uses_pam in policy design tool.
> > > 
> > > Tool adds
> > > 
> > > dontaudit financeapp_t shadow_t:file r_file_perms;
> > > 
> > > App in permissive mode reads shadow perms.  Dontaudit covers it up.
> > 
> > So don't do that.  Don't include new dontaudit rules while generating
> > policy in permissive mode, and let the user decide whether to select the
> > dontaudit branch or the allow branch in the final form of the generated
> > policy.  For that matter, we should really minimize use of dontaudit
> > rules whenever possible - if we can fix the code to _default_ to the
> > less privileged code path and only try the more privileged code path if
> > it truly needs it, then we should do that.
> 
> You rule out the possibility of running in production without enforcing.
> Obviously your customers would never do that, but a customer going from
> no MAC to some non-enforcing MAC to enforcing MAC, would like to
> actually test things along the way.  Its a different customer base.  And
> we don't have to harm one to help the other.
> 
> Fixing the code is always the better way to go than dontaudit,
> thankfully they exist because that isn't always possible.  Good thing we
> were thinking about this issue before.
> 
> > > App runs for three months.  policy writer sees no avc messages for a
> > > long time,  Thinks everything is fine.
> > > 
> > > Turns on enforcing mode, app tries to authenticate on mysql, gets
> > > denials apps blow up, millions lost, people say selinux sucks, policy
> > > writer is fired.
> > > 
> > > If I want the current behavior to see full permissive mode, I can
> > > semodule -DB or build my policy without dontaudit.
> > > 
> > > permissive mode not following code path of dontaudit would causes major
> > > problems.
> > 
> > Let me say it again - dontaudit rules don't affect whether or not
> > something is allowed in SELinux today; 
> 
> correct
> 
> > they are NOT deny rules.  If you
> > want deny rules, add those (gasp).  Permissive mode is simply following
> > the code path of allowing everything, as requested.
> 
> it's not following ANY code path now.  enforcing=0 is following the path
> you describe.
> 
> Start looking at this as a whole new type of domain, not just some
> extension of enforcing=X (although I do plan to tie them into each other
> at some level in the code since they provide similar features).
> 
> We need denial rules, we just don't have to call them that.  We just
> need to define how dontaudit and auditallow rules work in this new type
> of domain.  Then decide if that somehow interferes if the domain is not
> a permissive domain.  Aside from Karl's little flub, noone is arguing we
> should change anything having to do with enforcing=0 or enforcing=1 and
> a non-permissive-domain.  We don't need to rewrite how dontaudit rules
> affect enforcing domains or non-enforcing-systems, we just need an
> extended definition for permissive domains.  Seems dontaudit and
> auditallow can work very nicely to solve real practical problems
> constraining large applications in environments which may not be friends
> to problems introduced by SELinux.  Everyone agrees running an
> application and just allowing whatever it asks for isn't the best way to
> write policy, but when it's all you have, and all you are going to
> reasonably have I'm not hearing a argument why we can't do what Dan
> wants, other than 'that's not what it means today.'
> 
> dontaudit as an 'implicit denial in permissive domains' isn't what we
> have today, but then again, we don't have permissive domains today.

I think we need to be careful that we aren't making SELinux harder to
understand.  You are introducing a new construct that doesn't correspond
precisely with either "unconfined" domains under enforcing mode or all
domains under permissive mode today, and then you'll have to explain to
users how they each differ and how to use them in a coherent way.  Maybe
it would be useful to talk again about why we can't go with the "make
the domain unconfined in policy and use auditallow" approach.  There is
the log-once aspect of permissive mode, but possibly that could be made
selectable for domains, and there is the difference in the log messages
(granted vs. denied), but the tools can certainly deal with that.

Also, one other thing to keep in mind for the permissive domain concept
is that permission checks don't always fall neatly into the domain-type
form and that domains tend to flow to related objects (sockets, packets,
proc inodes, etc), so it is possibly insufficient and/or unsafe to
determine whether to apply permissive mode on the source context in all
cases.  Requires some investigation of all of the checks today.

-- 
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: concept of a permissive domain

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
>   
>> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
>>     
>>> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
>>>       
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Stephen Smalley wrote:
>>>>         
>>>>> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>>>>>           
>>>>>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>>>>>             
>>>>>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>>>>>               
>>>>>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>>>>>> [...]
>>>>>>>>                 
>>>>>>>>> One other feature/requirement would be to not override dontaudit rules.
>>>>>>>>> So if I have a domain in permissive mode and I have a dontaudit rule  on
>>>>>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>>>>>>> apps to take the code paths they will take in enforcing mode.)
>>>>>>>>>                   
>>>>>>>> This isn't specific to per-domain permissive, right? It would be useful
>>>>>>>> in general for permissive.
>>>>>>>>                 
>>>>>>> I would be opposed to such a change, as it is a semantic change to what
>>>>>>> dontaudit means.
>>>>>>>
>>>>>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>>>>>> independent of one another today and none of them imply the other, e.g.
>>>>>>> 	allow a b:file read;
>>>>>>> 	auditallow a b:file *;
>>>>>>> 	dontaudit a b:file *;
>>>>>>> is perfectly valid and means:
>>>>>>> - Let a read files labeled b,
>>>>>>> - Audit all permission grantings from a to files labeled b,
>>>>>>> - Don't audit any permission denials from a to files labeled b.
>>>>>>>
>>>>>>>               
>>>>>> I agree that changing the dontaudit semantic has problems - however the
>>>>>> reason Dan suggested is still valid. Currently, generating policy in
>>>>>> permissive mode can lead to bogus or overly permissive policy. It would
>>>>>> be nice to have some solution to that problem.
>>>>>>             
>>>>> Can't you handle that in the tool, by giving matching interfaces with
>>>>> dontaudit rules precedence over ones with allow rules and asking the
>>>>> user?
>>>>>
>>>>> I'd actually rather see an improved capability for (more easily)
>>>>> generating policy incrementally in enforcing mode.  That would make it
>>>>> more suitable for production use and avoid the problem above.
>>>>>
>>>>>           
>>>> Said large financial institution rols out policy for managing huge money
>>>> transactions in permissive mode.   Policy build with a pam for verifying
>>>> users.
>>>>         
>>> Note that I said it would be better to provide a capability to let
>>> people develop policy incrementally while in enforcing mode, not
>>> permissive mode.
>>>       
>> A fine goal, but not really feasible ATM.  It also doesn't allow for
>> going live and testing in production at the same time.  This is still a
>> 'must have perfect coverage before usage' model.  Just because you
>> develop you way means we don't have to worry about the permissive-denial
>> issue but it doesn't solve the 'you are fired' issue.  Great in theory,
>> but when talking about some ginormous app that noone fully understands I
>> wouldn't want to be the one who sticks his neck out.
>>
>>     
>>>> Users selected app_uses_pam in policy design tool.
>>>>
>>>> Tool adds
>>>>
>>>> dontaudit financeapp_t shadow_t:file r_file_perms;
>>>>
>>>> App in permissive mode reads shadow perms.  Dontaudit covers it up.
>>>>         
>>> So don't do that.  Don't include new dontaudit rules while generating
>>> policy in permissive mode, and let the user decide whether to select the
>>> dontaudit branch or the allow branch in the final form of the generated
>>> policy.  For that matter, we should really minimize use of dontaudit
>>> rules whenever possible - if we can fix the code to _default_ to the
>>> less privileged code path and only try the more privileged code path if
>>> it truly needs it, then we should do that.
>>>       
>> You rule out the possibility of running in production without enforcing.
>> Obviously your customers would never do that, but a customer going from
>> no MAC to some non-enforcing MAC to enforcing MAC, would like to
>> actually test things along the way.  Its a different customer base.  And
>> we don't have to harm one to help the other.
>>
>> Fixing the code is always the better way to go than dontaudit,
>> thankfully they exist because that isn't always possible.  Good thing we
>> were thinking about this issue before.
>>
>>     
>>>> App runs for three months.  policy writer sees no avc messages for a
>>>> long time,  Thinks everything is fine.
>>>>
>>>> Turns on enforcing mode, app tries to authenticate on mysql, gets
>>>> denials apps blow up, millions lost, people say selinux sucks, policy
>>>> writer is fired.
>>>>
>>>> If I want the current behavior to see full permissive mode, I can
>>>> semodule -DB or build my policy without dontaudit.
>>>>
>>>> permissive mode not following code path of dontaudit would causes major
>>>> problems.
>>>>         
>>> Let me say it again - dontaudit rules don't affect whether or not
>>> something is allowed in SELinux today; 
>>>       
>> correct
>>
>>     
>>> they are NOT deny rules.  If you
>>> want deny rules, add those (gasp).  Permissive mode is simply following
>>> the code path of allowing everything, as requested.
>>>       
>> it's not following ANY code path now.  enforcing=0 is following the path
>> you describe.
>>
>> Start looking at this as a whole new type of domain, not just some
>> extension of enforcing=X (although I do plan to tie them into each other
>> at some level in the code since they provide similar features).
>>
>> We need denial rules, we just don't have to call them that.  We just
>> need to define how dontaudit and auditallow rules work in this new type
>> of domain.  Then decide if that somehow interferes if the domain is not
>> a permissive domain.  Aside from Karl's little flub, noone is arguing we
>> should change anything having to do with enforcing=0 or enforcing=1 and
>> a non-permissive-domain.  We don't need to rewrite how dontaudit rules
>> affect enforcing domains or non-enforcing-systems, we just need an
>> extended definition for permissive domains.  Seems dontaudit and
>> auditallow can work very nicely to solve real practical problems
>> constraining large applications in environments which may not be friends
>> to problems introduced by SELinux.  Everyone agrees running an
>> application and just allowing whatever it asks for isn't the best way to
>> write policy, but when it's all you have, and all you are going to
>> reasonably have I'm not hearing a argument why we can't do what Dan
>> wants, other than 'that's not what it means today.'
>>
>> dontaudit as an 'implicit denial in permissive domains' isn't what we
>> have today, but then again, we don't have permissive domains today.
>>     
>
> I think we need to be careful that we aren't making SELinux harder to
> understand.  You are introducing a new construct that doesn't correspond
> precisely with either "unconfined" domains under enforcing mode or all
> domains under permissive mode today, and then you'll have to explain to
> users how they each differ and how to use them in a coherent way.  Maybe
> it would be useful to talk again about why we can't go with the "make
> the domain unconfined in policy and use auditallow" approach.  There is
> the log-once aspect of permissive mode, but possibly that could be made
> selectable for domains, and there is the difference in the log messages
> (granted vs. denied), but the tools can certainly deal with that.
>
>   

Also, since the avtab now has the rule type in the key we can make a new 
key that only logs once, call it "auditallowbutonlyonetimeplz". Or, we 
could just ignore this problem altogether and rely on the new read/write 
revalidation code to prevent log floods from happening (though that 
doesn't help in the find / case).

> Also, one other thing to keep in mind for the permissive domain concept
> is that permission checks don't always fall neatly into the domain-type
> form and that domains tend to flow to related objects (sockets, packets,
> proc inodes, etc), so it is possibly insufficient and/or unsafe to
> determine whether to apply permissive mode on the source context in all
> cases.  Requires some investigation of all of the checks today

There are also the checks that always happen like setrlimit, noatsecure 
and so on that need to be dealt with properly. Whether dealing with a 
permissive domain or an allow *, auditallow domain there will be an 
issue. We certainly don't want to accidently grant noatsecure to some 
random domain.


--
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: concept of a permissive domain

[Chad Sellers]

On 9/18/07 4:24 PM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:

> On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
>> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
>>> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> 
>>>> Stephen Smalley wrote:
>>>>> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>>>>>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>>>>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>>>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>>>>>> [...]
>>>>>>>>> One other feature/requirement would be to not override dontaudit
>>>>>>>>> rules.
>>>>>>>>> So if I have a domain in permissive mode and I have a dontaudit rule
>>>>>>>>> on
>>>>>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>>>>>>> apps to take the code paths they will take in enforcing mode.)
>>>>>>>> This isn't specific to per-domain permissive, right? It would be useful
>>>>>>>> in general for permissive.
>>>>>>> I would be opposed to such a change, as it is a semantic change to what
>>>>>>> dontaudit means.
>>>>>>> 
>>>>>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>>>>>> independent of one another today and none of them imply the other, e.g.
>>>>>>> allow a b:file read;
>>>>>>> auditallow a b:file *;
>>>>>>> dontaudit a b:file *;
>>>>>>> is perfectly valid and means:
>>>>>>> - Let a read files labeled b,
>>>>>>> - Audit all permission grantings from a to files labeled b,
>>>>>>> - Don't audit any permission denials from a to files labeled b.
>>>>>>> 
>>>>>> I agree that changing the dontaudit semantic has problems - however the
>>>>>> reason Dan suggested is still valid. Currently, generating policy in
>>>>>> permissive mode can lead to bogus or overly permissive policy. It would
>>>>>> be nice to have some solution to that problem.
>>>>> 
>>>>> Can't you handle that in the tool, by giving matching interfaces with
>>>>> dontaudit rules precedence over ones with allow rules and asking the
>>>>> user?
>>>>> 
>>>>> I'd actually rather see an improved capability for (more easily)
>>>>> generating policy incrementally in enforcing mode.  That would make it
>>>>> more suitable for production use and avoid the problem above.
>>>>> 
>>>> Said large financial institution rols out policy for managing huge money
>>>> transactions in permissive mode.   Policy build with a pam for verifying
>>>> users.
>>> 
>>> Note that I said it would be better to provide a capability to let
>>> people develop policy incrementally while in enforcing mode, not
>>> permissive mode.
>> 
>> A fine goal, but not really feasible ATM.  It also doesn't allow for
>> going live and testing in production at the same time.  This is still a
>> 'must have perfect coverage before usage' model.  Just because you
>> develop you way means we don't have to worry about the permissive-denial
>> issue but it doesn't solve the 'you are fired' issue.  Great in theory,
>> but when talking about some ginormous app that noone fully understands I
>> wouldn't want to be the one who sticks his neck out.
>> 
>>> 
>>>> Users selected app_uses_pam in policy design tool.
>>>> 
>>>> Tool adds
>>>> 
>>>> dontaudit financeapp_t shadow_t:file r_file_perms;
>>>> 
>>>> App in permissive mode reads shadow perms.  Dontaudit covers it up.
>>> 
>>> So don't do that.  Don't include new dontaudit rules while generating
>>> policy in permissive mode, and let the user decide whether to select the
>>> dontaudit branch or the allow branch in the final form of the generated
>>> policy.  For that matter, we should really minimize use of dontaudit
>>> rules whenever possible - if we can fix the code to _default_ to the
>>> less privileged code path and only try the more privileged code path if
>>> it truly needs it, then we should do that.
>> 
>> You rule out the possibility of running in production without enforcing.
>> Obviously your customers would never do that, but a customer going from
>> no MAC to some non-enforcing MAC to enforcing MAC, would like to
>> actually test things along the way.  Its a different customer base.  And
>> we don't have to harm one to help the other.
>> 
>> Fixing the code is always the better way to go than dontaudit,
>> thankfully they exist because that isn't always possible.  Good thing we
>> were thinking about this issue before.
>> 
>>>> App runs for three months.  policy writer sees no avc messages for a
>>>> long time,  Thinks everything is fine.
>>>> 
>>>> Turns on enforcing mode, app tries to authenticate on mysql, gets
>>>> denials apps blow up, millions lost, people say selinux sucks, policy
>>>> writer is fired.
>>>> 
>>>> If I want the current behavior to see full permissive mode, I can
>>>> semodule -DB or build my policy without dontaudit.
>>>> 
>>>> permissive mode not following code path of dontaudit would causes major
>>>> problems.
>>> 
>>> Let me say it again - dontaudit rules don't affect whether or not
>>> something is allowed in SELinux today;
>> 
>> correct
>> 
>>> they are NOT deny rules.  If you
>>> want deny rules, add those (gasp).  Permissive mode is simply following
>>> the code path of allowing everything, as requested.
>> 
>> it's not following ANY code path now.  enforcing=0 is following the path
>> you describe.
>> 
>> Start looking at this as a whole new type of domain, not just some
>> extension of enforcing=X (although I do plan to tie them into each other
>> at some level in the code since they provide similar features).
>> 
>> We need denial rules, we just don't have to call them that.  We just
>> need to define how dontaudit and auditallow rules work in this new type
>> of domain.  Then decide if that somehow interferes if the domain is not
>> a permissive domain.  Aside from Karl's little flub, noone is arguing we
>> should change anything having to do with enforcing=0 or enforcing=1 and
>> a non-permissive-domain.  We don't need to rewrite how dontaudit rules
>> affect enforcing domains or non-enforcing-systems, we just need an
>> extended definition for permissive domains.  Seems dontaudit and
>> auditallow can work very nicely to solve real practical problems
>> constraining large applications in environments which may not be friends
>> to problems introduced by SELinux.  Everyone agrees running an
>> application and just allowing whatever it asks for isn't the best way to
>> write policy, but when it's all you have, and all you are going to
>> reasonably have I'm not hearing a argument why we can't do what Dan
>> wants, other than 'that's not what it means today.'
>> 
>> dontaudit as an 'implicit denial in permissive domains' isn't what we
>> have today, but then again, we don't have permissive domains today.
> 
> I think we need to be careful that we aren't making SELinux harder to
> understand.  You are introducing a new construct that doesn't correspond
> precisely with either "unconfined" domains under enforcing mode or all
> domains under permissive mode today, and then you'll have to explain to
> users how they each differ and how to use them in a coherent way.  Maybe
> it would be useful to talk again about why we can't go with the "make
> the domain unconfined in policy and use auditallow" approach.  There is
> the log-once aspect of permissive mode, but possibly that could be made
> selectable for domains, and there is the difference in the log messages
> (granted vs. denied), but the tools can certainly deal with that.
> 
I have to say I agree - this is getting complicated. I'm having visions of
trying to explain all the different "unconfined" scenarios to customer
developers and it makes me want to cry. I understand the reason for
permissive domains (in fact I think there are more use cases than have been
mentioned here), but creating another "the rules don't apply" construct that
has different behavior from any of the current constructs adds too much
complexity.

One other note - how does a special debug domain that allows everything
except things that are dontaudit'd solve the use case that's been thrown
around. If I'm the IT guy, and I'm using this permissive domain to try out a
policy for 3 months in a permissive environment, I certainly don't want
certain items to be denied. Even worse, the current idea would have them
denied and not even audit'd. So, instead of causing a problem 3 months from
now when I switch to enforcing, it causes problems the day I install policy.
Millions are still lost, people still say SELinux sucks, and I (the policy
writer) still get fired (with 3 months less pay as well).

Chad


--
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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chad Sellers wrote:
> On 9/18/07 4:24 PM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> 
>> On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
>>> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
>>>> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Stephen Smalley wrote:
>>>>>> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>>>>>>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>>>>>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>>>>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>>>>>>> [...]
>>>>>>>>>> One other feature/requirement would be to not override dontaudit
>>>>>>>>>> rules.
>>>>>>>>>> So if I have a domain in permissive mode and I have a dontaudit rule
>>>>>>>>>> on
>>>>>>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>>>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to force
>>>>>>>>>> apps to take the code paths they will take in enforcing mode.)
>>>>>>>>> This isn't specific to per-domain permissive, right? It would be useful
>>>>>>>>> in general for permissive.
>>>>>>>> I would be opposed to such a change, as it is a semantic change to what
>>>>>>>> dontaudit means.
>>>>>>>>
>>>>>>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>>>>>>> independent of one another today and none of them imply the other, e.g.
>>>>>>>> allow a b:file read;
>>>>>>>> auditallow a b:file *;
>>>>>>>> dontaudit a b:file *;
>>>>>>>> is perfectly valid and means:
>>>>>>>> - Let a read files labeled b,
>>>>>>>> - Audit all permission grantings from a to files labeled b,
>>>>>>>> - Don't audit any permission denials from a to files labeled b.
>>>>>>>>
>>>>>>> I agree that changing the dontaudit semantic has problems - however the
>>>>>>> reason Dan suggested is still valid. Currently, generating policy in
>>>>>>> permissive mode can lead to bogus or overly permissive policy. It would
>>>>>>> be nice to have some solution to that problem.
>>>>>> Can't you handle that in the tool, by giving matching interfaces with
>>>>>> dontaudit rules precedence over ones with allow rules and asking the
>>>>>> user?
>>>>>>
>>>>>> I'd actually rather see an improved capability for (more easily)
>>>>>> generating policy incrementally in enforcing mode.  That would make it
>>>>>> more suitable for production use and avoid the problem above.
>>>>>>
>>>>> Said large financial institution rols out policy for managing huge money
>>>>> transactions in permissive mode.   Policy build with a pam for verifying
>>>>> users.
>>>> Note that I said it would be better to provide a capability to let
>>>> people develop policy incrementally while in enforcing mode, not
>>>> permissive mode.
>>> A fine goal, but not really feasible ATM.  It also doesn't allow for
>>> going live and testing in production at the same time.  This is still a
>>> 'must have perfect coverage before usage' model.  Just because you
>>> develop you way means we don't have to worry about the permissive-denial
>>> issue but it doesn't solve the 'you are fired' issue.  Great in theory,
>>> but when talking about some ginormous app that noone fully understands I
>>> wouldn't want to be the one who sticks his neck out.
>>>
>>>>> Users selected app_uses_pam in policy design tool.
>>>>>
>>>>> Tool adds
>>>>>
>>>>> dontaudit financeapp_t shadow_t:file r_file_perms;
>>>>>
>>>>> App in permissive mode reads shadow perms.  Dontaudit covers it up.
>>>> So don't do that.  Don't include new dontaudit rules while generating
>>>> policy in permissive mode, and let the user decide whether to select the
>>>> dontaudit branch or the allow branch in the final form of the generated
>>>> policy.  For that matter, we should really minimize use of dontaudit
>>>> rules whenever possible - if we can fix the code to _default_ to the
>>>> less privileged code path and only try the more privileged code path if
>>>> it truly needs it, then we should do that.
>>> You rule out the possibility of running in production without enforcing.
>>> Obviously your customers would never do that, but a customer going from
>>> no MAC to some non-enforcing MAC to enforcing MAC, would like to
>>> actually test things along the way.  Its a different customer base.  And
>>> we don't have to harm one to help the other.
>>>
>>> Fixing the code is always the better way to go than dontaudit,
>>> thankfully they exist because that isn't always possible.  Good thing we
>>> were thinking about this issue before.
>>>
>>>>> App runs for three months.  policy writer sees no avc messages for a
>>>>> long time,  Thinks everything is fine.
>>>>>
>>>>> Turns on enforcing mode, app tries to authenticate on mysql, gets
>>>>> denials apps blow up, millions lost, people say selinux sucks, policy
>>>>> writer is fired.
>>>>>
>>>>> If I want the current behavior to see full permissive mode, I can
>>>>> semodule -DB or build my policy without dontaudit.
>>>>>
>>>>> permissive mode not following code path of dontaudit would causes major
>>>>> problems.
>>>> Let me say it again - dontaudit rules don't affect whether or not
>>>> something is allowed in SELinux today;
>>> correct
>>>
>>>> they are NOT deny rules.  If you
>>>> want deny rules, add those (gasp).  Permissive mode is simply following
>>>> the code path of allowing everything, as requested.
>>> it's not following ANY code path now.  enforcing=0 is following the path
>>> you describe.
>>>
>>> Start looking at this as a whole new type of domain, not just some
>>> extension of enforcing=X (although I do plan to tie them into each other
>>> at some level in the code since they provide similar features).
>>>
>>> We need denial rules, we just don't have to call them that.  We just
>>> need to define how dontaudit and auditallow rules work in this new type
>>> of domain.  Then decide if that somehow interferes if the domain is not
>>> a permissive domain.  Aside from Karl's little flub, noone is arguing we
>>> should change anything having to do with enforcing=0 or enforcing=1 and
>>> a non-permissive-domain.  We don't need to rewrite how dontaudit rules
>>> affect enforcing domains or non-enforcing-systems, we just need an
>>> extended definition for permissive domains.  Seems dontaudit and
>>> auditallow can work very nicely to solve real practical problems
>>> constraining large applications in environments which may not be friends
>>> to problems introduced by SELinux.  Everyone agrees running an
>>> application and just allowing whatever it asks for isn't the best way to
>>> write policy, but when it's all you have, and all you are going to
>>> reasonably have I'm not hearing a argument why we can't do what Dan
>>> wants, other than 'that's not what it means today.'
>>>
>>> dontaudit as an 'implicit denial in permissive domains' isn't what we
>>> have today, but then again, we don't have permissive domains today.
>> I think we need to be careful that we aren't making SELinux harder to
>> understand.  You are introducing a new construct that doesn't correspond
>> precisely with either "unconfined" domains under enforcing mode or all
>> domains under permissive mode today, and then you'll have to explain to
>> users how they each differ and how to use them in a coherent way.  Maybe
>> it would be useful to talk again about why we can't go with the "make
>> the domain unconfined in policy and use auditallow" approach.  There is
>> the log-once aspect of permissive mode, but possibly that could be made
>> selectable for domains, and there is the difference in the log messages
>> (granted vs. denied), but the tools can certainly deal with that.
>>
> I have to say I agree - this is getting complicated. I'm having visions of
> trying to explain all the different "unconfined" scenarios to customer
> developers and it makes me want to cry. I understand the reason for
> permissive domains (in fact I think there are more use cases than have been
> mentioned here), but creating another "the rules don't apply" construct that
> has different behavior from any of the current constructs adds too much
> complexity.
> 
> One other note - how does a special debug domain that allows everything
> except things that are dontaudit'd solve the use case that's been thrown
> around. If I'm the IT guy, and I'm using this permissive domain to try out a
> policy for 3 months in a permissive environment, I certainly don't want
> certain items to be denied. Even worse, the current idea would have them
> denied and not even audit'd. So, instead of causing a problem 3 months from
> now when I switch to enforcing, it causes problems the day I install policy.
> Millions are still lost, people still say SELinux sucks, and I (the policy
> writer) still get fired (with 3 months less pay as well).
> 
> Chad
> 
I would argue just the opposite.  Lets use the pam case.  Currently pam
tries to read /etc/shadow and fails over to using unix_chkpwd.
(Something we are working to change, BTW).  So in the permissive domain
you suggest, we run for three months with myapp_t able to read
/etc/shadow, even with the standard dontaudit rule.  Everything works
fine, no AVC messages. Lets turn off the "permissive" bit.  Suddenly the
myapp can't read /etc/shadow. It goes down a totally different code path
and boom blows up.  By running it in this permissive mode, you are never
testing code paths that happen when myapp gets Perimission Denied.

But I think we need to move forward with some kind of
permissive/unconfined domain.  Whether this is a kernel change or tool
chain change, I don't care.  I just want it soon.  We talked about it
back at the Summit and no movement has happened.

As far as being fully permissive or allowing dontaudit rules to block,
lets go fully permissive for now.  Meaning, when you turn a domain to
permissive it works the same way permissive mode works now.
We can revisit the dontaudit/enforce at a later date.  The tools
(audit2allow/sepolgen) can easily be changed to generate rules for
looking at granted versus denied.  GRANTED would also stop
setroubleshoot from screaming constantly.

We need a way to build a policy module:

auditallow = unconfined_domain - (allow_rules + dontaudit_rules)

or set a flag in the kernel that says allow XYZ_T to run in permissive mode.

The ability to put a domain in permissive mode needs to be put in the
toolchain, so a user can set it also.

semodule/semanage --permissive myapp_t


User Scenarios:

1. Policy developer - discussed to death.
2. User wants app to work, knows it does stuff that SELinux would block
but does not want to deal with it, so sets it permissive.
3. Diagnosing whether SELinux is causing the problem.  Often we tell
users when they don't see AVC messages, to put the machine in permissive
mode to see if SELinux is the culprit.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG8RxsrlYvE4MpobMRAkOQAJ9it8yEBxJOfWzb1oJtahqq6/ns5QCfZYdw
SDoZwkRhxTg6QgORE0Aerdw=
=sPj8
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Chad Sellers]

On 9/19/07 8:56 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chad Sellers wrote:
>> On 9/18/07 4:24 PM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>> 
>>> On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
>>>> On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
>>>>> On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>> 
>>>>>> Stephen Smalley wrote:
>>>>>>> On Thu, 2007-09-13 at 10:46 -0400, Karl MacMillan wrote:
>>>>>>>> On Thu, 2007-09-13 at 10:08 -0400, Stephen Smalley wrote:
>>>>>>>>> On Tue, 2007-09-11 at 17:26 -0400, Karl MacMillan wrote:
>>>>>>>>>> On Tue, 2007-09-11 at 16:31 -0400, Daniel J Walsh wrote:
>>>>>>>>>> [...]
>>>>>>>>>>> One other feature/requirement would be to not override dontaudit
>>>>>>>>>>> rules.
>>>>>>>>>>> So if I have a domain in permissive mode and I have a dontaudit rule
>>>>>>>>>>> on
>>>>>>>>>>> reading /etc/shadow.  The app should still be denied reading
>>>>>>>>>>> /etc/shadow.  (This is not a show stopper, but would allow us to
>>>>>>>>>>> force
>>>>>>>>>>> apps to take the code paths they will take in enforcing mode.)
>>>>>>>>>> This isn't specific to per-domain permissive, right? It would be
>>>>>>>>>> useful
>>>>>>>>>> in general for permissive.
>>>>>>>>> I would be opposed to such a change, as it is a semantic change to
>>>>>>>>> what
>>>>>>>>> dontaudit means.
>>>>>>>>> 
>>>>>>>>> Keep in mind that allow, auditallow, and dontaudit/auditdeny are all
>>>>>>>>> independent of one another today and none of them imply the other,
>>>>>>>>> e.g.
>>>>>>>>> allow a b:file read;
>>>>>>>>> auditallow a b:file *;
>>>>>>>>> dontaudit a b:file *;
>>>>>>>>> is perfectly valid and means:
>>>>>>>>> - Let a read files labeled b,
>>>>>>>>> - Audit all permission grantings from a to files labeled b,
>>>>>>>>> - Don't audit any permission denials from a to files labeled b.
>>>>>>>>> 
>>>>>>>> I agree that changing the dontaudit semantic has problems - however the
>>>>>>>> reason Dan suggested is still valid. Currently, generating policy in
>>>>>>>> permissive mode can lead to bogus or overly permissive policy. It would
>>>>>>>> be nice to have some solution to that problem.
>>>>>>> Can't you handle that in the tool, by giving matching interfaces with
>>>>>>> dontaudit rules precedence over ones with allow rules and asking the
>>>>>>> user?
>>>>>>> 
>>>>>>> I'd actually rather see an improved capability for (more easily)
>>>>>>> generating policy incrementally in enforcing mode.  That would make it
>>>>>>> more suitable for production use and avoid the problem above.
>>>>>>> 
>>>>>> Said large financial institution rols out policy for managing huge money
>>>>>> transactions in permissive mode.   Policy build with a pam for verifying
>>>>>> users.
>>>>> Note that I said it would be better to provide a capability to let
>>>>> people develop policy incrementally while in enforcing mode, not
>>>>> permissive mode.
>>>> A fine goal, but not really feasible ATM.  It also doesn't allow for
>>>> going live and testing in production at the same time.  This is still a
>>>> 'must have perfect coverage before usage' model.  Just because you
>>>> develop you way means we don't have to worry about the permissive-denial
>>>> issue but it doesn't solve the 'you are fired' issue.  Great in theory,
>>>> but when talking about some ginormous app that noone fully understands I
>>>> wouldn't want to be the one who sticks his neck out.
>>>> 
>>>>>> Users selected app_uses_pam in policy design tool.
>>>>>> 
>>>>>> Tool adds
>>>>>> 
>>>>>> dontaudit financeapp_t shadow_t:file r_file_perms;
>>>>>> 
>>>>>> App in permissive mode reads shadow perms.  Dontaudit covers it up.
>>>>> So don't do that.  Don't include new dontaudit rules while generating
>>>>> policy in permissive mode, and let the user decide whether to select the
>>>>> dontaudit branch or the allow branch in the final form of the generated
>>>>> policy.  For that matter, we should really minimize use of dontaudit
>>>>> rules whenever possible - if we can fix the code to _default_ to the
>>>>> less privileged code path and only try the more privileged code path if
>>>>> it truly needs it, then we should do that.
>>>> You rule out the possibility of running in production without enforcing.
>>>> Obviously your customers would never do that, but a customer going from
>>>> no MAC to some non-enforcing MAC to enforcing MAC, would like to
>>>> actually test things along the way.  Its a different customer base.  And
>>>> we don't have to harm one to help the other.
>>>> 
>>>> Fixing the code is always the better way to go than dontaudit,
>>>> thankfully they exist because that isn't always possible.  Good thing we
>>>> were thinking about this issue before.
>>>> 
>>>>>> App runs for three months.  policy writer sees no avc messages for a
>>>>>> long time,  Thinks everything is fine.
>>>>>> 
>>>>>> Turns on enforcing mode, app tries to authenticate on mysql, gets
>>>>>> denials apps blow up, millions lost, people say selinux sucks, policy
>>>>>> writer is fired.
>>>>>> 
>>>>>> If I want the current behavior to see full permissive mode, I can
>>>>>> semodule -DB or build my policy without dontaudit.
>>>>>> 
>>>>>> permissive mode not following code path of dontaudit would causes major
>>>>>> problems.
>>>>> Let me say it again - dontaudit rules don't affect whether or not
>>>>> something is allowed in SELinux today;
>>>> correct
>>>> 
>>>>> they are NOT deny rules.  If you
>>>>> want deny rules, add those (gasp).  Permissive mode is simply following
>>>>> the code path of allowing everything, as requested.
>>>> it's not following ANY code path now.  enforcing=0 is following the path
>>>> you describe.
>>>> 
>>>> Start looking at this as a whole new type of domain, not just some
>>>> extension of enforcing=X (although I do plan to tie them into each other
>>>> at some level in the code since they provide similar features).
>>>> 
>>>> We need denial rules, we just don't have to call them that.  We just
>>>> need to define how dontaudit and auditallow rules work in this new type
>>>> of domain.  Then decide if that somehow interferes if the domain is not
>>>> a permissive domain.  Aside from Karl's little flub, noone is arguing we
>>>> should change anything having to do with enforcing=0 or enforcing=1 and
>>>> a non-permissive-domain.  We don't need to rewrite how dontaudit rules
>>>> affect enforcing domains or non-enforcing-systems, we just need an
>>>> extended definition for permissive domains.  Seems dontaudit and
>>>> auditallow can work very nicely to solve real practical problems
>>>> constraining large applications in environments which may not be friends
>>>> to problems introduced by SELinux.  Everyone agrees running an
>>>> application and just allowing whatever it asks for isn't the best way to
>>>> write policy, but when it's all you have, and all you are going to
>>>> reasonably have I'm not hearing a argument why we can't do what Dan
>>>> wants, other than 'that's not what it means today.'
>>>> 
>>>> dontaudit as an 'implicit denial in permissive domains' isn't what we
>>>> have today, but then again, we don't have permissive domains today.
>>> I think we need to be careful that we aren't making SELinux harder to
>>> understand.  You are introducing a new construct that doesn't correspond
>>> precisely with either "unconfined" domains under enforcing mode or all
>>> domains under permissive mode today, and then you'll have to explain to
>>> users how they each differ and how to use them in a coherent way.  Maybe
>>> it would be useful to talk again about why we can't go with the "make
>>> the domain unconfined in policy and use auditallow" approach.  There is
>>> the log-once aspect of permissive mode, but possibly that could be made
>>> selectable for domains, and there is the difference in the log messages
>>> (granted vs. denied), but the tools can certainly deal with that.
>>> 
>> I have to say I agree - this is getting complicated. I'm having visions of
>> trying to explain all the different "unconfined" scenarios to customer
>> developers and it makes me want to cry. I understand the reason for
>> permissive domains (in fact I think there are more use cases than have been
>> mentioned here), but creating another "the rules don't apply" construct that
>> has different behavior from any of the current constructs adds too much
>> complexity.
>> 
>> One other note - how does a special debug domain that allows everything
>> except things that are dontaudit'd solve the use case that's been thrown
>> around. If I'm the IT guy, and I'm using this permissive domain to try out a
>> policy for 3 months in a permissive environment, I certainly don't want
>> certain items to be denied. Even worse, the current idea would have them
>> denied and not even audit'd. So, instead of causing a problem 3 months from
>> now when I switch to enforcing, it causes problems the day I install policy.
>> Millions are still lost, people still say SELinux sucks, and I (the policy
>> writer) still get fired (with 3 months less pay as well).
>> 
>> Chad
>> 
> I would argue just the opposite.  Lets use the pam case.  Currently pam
> tries to read /etc/shadow and fails over to using unix_chkpwd.
> (Something we are working to change, BTW).  So in the permissive domain
> you suggest, we run for three months with myapp_t able to read
> /etc/shadow, even with the standard dontaudit rule.  Everything works
> fine, no AVC messages. Lets turn off the "permissive" bit.  Suddenly the
> myapp can't read /etc/shadow. It goes down a totally different code path
> and boom blows up.  By running it in this permissive mode, you are never
> testing code paths that happen when myapp gets Perimission Denied.
> 
I understand the problem and agree that it is indeed a problem. I was just
trying to point out that having a domain that is mostly permissive, but
denies things that are dontaudit'd exchanges one problem for another. We're
creating a concept for the IT guy to be able to test out his policy without
breaking the app (permissive), then adding a feature to it that gives the
policy the opportunity to break the app (by denying some things).

> But I think we need to move forward with some kind of
> permissive/unconfined domain.  Whether this is a kernel change or tool
> chain change, I don't care.  I just want it soon.  We talked about it
> back at the Summit and no movement has happened.
> 
Sounds good to me.

> As far as being fully permissive or allowing dontaudit rules to block,
> lets go fully permissive for now.  Meaning, when you turn a domain to
> permissive it works the same way permissive mode works now.
> We can revisit the dontaudit/enforce at a later date.

Sounds good.

> The tools
> (audit2allow/sepolgen) can easily be changed to generate rules for
> looking at granted versus denied.  GRANTED would also stop
> setroubleshoot from screaming constantly.
> 
> We need a way to build a policy module:
> 
> auditallow = unconfined_domain - (allow_rules + dontaudit_rules)
> 
> or set a flag in the kernel that says allow XYZ_T to run in permissive mode.
> 
> The ability to put a domain in permissive mode needs to be put in the
> toolchain, so a user can set it also.
> 
> semodule/semanage --permissive myapp_t
> 
> 
> User Scenarios:
> 
> 1. Policy developer - discussed to death.
> 2. User wants app to work, knows it does stuff that SELinux would block
> but does not want to deal with it, so sets it permissive.
> 3. Diagnosing whether SELinux is causing the problem.  Often we tell
> users when they don't see AVC messages, to put the machine in permissive
> mode to see if SELinux is the culprit.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFG8RxsrlYvE4MpobMRAkOQAJ9it8yEBxJOfWzb1oJtahqq6/ns5QCfZYdw
> SDoZwkRhxTg6QgORE0Aerdw=
> =sPj8
> -----END PGP SIGNATURE-----


--
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: concept of a permissive domain

[Martin Orr]

On 18/09/07 22:54, Chad Sellers wrote:
> One other note - how does a special debug domain that allows everything
> except things that are dontaudit'd solve the use case that's been thrown
> around. If I'm the IT guy, and I'm using this permissive domain to try out a
> policy for 3 months in a permissive environment, I certainly don't want
> certain items to be denied. Even worse, the current idea would have them
> denied and not even audit'd. So, instead of causing a problem 3 months from
> now when I switch to enforcing, it causes problems the day I install policy.
> Millions are still lost, people still say SELinux sucks, and I (the policy
> writer) still get fired (with 3 months less pay as well).

To pick out one particular point here, tracking down problems caused by
denials which have dontaudit rules is difficult, because by definition they
are not logged.  (I have what I guess is such a problem now: iff enforcing
is on, the mails cron sends me are empty.)  Would it not be useful to have a
way of disabling dontaudit rules, perhaps on a global or perhaps on a
per-domain basis?  Just as dontaudit rules are orthogonal to allow rules,
this setting would be orthogonal to permissive/enforcing.

Please forgive me if this is already possible and I have missed it.

-- 
Martin Orr

--
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: concept of a permissive domain

[Eric Paris]

On Wed, 2007-09-19 at 17:35 +0100, Martin Orr wrote:
> On 18/09/07 22:54, Chad Sellers wrote:
> > One other note - how does a special debug domain that allows everything
> > except things that are dontaudit'd solve the use case that's been thrown
> > around. If I'm the IT guy, and I'm using this permissive domain to try out a
> > policy for 3 months in a permissive environment, I certainly don't want
> > certain items to be denied. Even worse, the current idea would have them
> > denied and not even audit'd. So, instead of causing a problem 3 months from
> > now when I switch to enforcing, it causes problems the day I install policy.
> > Millions are still lost, people still say SELinux sucks, and I (the policy
> > writer) still get fired (with 3 months less pay as well).
> 
> To pick out one particular point here, tracking down problems caused by
> denials which have dontaudit rules is difficult, because by definition they
> are not logged.  (I have what I guess is such a problem now: iff enforcing
> is on, the mails cron sends me are empty.)  Would it not be useful to have a
> way of disabling dontaudit rules, perhaps on a global or perhaps on a
> per-domain basis?  Just as dontaudit rules are orthogonal to allow rules,
> this setting would be orthogonal to permissive/enforcing.
> 
> Please forgive me if this is already possible and I have missed it.

http://readlist.com/lists/tycho.nsa.gov/selinux/1/7187.html

nope, you didn't miss it, but it should be coming from the userspace
people sometime.....


--
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: concept of a permissive domain

[Stephen Smalley]

On Wed, 2007-09-19 at 17:35 +0100, Martin Orr wrote:
> On 18/09/07 22:54, Chad Sellers wrote:
> > One other note - how does a special debug domain that allows everything
> > except things that are dontaudit'd solve the use case that's been thrown
> > around. If I'm the IT guy, and I'm using this permissive domain to try out a
> > policy for 3 months in a permissive environment, I certainly don't want
> > certain items to be denied. Even worse, the current idea would have them
> > denied and not even audit'd. So, instead of causing a problem 3 months from
> > now when I switch to enforcing, it causes problems the day I install policy.
> > Millions are still lost, people still say SELinux sucks, and I (the policy
> > writer) still get fired (with 3 months less pay as well).
> 
> To pick out one particular point here, tracking down problems caused by
> denials which have dontaudit rules is difficult, because by definition they
> are not logged.  (I have what I guess is such a problem now: iff enforcing
> is on, the mails cron sends me are empty.)  Would it not be useful to have a
> way of disabling dontaudit rules, perhaps on a global or perhaps on a
> per-domain basis?  Just as dontaudit rules are orthogonal to allow rules,
> this setting would be orthogonal to permissive/enforcing.
> 
> Please forgive me if this is already possible and I have missed it.

Already possible on a global basis.

Original approach (pre-modular policy, e.g. RHEL 4, Fedora < 5):
	cd /etc/selinux/$SELINUXTYPE/src/policy
	make enableaudit load # rebuild and load policy without dontaudits
	<collect audit messages>
	make clean load # rebuild and load policy with dontaudits

Current modular policy approach (e.g. RHEL 5, Fedora > 5):
	semodule -b /usr/share/selinux/$SELINUXTYPE/enableaudit.pp # replace base module with one that has no dontaudits
	<collect audit messages>
	semodule -b /usr/share/selinux/$SELINUXTYPE/base.pp # restore original base module
	(limited to base module, doesn't help with non-base modules)

In current trunk (policycoreutils >= 2.0.23, libsemanage >= 2.0.4,
libsepol >= 2.0.6):
	semodule -DB # re-generate policy with dontaudit's stripped
	<collect audit messages>
	semodule -B # re-generate policy normally
	(deals with all policy modules)

-- 
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: concept of a permissive domain

[Joshua Brindle]

Eric Paris wrote:
> On Wed, 2007-09-19 at 17:35 +0100, Martin Orr wrote:
>> On 18/09/07 22:54, Chad Sellers wrote:
>>> One other note - how does a special debug domain that allows everything
>>> except things that are dontaudit'd solve the use case that's been thrown
>>> around. If I'm the IT guy, and I'm using this permissive domain to try out a
>>> policy for 3 months in a permissive environment, I certainly don't want
>>> certain items to be denied. Even worse, the current idea would have them
>>> denied and not even audit'd. So, instead of causing a problem 3 months from
>>> now when I switch to enforcing, it causes problems the day I install policy.
>>> Millions are still lost, people still say SELinux sucks, and I (the policy
>>> writer) still get fired (with 3 months less pay as well).
>> To pick out one particular point here, tracking down problems caused by
>> denials which have dontaudit rules is difficult, because by definition they
>> are not logged.  (I have what I guess is such a problem now: iff enforcing
>> is on, the mails cron sends me are empty.)  Would it not be useful to have a
>> way of disabling dontaudit rules, perhaps on a global or perhaps on a
>> per-domain basis?  Just as dontaudit rules are orthogonal to allow rules,
>> this setting would be orthogonal to permissive/enforcing.
>>
>> Please forgive me if this is already possible and I have missed it.
> 
> http://readlist.com/lists/tycho.nsa.gov/selinux/1/7187.html
> 
> nope, you didn't miss it, but it should be coming from the userspace
> people sometime.....
> 

Its been in svn since 2007-08-16, versions:
libsemanage 2.0.4
policycoreutils 2.0.23
libsepol 2.0.6



--
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: concept of a permissive domain

[Joshua Brindle]

Joshua Brindle wrote:
> Eric Paris wrote:
>> On Wed, 2007-09-19 at 17:35 +0100, Martin Orr wrote:
>>> On 18/09/07 22:54, Chad Sellers wrote:
>>>> One other note - how does a special debug domain that allows everything
>>>> except things that are dontaudit'd solve the use case that's been 
>>>> thrown
>>>> around. If I'm the IT guy, and I'm using this permissive domain to 
>>>> try out a
>>>> policy for 3 months in a permissive environment, I certainly don't want
>>>> certain items to be denied. Even worse, the current idea would have 
>>>> them
>>>> denied and not even audit'd. So, instead of causing a problem 3 
>>>> months from
>>>> now when I switch to enforcing, it causes problems the day I install 
>>>> policy.
>>>> Millions are still lost, people still say SELinux sucks, and I (the 
>>>> policy
>>>> writer) still get fired (with 3 months less pay as well).
>>> To pick out one particular point here, tracking down problems caused by
>>> denials which have dontaudit rules is difficult, because by 
>>> definition they
>>> are not logged.  (I have what I guess is such a problem now: iff 
>>> enforcing
>>> is on, the mails cron sends me are empty.)  Would it not be useful to 
>>> have a
>>> way of disabling dontaudit rules, perhaps on a global or perhaps on a
>>> per-domain basis?  Just as dontaudit rules are orthogonal to allow 
>>> rules,
>>> this setting would be orthogonal to permissive/enforcing.
>>>
>>> Please forgive me if this is already possible and I have missed it.
>>
>> http://readlist.com/lists/tycho.nsa.gov/selinux/1/7187.html
>>
>> nope, you didn't miss it, but it should be coming from the userspace
>> people sometime.....
>>
> 
> Its been in svn since 2007-08-16, versions:
> libsemanage 2.0.4
> policycoreutils 2.0.23
> libsepol 2.0.6
> 
> 

Hrm.. I suppose my response could have been a little more helpful.
http://marc.info/?l=selinux&m=118670946125889&w=2

If you have the versions mentioned above you can disable all dontaudits 
by running semodule -DB.

Once you are done you can run semodule -B and get dontaudits back.


--
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: concept of a permissive domain

[Karl MacMillan]

On Tue, 2007-09-18 at 16:24 -0400, Stephen Smalley wrote:
> On Thu, 2007-09-13 at 16:16 -0400, Eric Paris wrote:
> > On Thu, 2007-09-13 at 15:38 -0400, Stephen Smalley wrote:
> > > On Thu, 2007-09-13 at 15:25 -0400, Daniel J Walsh wrote:

[...]

> > We need denial rules, we just don't have to call them that.  We just
> > need to define how dontaudit and auditallow rules work in this new type
> > of domain.  Then decide if that somehow interferes if the domain is not
> > a permissive domain.  Aside from Karl's little flub, noone is arguing we
> > should change anything having to do with enforcing=0 or enforcing=1 and
> > a non-permissive-domain.  We don't need to rewrite how dontaudit rules
> > affect enforcing domains or non-enforcing-systems, we just need an
> > extended definition for permissive domains.  Seems dontaudit and
> > auditallow can work very nicely to solve real practical problems
> > constraining large applications in environments which may not be friends
> > to problems introduced by SELinux.  Everyone agrees running an
> > application and just allowing whatever it asks for isn't the best way to
> > write policy, but when it's all you have, and all you are going to
> > reasonably have I'm not hearing a argument why we can't do what Dan
> > wants, other than 'that's not what it means today.'
> > 
> > dontaudit as an 'implicit denial in permissive domains' isn't what we
> > have today, but then again, we don't have permissive domains today.
> 
> I think we need to be careful that we aren't making SELinux harder to
> understand.  You are introducing a new construct that doesn't correspond
> precisely with either "unconfined" domains under enforcing mode or all
> domains under permissive mode today, and then you'll have to explain to
> users how they each differ and how to use them in a coherent way.


I understand the concern, but I think that the concept is pretty simple
to understand. What is harder is the subtle operational differences.

>   Maybe
> it would be useful to talk again about why we can't go with the "make
> the domain unconfined in policy and use auditallow" approach.  There is
> the log-once aspect of permissive mode, but possibly that could be made
> selectable for domains, and there is the difference in the log messages
> (granted vs. denied), but the tools can certainly deal with that.
> 

To get a tool to do this you would essentially need to work on the final
policy. It would:

1. Determine the set of all possible access (which requires the ability
to enumerate all classes/perms and types).

2. Determine the set of access explicitly allowed for the permissive
domain.

3. Take the difference of those sets and insert auditallow rules for
that access.

Note that this would be different that unconfined because it would
likely allow all perms for all object classes for all types.
Alternatively we could try to determine what access an unconfined domain
is granted and use that set instead. The main problem is that access is
only available in the preprocessed policy (e.g., to sepolgen), while
this tool really needs to operate on the final, expanded policy.

The downsides of this approach:

1) Lots of additional rules.
2) The tool will be somewhat painful to write - not clear who will do
that.
3) Correctness seems harder to achieve versus the kernel route to me.
4) Absent a way to generate single denial rules via policy, we will also
have to change sepolgen to use granted rules. This will end up exposed
to the user (they will have to ask for it) and it means that we can't
use auditallow rules for these domains in general.

> Also, one other thing to keep in mind for the permissive domain concept
> is that permission checks don't always fall neatly into the domain-type
> form and that domains tend to flow to related objects (sockets, packets,
> proc inodes, etc), so it is possibly insufficient and/or unsafe to
> determine whether to apply permissive mode on the source context in all
> cases.  Requires some investigation of all of the checks today.
> 

Yeah - that's going to be tricky. The tool would have the same problem -
it would have to generate some rules with the domain as target.

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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would like to get this moving again.

I believe we came to a conclusion that the permissive domain should be
specified in userspace/policy.  So the next question is who can make the
change and what is the syntax?

I see we can do this in two ways.

One we add a new access to the Process Class called Permissive;
Which would cause the kernel to put this domain in the permissive
domain.  I am sure Steven dislikes this suggestion.  :^)


The second solution is to add a new command to audit, dontaudit,
auditallow, nerverallow

So if we add permissiveallow or just permissive.

What does the syntax look like?

permissive httpd_t;

permissive httpd_t self:process *;

In order to implement this, we need to modify libsepol,
checkmodule/checkpolicy?

Anything else?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHD3u/rlYvE4MpobMRAsb8AKCknzQMPwWk8NlkQXR/Et4HJ3drCgCfRxjj
wSFzHkV45PqsE/GwUMaf8bk=
=bWur
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I would like to get this moving again.
> 
> I believe we came to a conclusion that the permissive domain should be
> specified in userspace/policy.  So the next question is who can make the
> change and what is the syntax?
> 
> I see we can do this in two ways.
> 
> One we add a new access to the Process Class called Permissive;
> Which would cause the kernel to put this domain in the permissive
> domain.  I am sure Steven dislikes this suggestion.  :^)
> 

Thats a really bad idea, it means that any process that had ~ or * in 
the process class now becomes permissive. It also makes the hooks a 
complete mess as they now have to check for this permission in addition 
to the real requested perm.

> 
> The second solution is to add a new command to audit, dontaudit,
> auditallow, nerverallow
> 
> So if we add permissiveallow or just permissive.
> 
> What does the syntax look like?
> 
> permissive httpd_t;
> 
> permissive httpd_t self:process *;
> 
> In order to implement this, we need to modify libsepol,
> checkmodule/checkpolicy?
> 

I don't like this one either. I'd rather do what we were thinking about 
with selinuxfs where we have /selinux/types/foo_domain_t have a bitmap 
of properties, one of them being permissive.



--
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: concept of a permissive domain

[Eric Paris]

On 10/12/07, Joshua Brindle <jbrindle@tresys.com> wrote:

> I don't like this one either. I'd rather do what we were thinking about
> with selinuxfs where we have /selinux/types/foo_domain_t have a bitmap
> of properties, one of them being permissive.

I still don't agree.  From the point of view of analysis a permissive
domain and an unconfined domain are the same thing.  Thus this should
be a part of the policy the same way unconfined domains are.

I also still disagree that the policy administrator and the
application administrator are the same person or will have the ability
to reasonably work together in such a close manner as to make the
selinuxfs permissive domain implementation acceptable.  The guy who
adds a new policy module might not be able to control enough of the
system/application to echo 1 > /selinux/blah/blah/blah/enforcing every
time the application is started.  Nor do we necessarily want to put
the permissions to make an application permissive in the domains
associated with the application itself.  aka I sure as heck don't want
httpd_t to be allowed to make itself permissive and at the same time I
personally don't think that the httpd init script is the right place
either since I'd rather not give initrc_t permission to make anything
permissive.  (ok I think initrc_t is still and unconfined domain, but
I don't like it)

--
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: concept of a permissive domain

[Chad Sellers]

On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I would like to get this moving again.
> 
> I believe we came to a conclusion that the permissive domain should be
> specified in userspace/policy.  So the next question is who can make the
> change and what is the syntax?
> 
> I see we can do this in two ways.
> 
> One we add a new access to the Process Class called Permissive;
> Which would cause the kernel to put this domain in the permissive
> domain.  I am sure Steven dislikes this suggestion.  :^)
> 
> 
> The second solution is to add a new command to audit, dontaudit,
> auditallow, nerverallow
> 
> So if we add permissiveallow or just permissive.
> 
> What does the syntax look like?
> 
> permissive httpd_t;
> 
> permissive httpd_t self:process *;
> 
> In order to implement this, we need to modify libsepol,
> checkmodule/checkpolicy?
> 
> Anything else?

The kernel, for one. Both of these involve new policy constructs that the
kernel would use. Or am I misunderstanding what you're saying?

The last message on this thread seems to be Karl's message talking about
potentially doing this in userspace (meaning make libsemanage or something
similar go through policy, allow everything for a domain, auditallow
everything that's not explicitly allowed) and how this is possible but
painful. Did I miss any later follow up to this? Where are we with respect
to doing this in kernel vs. in policy?

I really don't care either way any more. My main concern is I want us to
come up with something that doesn't create another new concept to confuse
users. To me, this means either
1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
unconfined with auditallows. This could be done via Karl's earlier method.
Admittedly, the tool to create the policy would not be easy.
2) permissive domain that is the same as global permissive. This could be
done via an selinuxfs node (similar to global permissive) and made
persistent by some sort of state in /etc/selinux (like global permissive).

I know I may be in the minority here, but I really think we should consider
trying to minimize the differences in concepts we create as much as possible
to avoid complexity creep.

Thanks,
Chad

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHD3u/rlYvE4MpobMRAsb8AKCknzQMPwWk8NlkQXR/Et4HJ3drCgCfRxjj
> wSFzHkV45PqsE/GwUMaf8bk=
> =bWur
> -----END PGP SIGNATURE-----



--
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: concept of a permissive domain

[Karl MacMillan]

On Fri, 2007-10-12 at 14:07 -0400, Eric Paris wrote:
> On 10/12/07, Joshua Brindle <jbrindle@tresys.com> wrote:
> 
> > I don't like this one either. I'd rather do what we were thinking about
> > with selinuxfs where we have /selinux/types/foo_domain_t have a bitmap
> > of properties, one of them being permissive.
> 
> I still don't agree.  From the point of view of analysis a permissive
> domain and an unconfined domain are the same thing.  Thus this should
> be a part of the policy the same way unconfined domains are.
> 
> I also still disagree that the policy administrator and the
> application administrator are the same person or will have the ability
> to reasonably work together in such a close manner as to make the
> selinuxfs permissive domain implementation acceptable.  The guy who
> adds a new policy module might not be able to control enough of the
> system/application to echo 1 > /selinux/blah/blah/blah/enforcing every
> time the application is started.  Nor do we necessarily want to put
> the permissions to make an application permissive in the domains
> associated with the application itself.  aka I sure as heck don't want
> httpd_t to be allowed to make itself permissive and at the same time I
> personally don't think that the httpd init script is the right place
> either since I'd rather not give initrc_t permission to make anything
> permissive.  (ok I think initrc_t is still and unconfined domain, but
> I don't like it)

So I agree - I _really_ don't understand why we say some selinux
configuration is part of the policy and some is not. It is just
confusing and requires that we built more infrastructure.

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: concept of a permissive domain

[Karl MacMillan]

On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I would like to get this moving again.
> > 
> > I believe we came to a conclusion that the permissive domain should be
> > specified in userspace/policy.  So the next question is who can make the
> > change and what is the syntax?
> > 
> > I see we can do this in two ways.
> > 
> > One we add a new access to the Process Class called Permissive;
> > Which would cause the kernel to put this domain in the permissive
> > domain.  I am sure Steven dislikes this suggestion.  :^)
> > 
> > 
> > The second solution is to add a new command to audit, dontaudit,
> > auditallow, nerverallow
> > 
> > So if we add permissiveallow or just permissive.
> > 
> > What does the syntax look like?
> > 
> > permissive httpd_t;
> > 
> > permissive httpd_t self:process *;
> > 
> > In order to implement this, we need to modify libsepol,
> > checkmodule/checkpolicy?
> > 
> > Anything else?
> 
> The kernel, for one. Both of these involve new policy constructs that the
> kernel would use. Or am I misunderstanding what you're saying?
> 
> The last message on this thread seems to be Karl's message talking about
> potentially doing this in userspace (meaning make libsemanage or something
> similar go through policy, allow everything for a domain, auditallow
> everything that's not explicitly allowed) and how this is possible but
> painful. Did I miss any later follow up to this? Where are we with respect
> to doing this in kernel vs. in policy?
> 
> I really don't care either way any more. My main concern is I want us to
> come up with something that doesn't create another new concept to confuse
> users. To me, this means either
> 1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
> unconfined with auditallows. This could be done via Karl's earlier method.
> Admittedly, the tool to create the policy would not be easy.
> 2) permissive domain that is the same as global permissive. This could be
> done via an selinuxfs node (similar to global permissive) and made
> persistent by some sort of state in /etc/selinux (like global permissive).
> 
> I know I may be in the minority here, but I really think we should consider
> trying to minimize the differences in concepts we create as much as possible
> to avoid complexity creep.

Calling it a permissive domain uses the same concept as global
permissive - so I think that is natural. It does not, to me, mean that
it should be enabled in the same way as global permissive - that's just
an implementation detail. I think it is much better to put it in the
policy as that allows some sort of sane delivery mechanism.

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: concept of a permissive domain

[Stephen Smalley]

On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I would like to get this moving again.
> > 
> > I believe we came to a conclusion that the permissive domain should be
> > specified in userspace/policy.  So the next question is who can make the
> > change and what is the syntax?
> > 
> > I see we can do this in two ways.
> > 
> > One we add a new access to the Process Class called Permissive;
> > Which would cause the kernel to put this domain in the permissive
> > domain.  I am sure Steven dislikes this suggestion.  :^)
> > 
> > 
> > The second solution is to add a new command to audit, dontaudit,
> > auditallow, nerverallow
> > 
> > So if we add permissiveallow or just permissive.
> > 
> > What does the syntax look like?
> > 
> > permissive httpd_t;
> > 
> > permissive httpd_t self:process *;
> > 
> > In order to implement this, we need to modify libsepol,
> > checkmodule/checkpolicy?
> > 
> > Anything else?
> 
> The kernel, for one. Both of these involve new policy constructs that the
> kernel would use. Or am I misunderstanding what you're saying?
> 
> The last message on this thread seems to be Karl's message talking about
> potentially doing this in userspace (meaning make libsemanage or something
> similar go through policy, allow everything for a domain, auditallow
> everything that's not explicitly allowed) and how this is possible but
> painful. Did I miss any later follow up to this? Where are we with respect
> to doing this in kernel vs. in policy?
> 
> I really don't care either way any more. My main concern is I want us to
> come up with something that doesn't create another new concept to confuse
> users. To me, this means either
> 1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
> unconfined with auditallows. This could be done via Karl's earlier method.
> Admittedly, the tool to create the policy would not be easy.

Two possible stumbling blocks there:
1) auditallow will audit every permission check, while permissive only
audits the first occurrence (for a given source context, target context,
target class triple, which may actually cover multiple processes and/or
objects).  The permissive behavior was designed to avoid flooding the
audit logs with duplicate information, but it does have the disadvantage
that we don't see every denial, which could be useful when trying to
generate a policy from the auxiliary audit information beyond just the
contexts and classes (e.g. if you want to do pattern matching ala MITRE
Polgen on application behavior).  Also, the flooding problem is somewhat
alleviated by the recent change to not recheck on every read/write but
only when necessary, although that only dealt with read/write, not e.g.
socket sends and receives.

2) auditallow yields avc granted messages, whereas all policy tools
today look for avc denied messages.  And we use auditallow statements in
policy today to catch certain important events, so we'd have to make
sure that the tools don't accidentally generate from those audit
messages (well, I suppose they would be redundant and filterable on
domain).

> 2) permissive domain that is the same as global permissive. This could be
> done via an selinuxfs node (similar to global permissive) and made
> persistent by some sort of state in /etc/selinux (like global permissive).

That would be more like today's permissive mode, but as others have
pointed out, the per-domain permissive mode is more like an unconfined
domain and it would be useful to be able to see it in the policy for
analysis and management purposes.

> I know I may be in the minority here, but I really think we should consider
> trying to minimize the differences in concepts we create as much as possible
> to avoid complexity creep.

-- 
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: concept of a permissive domain

[Stephen Smalley]

On Fri, 2007-10-12 at 15:03 -0400, Karl MacMillan wrote:
> On Fri, 2007-10-12 at 14:07 -0400, Eric Paris wrote:
> > On 10/12/07, Joshua Brindle <jbrindle@tresys.com> wrote:
> > 
> > > I don't like this one either. I'd rather do what we were thinking about
> > > with selinuxfs where we have /selinux/types/foo_domain_t have a bitmap
> > > of properties, one of them being permissive.
> > 
> > I still don't agree.  From the point of view of analysis a permissive
> > domain and an unconfined domain are the same thing.  Thus this should
> > be a part of the policy the same way unconfined domains are.
> > 
> > I also still disagree that the policy administrator and the
> > application administrator are the same person or will have the ability
> > to reasonably work together in such a close manner as to make the
> > selinuxfs permissive domain implementation acceptable.  The guy who
> > adds a new policy module might not be able to control enough of the
> > system/application to echo 1 > /selinux/blah/blah/blah/enforcing every
> > time the application is started.  Nor do we necessarily want to put
> > the permissions to make an application permissive in the domains
> > associated with the application itself.  aka I sure as heck don't want
> > httpd_t to be allowed to make itself permissive and at the same time I
> > personally don't think that the httpd init script is the right place
> > either since I'd rather not give initrc_t permission to make anything
> > permissive.  (ok I think initrc_t is still and unconfined domain, but
> > I don't like it)
> 
> So I agree - I _really_ don't understand why we say some selinux
> configuration is part of the policy and some is not. It is just
> confusing and requires that we built more infrastructure.

Also makes it hard to measure the policy meaningfully...

-- 
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: concept of a permissive domain

[Stephen Smalley]

On Fri, 2007-10-12 at 15:07 -0400, Stephen Smalley wrote:
> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> > On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > I would like to get this moving again.
> > > 
> > > I believe we came to a conclusion that the permissive domain should be
> > > specified in userspace/policy.  So the next question is who can make the
> > > change and what is the syntax?
> > > 
> > > I see we can do this in two ways.
> > > 
> > > One we add a new access to the Process Class called Permissive;
> > > Which would cause the kernel to put this domain in the permissive
> > > domain.  I am sure Steven dislikes this suggestion.  :^)
> > > 
> > > 
> > > The second solution is to add a new command to audit, dontaudit,
> > > auditallow, nerverallow
> > > 
> > > So if we add permissiveallow or just permissive.
> > > 
> > > What does the syntax look like?
> > > 
> > > permissive httpd_t;
> > > 
> > > permissive httpd_t self:process *;
> > > 
> > > In order to implement this, we need to modify libsepol,
> > > checkmodule/checkpolicy?
> > > 
> > > Anything else?
> > 
> > The kernel, for one. Both of these involve new policy constructs that the
> > kernel would use. Or am I misunderstanding what you're saying?
> > 
> > The last message on this thread seems to be Karl's message talking about
> > potentially doing this in userspace (meaning make libsemanage or something
> > similar go through policy, allow everything for a domain, auditallow
> > everything that's not explicitly allowed) and how this is possible but
> > painful. Did I miss any later follow up to this? Where are we with respect
> > to doing this in kernel vs. in policy?
> > 
> > I really don't care either way any more. My main concern is I want us to
> > come up with something that doesn't create another new concept to confuse
> > users. To me, this means either
> > 1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
> > unconfined with auditallows. This could be done via Karl's earlier method.
> > Admittedly, the tool to create the policy would not be easy.
> 
> Two possible stumbling blocks there:
> 1) auditallow will audit every permission check, while permissive only
> audits the first occurrence (for a given source context, target context,
> target class triple, which may actually cover multiple processes and/or
> objects).  The permissive behavior was designed to avoid flooding the
> audit logs with duplicate information, but it does have the disadvantage
> that we don't see every denial, which could be useful when trying to
> generate a policy from the auxiliary audit information beyond just the
> contexts and classes (e.g. if you want to do pattern matching ala MITRE
> Polgen on application behavior).  Also, the flooding problem is somewhat
> alleviated by the recent change to not recheck on every read/write but
> only when necessary, although that only dealt with read/write, not e.g.
> socket sends and receives.
> 
> 2) auditallow yields avc granted messages, whereas all policy tools
> today look for avc denied messages.  And we use auditallow statements in
> policy today to catch certain important events, so we'd have to make
> sure that the tools don't accidentally generate from those audit
> messages (well, I suppose they would be redundant and filterable on
> domain).
> 
> > 2) permissive domain that is the same as global permissive. This could be
> > done via an selinuxfs node (similar to global permissive) and made
> > persistent by some sort of state in /etc/selinux (like global permissive).
> 
> That would be more like today's permissive mode, but as others have
> pointed out, the per-domain permissive mode is more like an unconfined
> domain and it would be useful to be able to see it in the policy for
> analysis and management purposes.

Possible stumbling blocks on the second (kernel) approach:
1) It doesn't address userspace object managers at all - we'd have to
change libselinux too, and provide a selinuxfs interface for checking
whether a context is permissive.
2) It doesn't provide any flexibility in what we allow to the domain,
merely "if the source context has domain X, allow it", versus the more
granular control we have in defining unconfined domains today.  That of
particular concern if some checks don't quite follow the conventional
subject-object form.

-- 
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: concept of a permissive domain

[Chad Sellers]

On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:

> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
>> On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> I would like to get this moving again.
>>> 
>>> I believe we came to a conclusion that the permissive domain should be
>>> specified in userspace/policy.  So the next question is who can make the
>>> change and what is the syntax?
>>> 
>>> I see we can do this in two ways.
>>> 
>>> One we add a new access to the Process Class called Permissive;
>>> Which would cause the kernel to put this domain in the permissive
>>> domain.  I am sure Steven dislikes this suggestion.  :^)
>>> 
>>> 
>>> The second solution is to add a new command to audit, dontaudit,
>>> auditallow, nerverallow
>>> 
>>> So if we add permissiveallow or just permissive.
>>> 
>>> What does the syntax look like?
>>> 
>>> permissive httpd_t;
>>> 
>>> permissive httpd_t self:process *;
>>> 
>>> In order to implement this, we need to modify libsepol,
>>> checkmodule/checkpolicy?
>>> 
>>> Anything else?
>> 
>> The kernel, for one. Both of these involve new policy constructs that the
>> kernel would use. Or am I misunderstanding what you're saying?
>> 
>> The last message on this thread seems to be Karl's message talking about
>> potentially doing this in userspace (meaning make libsemanage or something
>> similar go through policy, allow everything for a domain, auditallow
>> everything that's not explicitly allowed) and how this is possible but
>> painful. Did I miss any later follow up to this? Where are we with respect
>> to doing this in kernel vs. in policy?
>> 
>> I really don't care either way any more. My main concern is I want us to
>> come up with something that doesn't create another new concept to confuse
>> users. To me, this means either
>> 1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
>> unconfined with auditallows. This could be done via Karl's earlier method.
>> Admittedly, the tool to create the policy would not be easy.
>> 2) permissive domain that is the same as global permissive. This could be
>> done via an selinuxfs node (similar to global permissive) and made
>> persistent by some sort of state in /etc/selinux (like global permissive).
>> 
>> I know I may be in the minority here, but I really think we should consider
>> trying to minimize the differences in concepts we create as much as possible
>> to avoid complexity creep.
> 
> Calling it a permissive domain uses the same concept as global
> permissive - so I think that is natural. It does not, to me, mean that
> it should be enabled in the same way as global permissive - that's just
> an implementation detail. I think it is much better to put it in the
> policy as that allows some sort of sane delivery mechanism.
> 
Calling it one thing and implementing it differently is fine as long as the
implementation doesn't leak out to the user. And it will here. We're not
exactly good at making leak-proof abstractions to begin with, but this is a
case where the user will see a new statement in policy.

Think of this from the perspective of the user. We have to tell them that
system-wide permissive is not part of policy, but is instead in a config
file, done using setenforce, or done using selinuxfs, but per-domain
permissive is not done by any of those methods, but instead is done in
policy via a new language construct. This is confusing.

Chad


--
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: concept of a permissive domain

[Stephen Smalley]

On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> 
> > On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> >> On 10/12/07 9:50 AM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> >> 
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>> 
> >>> I would like to get this moving again.
> >>> 
> >>> I believe we came to a conclusion that the permissive domain should be
> >>> specified in userspace/policy.  So the next question is who can make the
> >>> change and what is the syntax?
> >>> 
> >>> I see we can do this in two ways.
> >>> 
> >>> One we add a new access to the Process Class called Permissive;
> >>> Which would cause the kernel to put this domain in the permissive
> >>> domain.  I am sure Steven dislikes this suggestion.  :^)
> >>> 
> >>> 
> >>> The second solution is to add a new command to audit, dontaudit,
> >>> auditallow, nerverallow
> >>> 
> >>> So if we add permissiveallow or just permissive.
> >>> 
> >>> What does the syntax look like?
> >>> 
> >>> permissive httpd_t;
> >>> 
> >>> permissive httpd_t self:process *;
> >>> 
> >>> In order to implement this, we need to modify libsepol,
> >>> checkmodule/checkpolicy?
> >>> 
> >>> Anything else?
> >> 
> >> The kernel, for one. Both of these involve new policy constructs that the
> >> kernel would use. Or am I misunderstanding what you're saying?
> >> 
> >> The last message on this thread seems to be Karl's message talking about
> >> potentially doing this in userspace (meaning make libsemanage or something
> >> similar go through policy, allow everything for a domain, auditallow
> >> everything that's not explicitly allowed) and how this is possible but
> >> painful. Did I miss any later follow up to this? Where are we with respect
> >> to doing this in kernel vs. in policy?
> >> 
> >> I really don't care either way any more. My main concern is I want us to
> >> come up with something that doesn't create another new concept to confuse
> >> users. To me, this means either
> >> 1) matches unconfined_t, perhaps call it unconfined_audit and make a domain
> >> unconfined with auditallows. This could be done via Karl's earlier method.
> >> Admittedly, the tool to create the policy would not be easy.
> >> 2) permissive domain that is the same as global permissive. This could be
> >> done via an selinuxfs node (similar to global permissive) and made
> >> persistent by some sort of state in /etc/selinux (like global permissive).
> >> 
> >> I know I may be in the minority here, but I really think we should consider
> >> trying to minimize the differences in concepts we create as much as possible
> >> to avoid complexity creep.
> > 
> > Calling it a permissive domain uses the same concept as global
> > permissive - so I think that is natural. It does not, to me, mean that
> > it should be enabled in the same way as global permissive - that's just
> > an implementation detail. I think it is much better to put it in the
> > policy as that allows some sort of sane delivery mechanism.
> > 
> Calling it one thing and implementing it differently is fine as long as the
> implementation doesn't leak out to the user. And it will here. We're not
> exactly good at making leak-proof abstractions to begin with, but this is a
> case where the user will see a new statement in policy.
> 
> Think of this from the perspective of the user. We have to tell them that
> system-wide permissive is not part of policy, but is instead in a config
> file, done using setenforce, or done using selinuxfs, but per-domain
> permissive is not done by any of those methods, but instead is done in
> policy via a new language construct. This is confusing.

That doesn't seem too bad given that one is a global property of the
system and one is per-domain.  Especially since a permissive domain is
logically the same as an unconfined domain + a matching auditallow
statement for every allow statement.  Whether we implement it that way
or not is open to discussion.

-- 
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: concept of a permissive domain

[Karl MacMillan]

On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> 
> > On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:

[...[

> > 
> > Calling it a permissive domain uses the same concept as global
> > permissive - so I think that is natural. It does not, to me, mean that
> > it should be enabled in the same way as global permissive - that's just
> > an implementation detail. I think it is much better to put it in the
> > policy as that allows some sort of sane delivery mechanism.
> > 
> Calling it one thing and implementing it differently is fine as long as the
> implementation doesn't leak out to the user. And it will here. We're not
> exactly good at making leak-proof abstractions to begin with, but this is a
> case where the user will see a new statement in policy.
> 
> Think of this from the perspective of the user. We have to tell them that
> system-wide permissive is not part of policy, but is instead in a config
> file, done using setenforce, or done using selinuxfs, but per-domain
> permissive is not done by any of those methods, but instead is done in
> policy via a new language construct. This is confusing.
> 
> Chad

See, now you are going to make me argue for putting permissive in the
policy, which I think that it should be. The fact that we have
permissive in a separate config file, have to write a little parser in
libselinux, patch apps to set permissive on boot is just dumb.

That doesn't mean when shouldn't allow small changes to the in-kernel
policy - like switching permissive on or off - but I still think it
makes no sense to have one big configuration file with lots of tiny
supporting config files. Just put it all in one place and be done with
it.

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: concept of a permissive domain

[Chad Sellers]

On 10/12/07 5:21 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:

> On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
>> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
>> 
>>> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> 
> [...[
> 
>>> 
>>> Calling it a permissive domain uses the same concept as global
>>> permissive - so I think that is natural. It does not, to me, mean that
>>> it should be enabled in the same way as global permissive - that's just
>>> an implementation detail. I think it is much better to put it in the
>>> policy as that allows some sort of sane delivery mechanism.
>>> 
>> Calling it one thing and implementing it differently is fine as long as the
>> implementation doesn't leak out to the user. And it will here. We're not
>> exactly good at making leak-proof abstractions to begin with, but this is a
>> case where the user will see a new statement in policy.
>> 
>> Think of this from the perspective of the user. We have to tell them that
>> system-wide permissive is not part of policy, but is instead in a config
>> file, done using setenforce, or done using selinuxfs, but per-domain
>> permissive is not done by any of those methods, but instead is done in
>> policy via a new language construct. This is confusing.
>> 
>> Chad
> 
> See, now you are going to make me argue for putting permissive in the
> policy, which I think that it should be. The fact that we have
> permissive in a separate config file, have to write a little parser in
> libselinux, patch apps to set permissive on boot is just dumb.
> 
I figured that might be your response. I actually don't mind that solution
at all. I'm just trying to minimize the number of different concepts in
SELinux.

> That doesn't mean when shouldn't allow small changes to the in-kernel
> policy - like switching permissive on or off - but I still think it
> makes no sense to have one big configuration file with lots of tiny
> supporting config files. Just put it all in one place and be done with
> it.
> 
Note that we already have a mechanism for turning pieces of policy on/off
in-kernel (booleans). So, if permissive were policy based, we could
potentially simplify things by having the kernel "switch" be just another
boolean instead of a separate mechanism.

Chad

> 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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chad Sellers wrote:
> On 10/12/07 5:21 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> 
>> On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
>>> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
>>>
>>>> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
>> [...[
>>
>>>> Calling it a permissive domain uses the same concept as global
>>>> permissive - so I think that is natural. It does not, to me, mean that
>>>> it should be enabled in the same way as global permissive - that's just
>>>> an implementation detail. I think it is much better to put it in the
>>>> policy as that allows some sort of sane delivery mechanism.
>>>>
>>> Calling it one thing and implementing it differently is fine as long as the
>>> implementation doesn't leak out to the user. And it will here. We're not
>>> exactly good at making leak-proof abstractions to begin with, but this is a
>>> case where the user will see a new statement in policy.
>>>
>>> Think of this from the perspective of the user. We have to tell them that
>>> system-wide permissive is not part of policy, but is instead in a config
>>> file, done using setenforce, or done using selinuxfs, but per-domain
>>> permissive is not done by any of those methods, but instead is done in
>>> policy via a new language construct. This is confusing.
>>>
>>> Chad
>> See, now you are going to make me argue for putting permissive in the
>> policy, which I think that it should be. The fact that we have
>> permissive in a separate config file, have to write a little parser in
>> libselinux, patch apps to set permissive on boot is just dumb.
>>
> I figured that might be your response. I actually don't mind that solution
> at all. I'm just trying to minimize the number of different concepts in
> SELinux.
> 
>> That doesn't mean when shouldn't allow small changes to the in-kernel
>> policy - like switching permissive on or off - but I still think it
>> makes no sense to have one big configuration file with lots of tiny
>> supporting config files. Just put it all in one place and be done with
>> it.
>>
> Note that we already have a mechanism for turning pieces of policy on/off
> in-kernel (booleans). So, if permissive were policy based, we could
> potentially simplify things by having the kernel "switch" be just another
> boolean instead of a separate mechanism.
> 
> Chad
> 
>> Karl
>>
> 
- From the user point of view we could change the setenforce command

setenforce 0
setenforce httpd_t 0

getenforce 0
getenforce httpd_t 0

Then we could replace both to do something in semanage to rebuild and
reload policy.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHEMpErlYvE4MpobMRApyIAKDPblk4zBoGsZyj8euc1JgTpvetcACgmpNI
4zKVHCrPKOGtuFPnm35xM5c=
=n6n2
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Stefan Schulze Frielinghaus]

On Sat, 2007-10-13 at 09:38 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chad Sellers wrote:
> > On 10/12/07 5:21 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> > 
> >> On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
> >>> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> >>>
> >>>> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
> >> [...[
> >>
> >>>> Calling it a permissive domain uses the same concept as global
> >>>> permissive - so I think that is natural. It does not, to me, mean that
> >>>> it should be enabled in the same way as global permissive - that's just
> >>>> an implementation detail. I think it is much better to put it in the
> >>>> policy as that allows some sort of sane delivery mechanism.
> >>>>
> >>> Calling it one thing and implementing it differently is fine as long as the
> >>> implementation doesn't leak out to the user. And it will here. We're not
> >>> exactly good at making leak-proof abstractions to begin with, but this is a
> >>> case where the user will see a new statement in policy.
> >>>
> >>> Think of this from the perspective of the user. We have to tell them that
> >>> system-wide permissive is not part of policy, but is instead in a config
> >>> file, done using setenforce, or done using selinuxfs, but per-domain
> >>> permissive is not done by any of those methods, but instead is done in
> >>> policy via a new language construct. This is confusing.
> >>>
> >>> Chad
> >> See, now you are going to make me argue for putting permissive in the
> >> policy, which I think that it should be. The fact that we have
> >> permissive in a separate config file, have to write a little parser in
> >> libselinux, patch apps to set permissive on boot is just dumb.
> >>
> > I figured that might be your response. I actually don't mind that solution
> > at all. I'm just trying to minimize the number of different concepts in
> > SELinux.
> > 
> >> That doesn't mean when shouldn't allow small changes to the in-kernel
> >> policy - like switching permissive on or off - but I still think it
> >> makes no sense to have one big configuration file with lots of tiny
> >> supporting config files. Just put it all in one place and be done with
> >> it.
> >>
> > Note that we already have a mechanism for turning pieces of policy on/off
> > in-kernel (booleans). So, if permissive were policy based, we could
> > potentially simplify things by having the kernel "switch" be just another
> > boolean instead of a separate mechanism.
> > 
> > Chad
> > 
> >> Karl
> >>
> > 
> - From the user point of view we could change the setenforce command
> 
> setenforce 0
> setenforce httpd_t 0
> 
> getenforce 0
> getenforce httpd_t 0
> 
> Then we could replace both to do something in semanage to rebuild and
> reload policy.

But that would mean e.g. consider apache that you would have to
setenforce for every domain type?

apache_t
apache_helper_t
apache_php_t
httpd_rotatelogs_t
httpd_suexec_t
...

There wouldn't be a setenforce for a whole module, right?

	Stefan


--
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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Schulze Frielinghaus wrote:
> On Sat, 2007-10-13 at 09:38 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Chad Sellers wrote:
>>> On 10/12/07 5:21 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
>>>
>>>> On Fri, 2007-10-12 at 16:43 -0400, Chad Sellers wrote:
>>>>> On 10/12/07 3:05 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
>>>>>
>>>>>> On Fri, 2007-10-12 at 14:40 -0400, Chad Sellers wrote:
>>>> [...[
>>>>
>>>>>> Calling it a permissive domain uses the same concept as global
>>>>>> permissive - so I think that is natural. It does not, to me, mean that
>>>>>> it should be enabled in the same way as global permissive - that's just
>>>>>> an implementation detail. I think it is much better to put it in the
>>>>>> policy as that allows some sort of sane delivery mechanism.
>>>>>>
>>>>> Calling it one thing and implementing it differently is fine as long as the
>>>>> implementation doesn't leak out to the user. And it will here. We're not
>>>>> exactly good at making leak-proof abstractions to begin with, but this is a
>>>>> case where the user will see a new statement in policy.
>>>>>
>>>>> Think of this from the perspective of the user. We have to tell them that
>>>>> system-wide permissive is not part of policy, but is instead in a config
>>>>> file, done using setenforce, or done using selinuxfs, but per-domain
>>>>> permissive is not done by any of those methods, but instead is done in
>>>>> policy via a new language construct. This is confusing.
>>>>>
>>>>> Chad
>>>> See, now you are going to make me argue for putting permissive in the
>>>> policy, which I think that it should be. The fact that we have
>>>> permissive in a separate config file, have to write a little parser in
>>>> libselinux, patch apps to set permissive on boot is just dumb.
>>>>
>>> I figured that might be your response. I actually don't mind that solution
>>> at all. I'm just trying to minimize the number of different concepts in
>>> SELinux.
>>>
>>>> That doesn't mean when shouldn't allow small changes to the in-kernel
>>>> policy - like switching permissive on or off - but I still think it
>>>> makes no sense to have one big configuration file with lots of tiny
>>>> supporting config files. Just put it all in one place and be done with
>>>> it.
>>>>
>>> Note that we already have a mechanism for turning pieces of policy on/off
>>> in-kernel (booleans). So, if permissive were policy based, we could
>>> potentially simplify things by having the kernel "switch" be just another
>>> boolean instead of a separate mechanism.
>>>
>>> Chad
>>>
>>>> Karl
>>>>
>> - From the user point of view we could change the setenforce command
>>
>> setenforce 0
>> setenforce httpd_t 0
>>
>> getenforce 0
>> getenforce httpd_t 0
>>
>> Then we could replace both to do something in semanage to rebuild and
>> reload policy.
> 
> But that would mean e.g. consider apache that you would have to
> setenforce for every domain type?
> 
> apache_t
> apache_helper_t
> apache_php_t
> httpd_rotatelogs_t
> httpd_suexec_t
> ...
> 
> There wouldn't be a setenforce for a whole module, right?
> 
> 	Stefan
> 
Yes although it is doubtful you would have all of those running at the
same time.  (httpd_t and httpd_helper_t).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
p4+2X7ixDbvoxSyMjrReLCE=
=6X1D
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Brett Lentz]

On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> >> - From the user point of view we could change the setenforce command
> >>
> >> setenforce 0
> >> setenforce httpd_t 0
> >>
> >> getenforce 0
> >> getenforce httpd_t 0
> >>
> >> Then we could replace both to do something in semanage to rebuild and
> >> reload policy.
> > 
> > But that would mean e.g. consider apache that you would have to
> > setenforce for every domain type?
> > 
> > apache_t
> > apache_helper_t
> > apache_php_t
> > httpd_rotatelogs_t
> > httpd_suexec_t
> > ...
> > 
> > There wouldn't be a setenforce for a whole module, right?
> > 
> > 	Stefan
> > 
> Yes although it is doubtful you would have all of those running at the
> same time.  (httpd_t and httpd_helper_t).
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> p4+2X7ixDbvoxSyMjrReLCE=
> =6X1D
> -----END PGP SIGNATURE-----


As an SELinux user, it makes the most sense to me for this capability to
be accessible on a per-module basis rather than per-domain.

I would much rather set the httpd module as a whole to permissive rather
than fiddle around trying to A) set all of httpd's domains to permissive
and B) requiring a fairly significant amount of knowledge of the
security policy to know which domains may require this intervention.

I think that per-domain permissive is probably useful for certain kinds
of policy development, but per-module permissive would be significantly
more useful for the work that I'm currently doing with SELinux.

_______________________________
Brett Lentz | CarDomain Network
System Administrator

blentz@cardomain.com | tel 206.926.2109 | cell 206.851.6669
http://www.cardomain.com/id/wakko666

One organism, one vote.

--
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: concept of a permissive domain

[Stephen Smalley]

On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> > >> - From the user point of view we could change the setenforce command
> > >>
> > >> setenforce 0
> > >> setenforce httpd_t 0
> > >>
> > >> getenforce 0
> > >> getenforce httpd_t 0
> > >>
> > >> Then we could replace both to do something in semanage to rebuild and
> > >> reload policy.
> > > 
> > > But that would mean e.g. consider apache that you would have to
> > > setenforce for every domain type?
> > > 
> > > apache_t
> > > apache_helper_t
> > > apache_php_t
> > > httpd_rotatelogs_t
> > > httpd_suexec_t
> > > ...
> > > 
> > > There wouldn't be a setenforce for a whole module, right?
> > > 
> > > 	Stefan
> > > 
> > Yes although it is doubtful you would have all of those running at the
> > same time.  (httpd_t and httpd_helper_t).
> > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.7 (GNU/Linux)
> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > 
> > iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> > p4+2X7ixDbvoxSyMjrReLCE=
> > =6X1D
> > -----END PGP SIGNATURE-----
> 
> 
> As an SELinux user, it makes the most sense to me for this capability to
> be accessible on a per-module basis rather than per-domain.
> 
> I would much rather set the httpd module as a whole to permissive rather
> than fiddle around trying to A) set all of httpd's domains to permissive
> and B) requiring a fairly significant amount of knowledge of the
> security policy to know which domains may require this intervention.
> 
> I think that per-domain permissive is probably useful for certain kinds
> of policy development, but per-module permissive would be significantly
> more useful for the work that I'm currently doing with SELinux.

So this suggests that the userland/policy approach is the better way to
go than the kernel mechanism approach, as the former would provide the
flexibility to turn on "permissive" behavior for all domains defined by
a module more easily than the latter.  unconfined + auditallow, along
with corresponding enhancements to audit2allow to select on avc granted.
And possibly some way to enable/disable log-once behavior for avc
grantings.

-- 
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: concept of a permissive domain

[Chad Sellers]

On 10/15/07 12:52 PM, "Brett Lentz" <blentz@cardomain.com> wrote:

> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
>>>> - From the user point of view we could change the setenforce command
>>>> 
>>>> setenforce 0
>>>> setenforce httpd_t 0
>>>> 
>>>> getenforce 0
>>>> getenforce httpd_t 0
>>>> 
>>>> Then we could replace both to do something in semanage to rebuild and
>>>> reload policy.
>>> 
>>> But that would mean e.g. consider apache that you would have to
>>> setenforce for every domain type?
>>> 
>>> apache_t
>>> apache_helper_t
>>> apache_php_t
>>> httpd_rotatelogs_t
>>> httpd_suexec_t
>>> ...
>>> 
>>> There wouldn't be a setenforce for a whole module, right?
>>> 
>>> Stefan
>>> 
>> Yes although it is doubtful you would have all of those running at the
>> same time.  (httpd_t and httpd_helper_t).
>> 
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>> 
>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
>> p4+2X7ixDbvoxSyMjrReLCE=
>> =6X1D
>> -----END PGP SIGNATURE-----
> 
> 
> As an SELinux user, it makes the most sense to me for this capability to
> be accessible on a per-module basis rather than per-domain.
> 
> I would much rather set the httpd module as a whole to permissive rather
> than fiddle around trying to A) set all of httpd's domains to permissive
> and B) requiring a fairly significant amount of knowledge of the
> security policy to know which domains may require this intervention.
> 
> I think that per-domain permissive is probably useful for certain kinds
> of policy development, but per-module permissive would be significantly
> more useful for the work that I'm currently doing with SELinux.
> 
I tend to agree with using module-level granularity, except I'm not sure how
we handle things in the base module. There are still a fair amount of source
modules compiled into the base module. I suppose we could just tell the user
to set permissive on "base" for certain domains, but that's fairly
unintuitive and messy.

Chad 

> _______________________________
> Brett Lentz | CarDomain Network
> System Administrator
> 
> blentz@cardomain.com | tel 206.926.2109 | cell 206.851.6669
> http://www.cardomain.com/id/wakko666
> 
> One organism, one vote.



--
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: concept of a permissive domain

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
>> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
>>>>> - From the user point of view we could change the setenforce command
>>>>>
>>>>> setenforce 0
>>>>> setenforce httpd_t 0
>>>>>
>>>>> getenforce 0
>>>>> getenforce httpd_t 0
>>>>>
>>>>> Then we could replace both to do something in semanage to rebuild and
>>>>> reload policy.
>>>> But that would mean e.g. consider apache that you would have to
>>>> setenforce for every domain type?
>>>>
>>>> apache_t
>>>> apache_helper_t
>>>> apache_php_t
>>>> httpd_rotatelogs_t
>>>> httpd_suexec_t
>>>> ...
>>>>
>>>> There wouldn't be a setenforce for a whole module, right?
>>>>
>>>> 	Stefan
>>>>
>>> Yes although it is doubtful you would have all of those running at the
>>> same time.  (httpd_t and httpd_helper_t).
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (GNU/Linux)
>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>>>
>>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
>>> p4+2X7ixDbvoxSyMjrReLCE=
>>> =6X1D
>>> -----END PGP SIGNATURE-----
>>
>> As an SELinux user, it makes the most sense to me for this capability to
>> be accessible on a per-module basis rather than per-domain.
>>
>> I would much rather set the httpd module as a whole to permissive rather
>> than fiddle around trying to A) set all of httpd's domains to permissive
>> and B) requiring a fairly significant amount of knowledge of the
>> security policy to know which domains may require this intervention.
>>
>> I think that per-domain permissive is probably useful for certain kinds
>> of policy development, but per-module permissive would be significantly
>> more useful for the work that I'm currently doing with SELinux.
> 
> So this suggests that the userland/policy approach is the better way to
> go than the kernel mechanism approach, as the former would provide the
> flexibility to turn on "permissive" behavior for all domains defined by
> a module more easily than the latter.  unconfined + auditallow, along
> with corresponding enhancements to audit2allow to select on avc granted.
> And possibly some way to enable/disable log-once behavior for avc
> grantings.
> 
I would rather give them globing capability, something like

setenforce -t http*=0


We do not separate everything out as per module and I think it is most
likely only a certain domain is causing the problem, that the user or
policy writer would be concerned with.

Steven, I don't see where you make the leap to this suggests a userland
approach versus the kernel.

for i in `sesearch --allow | grep transition | awk '{ print $2}' | sort
- -u | grep http`; do setenforce $i 0; done

setenforce in this example is either going to have to create a loadable
policy module with all the allow and auditallow rules for the domain and
load it, or a single newcommand to tell the kernel this domain is in
permissive mode.

Either way I don't care.  I just need it soon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHE7JXrlYvE4MpobMRApMAAJ9VjZb8BTeez8I4Xsc4CrsXYrtp0QCg2edf
RBfi+L0ikWWgoioQpr+rMLA=
=HtO/
-----END PGP SIGNATURE-----

--
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: concept of a permissive domain

[Stephen Smalley]

On Mon, 2007-10-15 at 14:32 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
> >> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> >>>>> - From the user point of view we could change the setenforce command
> >>>>>
> >>>>> setenforce 0
> >>>>> setenforce httpd_t 0
> >>>>>
> >>>>> getenforce 0
> >>>>> getenforce httpd_t 0
> >>>>>
> >>>>> Then we could replace both to do something in semanage to rebuild and
> >>>>> reload policy.
> >>>> But that would mean e.g. consider apache that you would have to
> >>>> setenforce for every domain type?
> >>>>
> >>>> apache_t
> >>>> apache_helper_t
> >>>> apache_php_t
> >>>> httpd_rotatelogs_t
> >>>> httpd_suexec_t
> >>>> ...
> >>>>
> >>>> There wouldn't be a setenforce for a whole module, right?
> >>>>
> >>>> 	Stefan
> >>>>
> >>> Yes although it is doubtful you would have all of those running at the
> >>> same time.  (httpd_t and httpd_helper_t).
> >>>
> >>>
> >>> -----BEGIN PGP SIGNATURE-----
> >>> Version: GnuPG v1.4.7 (GNU/Linux)
> >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >>>
> >>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> >>> p4+2X7ixDbvoxSyMjrReLCE=
> >>> =6X1D
> >>> -----END PGP SIGNATURE-----
> >>
> >> As an SELinux user, it makes the most sense to me for this capability to
> >> be accessible on a per-module basis rather than per-domain.
> >>
> >> I would much rather set the httpd module as a whole to permissive rather
> >> than fiddle around trying to A) set all of httpd's domains to permissive
> >> and B) requiring a fairly significant amount of knowledge of the
> >> security policy to know which domains may require this intervention.
> >>
> >> I think that per-domain permissive is probably useful for certain kinds
> >> of policy development, but per-module permissive would be significantly
> >> more useful for the work that I'm currently doing with SELinux.
> > 
> > So this suggests that the userland/policy approach is the better way to
> > go than the kernel mechanism approach, as the former would provide the
> > flexibility to turn on "permissive" behavior for all domains defined by
> > a module more easily than the latter.  unconfined + auditallow, along
> > with corresponding enhancements to audit2allow to select on avc granted.
> > And possibly some way to enable/disable log-once behavior for avc
> > grantings.
> > 
> I would rather give them globing capability, something like
> 
> setenforce -t http*=0
> 
> 
> We do not separate everything out as per module and I think it is most
> likely only a certain domain is causing the problem, that the user or
> policy writer would be concerned with.
> 
> Steven, I don't see where you make the leap to this suggests a userland
> approach versus the kernel.
> 
> for i in `sesearch --allow | grep transition | awk '{ print $2}' | sort
> - -u | grep http`; do setenforce $i 0; done
> 
> setenforce in this example is either going to have to create a loadable
> policy module with all the allow and auditallow rules for the domain and
> load it, or a single newcommand to tell the kernel this domain is in
> permissive mode.
> 
> Either way I don't care.  I just need it soon.

Userland/policy approach is more flexible (per-domain, per-module,
matches domain prefix, ...) and lets you switch multiple domains
atomically between permissive and enforcing mode.  Kernel approach is
more limiting and either requires separate commit node like booleans or
won't support atomic transaction.

Also, userland/policy approach doesn't require a new kernel.  So it can
work on existing distributions (including RHEL5).

-- 
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: concept of a permissive domain

[Karl MacMillan]

On Mon, 2007-10-15 at 14:40 -0400, Stephen Smalley wrote:
> On Mon, 2007-10-15 at 14:32 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stephen Smalley wrote:
> > > On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
> > >> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> > >>>>> - From the user point of view we could change the setenforce command
> > >>>>>
> > >>>>> setenforce 0
> > >>>>> setenforce httpd_t 0
> > >>>>>
> > >>>>> getenforce 0
> > >>>>> getenforce httpd_t 0
> > >>>>>
> > >>>>> Then we could replace both to do something in semanage to rebuild and
> > >>>>> reload policy.
> > >>>> But that would mean e.g. consider apache that you would have to
> > >>>> setenforce for every domain type?
> > >>>>
> > >>>> apache_t
> > >>>> apache_helper_t
> > >>>> apache_php_t
> > >>>> httpd_rotatelogs_t
> > >>>> httpd_suexec_t
> > >>>> ...
> > >>>>
> > >>>> There wouldn't be a setenforce for a whole module, right?
> > >>>>
> > >>>> 	Stefan
> > >>>>
> > >>> Yes although it is doubtful you would have all of those running at the
> > >>> same time.  (httpd_t and httpd_helper_t).
> > >>>
> > >>>
> > >>> -----BEGIN PGP SIGNATURE-----
> > >>> Version: GnuPG v1.4.7 (GNU/Linux)
> > >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > >>>
> > >>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> > >>> p4+2X7ixDbvoxSyMjrReLCE=
> > >>> =6X1D
> > >>> -----END PGP SIGNATURE-----
> > >>
> > >> As an SELinux user, it makes the most sense to me for this capability to
> > >> be accessible on a per-module basis rather than per-domain.
> > >>
> > >> I would much rather set the httpd module as a whole to permissive rather
> > >> than fiddle around trying to A) set all of httpd's domains to permissive
> > >> and B) requiring a fairly significant amount of knowledge of the
> > >> security policy to know which domains may require this intervention.
> > >>
> > >> I think that per-domain permissive is probably useful for certain kinds
> > >> of policy development, but per-module permissive would be significantly
> > >> more useful for the work that I'm currently doing with SELinux.
> > > 
> > > So this suggests that the userland/policy approach is the better way to
> > > go than the kernel mechanism approach, as the former would provide the
> > > flexibility to turn on "permissive" behavior for all domains defined by
> > > a module more easily than the latter.  unconfined + auditallow, along
> > > with corresponding enhancements to audit2allow to select on avc granted.
> > > And possibly some way to enable/disable log-once behavior for avc
> > > grantings.
> > > 
> > I would rather give them globing capability, something like
> > 
> > setenforce -t http*=0
> > 
> > 
> > We do not separate everything out as per module and I think it is most
> > likely only a certain domain is causing the problem, that the user or
> > policy writer would be concerned with.
> > 
> > Steven, I don't see where you make the leap to this suggests a userland
> > approach versus the kernel.
> > 
> > for i in `sesearch --allow | grep transition | awk '{ print $2}' | sort
> > - -u | grep http`; do setenforce $i 0; done
> > 
> > setenforce in this example is either going to have to create a loadable
> > policy module with all the allow and auditallow rules for the domain and
> > load it, or a single newcommand to tell the kernel this domain is in
> > permissive mode.
> > 
> > Either way I don't care.  I just need it soon.
> 
> Userland/policy approach is more flexible (per-domain, per-module,
> matches domain prefix, ...) and lets you switch multiple domains
> atomically between permissive and enforcing mode.  Kernel approach is
> more limiting and either requires separate commit node like booleans or
> won't support atomic transaction.
> 
> Also, userland/policy approach doesn't require a new kernel.  So it can
> work on existing distributions (including RHEL5).
> 

It will also be _very_ difficult to implement and prone to small errors.
Basically, I don't think it is likely to happen unless someone is
willing to step up and commit a large amount of time.

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: concept of a permissive domain

[Eric Paris]

On Mon, 2007-10-15 at 14:40 -0400, Stephen Smalley wrote:
> On Mon, 2007-10-15 at 14:32 -0400, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stephen Smalley wrote:
> > > On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
> > >> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> > >>>>> - From the user point of view we could change the setenforce command
> > >>>>>
> > >>>>> setenforce 0
> > >>>>> setenforce httpd_t 0
> > >>>>>
> > >>>>> getenforce 0
> > >>>>> getenforce httpd_t 0
> > >>>>>
> > >>>>> Then we could replace both to do something in semanage to rebuild and
> > >>>>> reload policy.
> > >>>> But that would mean e.g. consider apache that you would have to
> > >>>> setenforce for every domain type?
> > >>>>
> > >>>> apache_t
> > >>>> apache_helper_t
> > >>>> apache_php_t
> > >>>> httpd_rotatelogs_t
> > >>>> httpd_suexec_t
> > >>>> ...
> > >>>>
> > >>>> There wouldn't be a setenforce for a whole module, right?
> > >>>>
> > >>>> 	Stefan
> > >>>>
> > >>> Yes although it is doubtful you would have all of those running at the
> > >>> same time.  (httpd_t and httpd_helper_t).
> > >>>
> > >>>
> > >>> -----BEGIN PGP SIGNATURE-----
> > >>> Version: GnuPG v1.4.7 (GNU/Linux)
> > >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > >>>
> > >>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> > >>> p4+2X7ixDbvoxSyMjrReLCE=
> > >>> =6X1D
> > >>> -----END PGP SIGNATURE-----
> > >>
> > >> As an SELinux user, it makes the most sense to me for this capability to
> > >> be accessible on a per-module basis rather than per-domain.
> > >>
> > >> I would much rather set the httpd module as a whole to permissive rather
> > >> than fiddle around trying to A) set all of httpd's domains to permissive
> > >> and B) requiring a fairly significant amount of knowledge of the
> > >> security policy to know which domains may require this intervention.
> > >>
> > >> I think that per-domain permissive is probably useful for certain kinds
> > >> of policy development, but per-module permissive would be significantly
> > >> more useful for the work that I'm currently doing with SELinux.
> > > 
> > > So this suggests that the userland/policy approach is the better way to
> > > go than the kernel mechanism approach, as the former would provide the
> > > flexibility to turn on "permissive" behavior for all domains defined by
> > > a module more easily than the latter.  unconfined + auditallow, along
> > > with corresponding enhancements to audit2allow to select on avc granted.
> > > And possibly some way to enable/disable log-once behavior for avc
> > > grantings.
> > > 
> > I would rather give them globing capability, something like
> > 
> > setenforce -t http*=0
> > 
> > 
> > We do not separate everything out as per module and I think it is most
> > likely only a certain domain is causing the problem, that the user or
> > policy writer would be concerned with.
> > 
> > Steven, I don't see where you make the leap to this suggests a userland
> > approach versus the kernel.
> > 
> > for i in `sesearch --allow | grep transition | awk '{ print $2}' | sort
> > - -u | grep http`; do setenforce $i 0; done
> > 
> > setenforce in this example is either going to have to create a loadable
> > policy module with all the allow and auditallow rules for the domain and
> > load it, or a single newcommand to tell the kernel this domain is in
> > permissive mode.
> > 
> > Either way I don't care.  I just need it soon.
> 
> Userland/policy approach is more flexible (per-domain, per-module,
> matches domain prefix, ...) and lets you switch multiple domains
> atomically between permissive and enforcing mode.  Kernel approach is
> more limiting and either requires separate commit node like booleans or
> won't support atomic transaction.

Or the 'some userspace some kernel' approach that I originally
suggested.  setenforce httpd* 0 could walk all of policy, set the
type_datum->primary flag appropiately on everything that matched and
then when that new policy was loaded the permissive changes would be
atomic.  Although using primary isn't exactly backwards compatible
either.  It would, however, put all the intelligence in
userspace/policy, generates denials instead of allows, solves the audit
log spam problem and stuff like that.
> 
> Also, userland/policy approach doesn't require a new kernel.  So it can
> work on existing distributions (including RHEL5).
> 


--
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: concept of a permissive domain

[Stephen Smalley]

On Mon, 2007-10-15 at 15:09 -0400, Eric Paris wrote:
> On Mon, 2007-10-15 at 14:40 -0400, Stephen Smalley wrote:
> > On Mon, 2007-10-15 at 14:32 -0400, Daniel J Walsh wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Stephen Smalley wrote:
> > > > On Mon, 2007-10-15 at 09:52 -0700, Brett Lentz wrote:
> > > >> On Mon, 2007-10-15 at 08:40 -0400, Daniel J Walsh wrote:
> > > >>>>> - From the user point of view we could change the setenforce command
> > > >>>>>
> > > >>>>> setenforce 0
> > > >>>>> setenforce httpd_t 0
> > > >>>>>
> > > >>>>> getenforce 0
> > > >>>>> getenforce httpd_t 0
> > > >>>>>
> > > >>>>> Then we could replace both to do something in semanage to rebuild and
> > > >>>>> reload policy.
> > > >>>> But that would mean e.g. consider apache that you would have to
> > > >>>> setenforce for every domain type?
> > > >>>>
> > > >>>> apache_t
> > > >>>> apache_helper_t
> > > >>>> apache_php_t
> > > >>>> httpd_rotatelogs_t
> > > >>>> httpd_suexec_t
> > > >>>> ...
> > > >>>>
> > > >>>> There wouldn't be a setenforce for a whole module, right?
> > > >>>>
> > > >>>> 	Stefan
> > > >>>>
> > > >>> Yes although it is doubtful you would have all of those running at the
> > > >>> same time.  (httpd_t and httpd_helper_t).
> > > >>>
> > > >>>
> > > >>> -----BEGIN PGP SIGNATURE-----
> > > >>> Version: GnuPG v1.4.7 (GNU/Linux)
> > > >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > > >>>
> > > >>> iD8DBQFHE1/NrlYvE4MpobMRAuiiAKDgSEfnJHsFI9R1nmvvPx6PrhuQ9QCeIQHh
> > > >>> p4+2X7ixDbvoxSyMjrReLCE=
> > > >>> =6X1D
> > > >>> -----END PGP SIGNATURE-----
> > > >>
> > > >> As an SELinux user, it makes the most sense to me for this capability to
> > > >> be accessible on a per-module basis rather than per-domain.
> > > >>
> > > >> I would much rather set the httpd module as a whole to permissive rather
> > > >> than fiddle around trying to A) set all of httpd's domains to permissive
> > > >> and B) requiring a fairly significant amount of knowledge of the
> > > >> security policy to know which domains may require this intervention.
> > > >>
> > > >> I think that per-domain permissive is probably useful for certain kinds
> > > >> of policy development, but per-module permissive would be significantly
> > > >> more useful for the work that I'm currently doing with SELinux.
> > > > 
> > > > So this suggests that the userland/policy approach is the better way to
> > > > go than the kernel mechanism approach, as the former would provide the
> > > > flexibility to turn on "permissive" behavior for all domains defined by
> > > > a module more easily than the latter.  unconfined + auditallow, along
> > > > with corresponding enhancements to audit2allow to select on avc granted.
> > > > And possibly some way to enable/disable log-once behavior for avc
> > > > grantings.
> > > > 
> > > I would rather give them globing capability, something like
> > > 
> > > setenforce -t http*=0
> > > 
> > > 
> > > We do not separate everything out as per module and I think it is most
> > > likely only a certain domain is causing the problem, that the user or
> > > policy writer would be concerned with.
> > > 
> > > Steven, I don't see where you make the leap to this suggests a userland
> > > approach versus the kernel.
> > > 
> > > for i in `sesearch --allow | grep transition | awk '{ print $2}' | sort
> > > - -u | grep http`; do setenforce $i 0; done
> > > 
> > > setenforce in this example is either going to have to create a loadable
> > > policy module with all the allow and auditallow rules for the domain and
> > > load it, or a single newcommand to tell the kernel this domain is in
> > > permissive mode.
> > > 
> > > Either way I don't care.  I just need it soon.
> > 
> > Userland/policy approach is more flexible (per-domain, per-module,
> > matches domain prefix, ...) and lets you switch multiple domains
> > atomically between permissive and enforcing mode.  Kernel approach is
> > more limiting and either requires separate commit node like booleans or
> > won't support atomic transaction.
> 
> Or the 'some userspace some kernel' approach that I originally
> suggested.  setenforce httpd* 0 could walk all of policy, set the
> type_datum->primary flag appropiately on everything that matched and
> then when that new policy was loaded the permissive changes would be
> atomic.  Although using primary isn't exactly backwards compatible
> either.  It would, however, put all the intelligence in
> userspace/policy, generates denials instead of allows, solves the audit
> log spam problem and stuff like that.

Fine, let's proceed that way then.

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

Recurring SELinux events for similar violations...

[Hasan Rezaul-CHR010]

Hi All,

I am using a Fedora 6 STRICT policy as my base, and have written some
additional custom policies on top.

For example, I have allowed certain domains (e.g. staff_t) to modify
file types of  etc_t
And I have disallowed other domains (e.g. user_t) to modify file types
of etc_t.

When user_t makes the first attempt to modify an etc_t file, I do get
DENY events  :-)

But subsequent attempts by user_t to modify etc_t files  *DO NOT*
generate any more events ?!?

- Is this by design ??? 

- Is there something I can do such that  EVERY time user_t  attempts to
modify a file type etc_t , I will get a corresponding DENY ?

- In other words, I would like every violation attempt to be reported in
the audit.log file, even if the same violation occurs multiple times in
the same session.

Thanks in advance,

- Rezaul.


--
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: Recurring SELinux events for similar violations...

[Eric Paris]

Are you running without enforcing just for testing?  When you turn off
enforcing it only logs once (by design) but I think it should log the
denial every single time in enforcing mode.

-Eric

On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> Hi All,
>
> I am using a Fedora 6 STRICT policy as my base, and have written some
> additional custom policies on top.
>
> For example, I have allowed certain domains (e.g. staff_t) to modify
> file types of  etc_t
> And I have disallowed other domains (e.g. user_t) to modify file types
> of etc_t.
>
> When user_t makes the first attempt to modify an etc_t file, I do get
> DENY events  :-)
>
> But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> generate any more events ?!?
>
> - Is this by design ???
>
> - Is there something I can do such that  EVERY time user_t  attempts to
> modify a file type etc_t , I will get a corresponding DENY ?
>
> - In other words, I would like every violation attempt to be reported in
> the audit.log file, even if the same violation occurs multiple times in
> the same session.
>
> Thanks in advance,
>
> - Rezaul.
>
>
> --
> 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.
>

--
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: Recurring SELinux events for similar violations...

[Hasan Rezaul-CHR010]

Yes, I am running in "Permissive" mode right now, just for testing
purposes.

If this is by design, is there any way I can force SELinux to log every
denial even in Permissive mode ?

Thanks,

- Rezaul.
  

-----Original Message-----
From: Eric Paris [mailto:eparis@parisplace.org] 
Sent: Wednesday, October 17, 2007 5:19 PM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
Subject: Re: Recurring SELinux events for similar violations...

Are you running without enforcing just for testing?  When you turn off
enforcing it only logs once (by design) but I think it should log the
denial every single time in enforcing mode.

-Eric

On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> Hi All,
>
> I am using a Fedora 6 STRICT policy as my base, and have written some
> additional custom policies on top.
>
> For example, I have allowed certain domains (e.g. staff_t) to modify
> file types of  etc_t
> And I have disallowed other domains (e.g. user_t) to modify file types
> of etc_t.
>
> When user_t makes the first attempt to modify an etc_t file, I do get
> DENY events  :-)
>
> But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> generate any more events ?!?
>
> - Is this by design ???
>
> - Is there something I can do such that  EVERY time user_t  attempts
to
> modify a file type etc_t , I will get a corresponding DENY ?
>
> - In other words, I would like every violation attempt to be reported
in
> the audit.log file, even if the same violation occurs multiple times
in
> the same session.
>
> Thanks in advance,
>
> - Rezaul.
>
>
> --
> 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.
>


--
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: Recurring SELinux events for similar violations...

[Stephen Smalley]

On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> Yes, I am running in "Permissive" mode right now, just for testing
> purposes.
> 
> If this is by design, is there any way I can force SELinux to log every
> denial even in Permissive mode ?

It is by design, as otherwise you could end up with an unending stream
of duplicate denials since the application will keep on processing
(since the denials are not enforced), and thus flood the audit system
and logs with redundant information.

However, the denial will re-appear if the AVC entry is evicted.  You can
manually flush the AVC by:
- toggling enforcing mode (e.g. setenforce 1; setenforce 0),
- setting a boolean (e.g. setsebool <somebool>=<somevalue>),
- reloading policy (e.g. /usr/sbin/load_policy)

Or you should be able to effectively turn off caching by setting the
cache threshold down (performance will naturally suffer as a result):
echo 0 > /selinux/avc/cache_threshold
cat /selinux/avc/cache_threshold


> Thanks,
> 
> - Rezaul.
>   
> 
> -----Original Message-----
> From: Eric Paris [mailto:eparis@parisplace.org] 
> Sent: Wednesday, October 17, 2007 5:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: Re: Recurring SELinux events for similar violations...
> 
> Are you running without enforcing just for testing?  When you turn off
> enforcing it only logs once (by design) but I think it should log the
> denial every single time in enforcing mode.
> 
> -Eric
> 
> On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > Hi All,
> >
> > I am using a Fedora 6 STRICT policy as my base, and have written some
> > additional custom policies on top.
> >
> > For example, I have allowed certain domains (e.g. staff_t) to modify
> > file types of  etc_t
> > And I have disallowed other domains (e.g. user_t) to modify file types
> > of etc_t.
> >
> > When user_t makes the first attempt to modify an etc_t file, I do get
> > DENY events  :-)
> >
> > But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> > generate any more events ?!?
> >
> > - Is this by design ???
> >
> > - Is there something I can do such that  EVERY time user_t  attempts
> to
> > modify a file type etc_t , I will get a corresponding DENY ?
> >
> > - In other words, I would like every violation attempt to be reported
> in
> > the audit.log file, even if the same violation occurs multiple times
> in
> > the same session.
> >
> > Thanks in advance,
> >
> > - Rezaul.
> >
> >
> > --
> > 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.
> >
> 
> 
> --
> 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.
-- 
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: Recurring SELinux events for similar violations...

[Hasan Rezaul-CHR010]

Great.

Thanks a bunch !

- Reza.
 

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Thursday, October 18, 2007 8:14 AM
To: Hasan Rezaul-CHR010
Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Recurring SELinux events for similar violations...

On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> Yes, I am running in "Permissive" mode right now, just for testing
> purposes.
> 
> If this is by design, is there any way I can force SELinux to log
every
> denial even in Permissive mode ?

It is by design, as otherwise you could end up with an unending stream
of duplicate denials since the application will keep on processing
(since the denials are not enforced), and thus flood the audit system
and logs with redundant information.

However, the denial will re-appear if the AVC entry is evicted.  You can
manually flush the AVC by:
- toggling enforcing mode (e.g. setenforce 1; setenforce 0),
- setting a boolean (e.g. setsebool <somebool>=<somevalue>),
- reloading policy (e.g. /usr/sbin/load_policy)

Or you should be able to effectively turn off caching by setting the
cache threshold down (performance will naturally suffer as a result):
echo 0 > /selinux/avc/cache_threshold
cat /selinux/avc/cache_threshold


> Thanks,
> 
> - Rezaul.
>   
> 
> -----Original Message-----
> From: Eric Paris [mailto:eparis@parisplace.org] 
> Sent: Wednesday, October 17, 2007 5:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: Re: Recurring SELinux events for similar violations...
> 
> Are you running without enforcing just for testing?  When you turn off
> enforcing it only logs once (by design) but I think it should log the
> denial every single time in enforcing mode.
> 
> -Eric
> 
> On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > Hi All,
> >
> > I am using a Fedora 6 STRICT policy as my base, and have written
some
> > additional custom policies on top.
> >
> > For example, I have allowed certain domains (e.g. staff_t) to modify
> > file types of  etc_t
> > And I have disallowed other domains (e.g. user_t) to modify file
types
> > of etc_t.
> >
> > When user_t makes the first attempt to modify an etc_t file, I do
get
> > DENY events  :-)
> >
> > But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> > generate any more events ?!?
> >
> > - Is this by design ???
> >
> > - Is there something I can do such that  EVERY time user_t  attempts
> to
> > modify a file type etc_t , I will get a corresponding DENY ?
> >
> > - In other words, I would like every violation attempt to be
reported
> in
> > the audit.log file, even if the same violation occurs multiple times
> in
> > the same session.
> >
> > Thanks in advance,
> >
> > - Rezaul.
> >
> >
> > --
> > 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.
> >
> 
> 
> --
> 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.
-- 
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: Recurring SELinux events for similar violations...

[Hasan Rezaul-CHR010]

Hi All,

So here is my problem statement:

While running in "Permissive" Mode, and keeping the
/selinux/avc/cache_threshold at the default 512 value, is there any
*other* way to make sure that  EVERY  SELinux violation attempt still
automatically gets logged into the audit.log file ???

Currently, while running in "Permissive" mode, and with the default
cache_threshold value of 512:

- if a violation is attempted, I see a deny event only once in the
audit.log file ! Successive violation attempts within the same session
are NOT logged in the audit.log file  :(  I need to get a DENY for every
violation attempt during runtime !

- When I run in "Enforcing" mode, every single violation does get logged
in the audit.log file. But at this time, lets just say I CANT afford to
run in Enforcing mode ! I must run in Permissive mode for now !

- If I change the cache_threshold to 0, every single violation attempt
does get logged, but I also get some other useless frequent periodic
violations. Besides, it seems to have performance impacts of course...

Therefore, I am looking for any other good way to generate a deny in the
audit.log for every violation attempt. But I cant change to Enforcing,
and I would prefer not to modify the cache_threshold.

Please help. Thanks,

- Rezaul.


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Thursday, October 18, 2007 8:14 AM
To: Hasan Rezaul-CHR010
Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Recurring SELinux events for similar violations...

On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> Yes, I am running in "Permissive" mode right now, just for testing
> purposes.
> 
> If this is by design, is there any way I can force SELinux to log
every
> denial even in Permissive mode ?

It is by design, as otherwise you could end up with an unending stream
of duplicate denials since the application will keep on processing
(since the denials are not enforced), and thus flood the audit system
and logs with redundant information.

However, the denial will re-appear if the AVC entry is evicted.  You can
manually flush the AVC by:
- toggling enforcing mode (e.g. setenforce 1; setenforce 0),
- setting a boolean (e.g. setsebool <somebool>=<somevalue>),
- reloading policy (e.g. /usr/sbin/load_policy)

Or you should be able to effectively turn off caching by setting the
cache threshold down (performance will naturally suffer as a result):
echo 0 > /selinux/avc/cache_threshold
cat /selinux/avc/cache_threshold


> Thanks,
> 
> - Rezaul.
>   
> 
> -----Original Message-----
> From: Eric Paris [mailto:eparis@parisplace.org] 
> Sent: Wednesday, October 17, 2007 5:19 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: Re: Recurring SELinux events for similar violations...
> 
> Are you running without enforcing just for testing?  When you turn off
> enforcing it only logs once (by design) but I think it should log the
> denial every single time in enforcing mode.
> 
> -Eric
> 
> On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > Hi All,
> >
> > I am using a Fedora 6 STRICT policy as my base, and have written
some
> > additional custom policies on top.
> >
> > For example, I have allowed certain domains (e.g. staff_t) to modify
> > file types of  etc_t
> > And I have disallowed other domains (e.g. user_t) to modify file
types
> > of etc_t.
> >
> > When user_t makes the first attempt to modify an etc_t file, I do
get
> > DENY events  :-)
> >
> > But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> > generate any more events ?!?
> >
> > - Is this by design ???
> >
> > - Is there something I can do such that  EVERY time user_t  attempts
> to
> > modify a file type etc_t , I will get a corresponding DENY ?
> >
> > - In other words, I would like every violation attempt to be
reported
> in
> > the audit.log file, even if the same violation occurs multiple times
> in
> > the same session.
> >
> > Thanks in advance,
> >
> > - Rezaul.
> >
> >
> > --
> > 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.
> >
> 
> 
> --
> 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.
-- 
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: Recurring SELinux events for similar violations...

[Stephen Smalley]

On Thu, 2007-11-29 at 15:06 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> So here is my problem statement:
> 
> While running in "Permissive" Mode, and keeping the
> /selinux/avc/cache_threshold at the default 512 value, is there any
> *other* way to make sure that  EVERY  SELinux violation attempt still
> automatically gets logged into the audit.log file ???

Not without patching your kernel, no.  I already explained your options
here.

> Currently, while running in "Permissive" mode, and with the default
> cache_threshold value of 512:
> 
> - if a violation is attempted, I see a deny event only once in the
> audit.log file ! Successive violation attempts within the same session
> are NOT logged in the audit.log file  :(  I need to get a DENY for every
> violation attempt during runtime !

Why?  You are already getting one instance of each distinct denial, i.e.
each denial on a different (scontext, tcontext, tclass, permissions)
quadruple will appear exactly once, which is all you need in order to
create allow rules.  Repeating those messages won't yield any more allow
rules, and it does have a cost - it commonly leads to audit flooding and
making the system unusable.

> - When I run in "Enforcing" mode, every single violation does get logged
> in the audit.log file. But at this time, lets just say I CANT afford to
> run in Enforcing mode ! I must run in Permissive mode for now !

Ok, fine.

> - If I change the cache_threshold to 0, every single violation attempt
> does get logged, but I also get some other useless frequent periodic
> violations. Besides, it seems to have performance impacts of course...

I don't understand.  This gives you the behavior you want, but what are
these "useless frequent periodic violations" and why don't you want them
- you just said you wanted every denial.  And yes, there will be a
performance impact, but if you are doing policy development, that
shouldn't matter, and performance testing should always happen _after_
constructing a working policy and moving into enforcing mode.

> Therefore, I am looking for any other good way to generate a deny in the
> audit.log for every violation attempt. But I cant change to Enforcing,
> and I would prefer not to modify the cache_threshold.
> 
> Please help. Thanks,
> 
> - Rezaul.
> 
> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Thursday, October 18, 2007 8:14 AM
> To: Hasan Rezaul-CHR010
> Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: RE: Recurring SELinux events for similar violations...
> 
> On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> > Yes, I am running in "Permissive" mode right now, just for testing
> > purposes.
> > 
> > If this is by design, is there any way I can force SELinux to log
> every
> > denial even in Permissive mode ?
> 
> It is by design, as otherwise you could end up with an unending stream
> of duplicate denials since the application will keep on processing
> (since the denials are not enforced), and thus flood the audit system
> and logs with redundant information.
> 
> However, the denial will re-appear if the AVC entry is evicted.  You can
> manually flush the AVC by:
> - toggling enforcing mode (e.g. setenforce 1; setenforce 0),
> - setting a boolean (e.g. setsebool <somebool>=<somevalue>),
> - reloading policy (e.g. /usr/sbin/load_policy)
> 
> Or you should be able to effectively turn off caching by setting the
> cache threshold down (performance will naturally suffer as a result):
> echo 0 > /selinux/avc/cache_threshold
> cat /selinux/avc/cache_threshold
> 
> 
> > Thanks,
> > 
> > - Rezaul.
> >   
> > 
> > -----Original Message-----
> > From: Eric Paris [mailto:eparis@parisplace.org] 
> > Sent: Wednesday, October 17, 2007 5:19 PM
> > To: Hasan Rezaul-CHR010
> > Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> > Subject: Re: Recurring SELinux events for similar violations...
> > 
> > Are you running without enforcing just for testing?  When you turn off
> > enforcing it only logs once (by design) but I think it should log the
> > denial every single time in enforcing mode.
> > 
> > -Eric
> > 
> > On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > > Hi All,
> > >
> > > I am using a Fedora 6 STRICT policy as my base, and have written
> some
> > > additional custom policies on top.
> > >
> > > For example, I have allowed certain domains (e.g. staff_t) to modify
> > > file types of  etc_t
> > > And I have disallowed other domains (e.g. user_t) to modify file
> types
> > > of etc_t.
> > >
> > > When user_t makes the first attempt to modify an etc_t file, I do
> get
> > > DENY events  :-)
> > >
> > > But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> > > generate any more events ?!?
> > >
> > > - Is this by design ???
> > >
> > > - Is there something I can do such that  EVERY time user_t  attempts
> > to
> > > modify a file type etc_t , I will get a corresponding DENY ?
> > >
> > > - In other words, I would like every violation attempt to be
> reported
> > in
> > > the audit.log file, even if the same violation occurs multiple times
> > in
> > > the same session.
> > >
> > > Thanks in advance,
> > >
> > > - Rezaul.
> > >
> > >
> > > --
> > > 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.
> > >
> > 
> > 
> > --
> > 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.
-- 
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: Recurring SELinux events for similar violations...

[Hasan Rezaul-CHR010]

Hi Stephen,

Thanks as always for your response  :-)

I have already created a set of allow rules necessary. So we're using
SELinux is to capture info about EVERY attempt an unauthorized/rogue
user makes to access something they're NOT supposed to! So the reason I
want to see the DENY events in audit.log, is *NOT* for creating
corresponding allow rules. 

The "frequent periodic violation" I was referring to is as follows:

type=AVC msg=audit(1196369398.427:126): avc:  denied  { read } for
pid=1040 com
m="klogd" name="kmsg" dev=proc ino=-268435446
scontext=system_u:system_r:kernel_
t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file

With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
audit.log every second !  I would like to create an allow rule, to get
rid of this event. When I used audit2allow to generate the allow rule, I
got:

allow kernel_t proc_kmsg_t:file read


However, the base policy I am using as my starting policy is the
*STRICT* Fedora Core 6 policy. And with that in place, when I try to
insert this allow rule using (semodule -i myPolicy.pp), I get an
assertion failure for that allow rule!!! So seems like the base policy
wont let me insert this allow rule  :-(

So that is my dilemma.
With cache_threshold = 0,  I get all the denies I want to see. But I
also get these extra denies that I cant get rid off  :-(

- Rezaul. 


-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On Behalf Of Stephen Smalley
Sent: Thursday, November 29, 2007 2:17 PM
To: Hasan Rezaul-CHR010
Cc: Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Recurring SELinux events for similar violations...

On Thu, 2007-11-29 at 15:06 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> So here is my problem statement:
> 
> While running in "Permissive" Mode, and keeping the
> /selinux/avc/cache_threshold at the default 512 value, is there any
> *other* way to make sure that  EVERY  SELinux violation attempt still
> automatically gets logged into the audit.log file ???

Not without patching your kernel, no.  I already explained your options
here.

> Currently, while running in "Permissive" mode, and with the default
> cache_threshold value of 512:
> 
> - if a violation is attempted, I see a deny event only once in the
> audit.log file ! Successive violation attempts within the same session
> are NOT logged in the audit.log file  :(  I need to get a DENY for
every
> violation attempt during runtime !

Why?  You are already getting one instance of each distinct denial, i.e.
each denial on a different (scontext, tcontext, tclass, permissions)
quadruple will appear exactly once, which is all you need in order to
create allow rules.  Repeating those messages won't yield any more allow
rules, and it does have a cost - it commonly leads to audit flooding and
making the system unusable.

> - When I run in "Enforcing" mode, every single violation does get
logged
> in the audit.log file. But at this time, lets just say I CANT afford
to
> run in Enforcing mode ! I must run in Permissive mode for now !

Ok, fine.

> - If I change the cache_threshold to 0, every single violation attempt
> does get logged, but I also get some other useless frequent periodic
> violations. Besides, it seems to have performance impacts of course...

I don't understand.  This gives you the behavior you want, but what are
these "useless frequent periodic violations" and why don't you want them
- you just said you wanted every denial.  And yes, there will be a
performance impact, but if you are doing policy development, that
shouldn't matter, and performance testing should always happen _after_
constructing a working policy and moving into enforcing mode.

> Therefore, I am looking for any other good way to generate a deny in
the
> audit.log for every violation attempt. But I cant change to Enforcing,
> and I would prefer not to modify the cache_threshold.
> 
> Please help. Thanks,
> 
> - Rezaul.
> 
> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Thursday, October 18, 2007 8:14 AM
> To: Hasan Rezaul-CHR010
> Cc: Eric Paris; Daniel J Walsh; selinux@tycho.nsa.gov
> Subject: RE: Recurring SELinux events for similar violations...
> 
> On Wed, 2007-10-17 at 18:22 -0400, Hasan Rezaul-CHR010 wrote:
> > Yes, I am running in "Permissive" mode right now, just for testing
> > purposes.
> > 
> > If this is by design, is there any way I can force SELinux to log
> every
> > denial even in Permissive mode ?
> 
> It is by design, as otherwise you could end up with an unending stream
> of duplicate denials since the application will keep on processing
> (since the denials are not enforced), and thus flood the audit system
> and logs with redundant information.
> 
> However, the denial will re-appear if the AVC entry is evicted.  You
can
> manually flush the AVC by:
> - toggling enforcing mode (e.g. setenforce 1; setenforce 0),
> - setting a boolean (e.g. setsebool <somebool>=<somevalue>),
> - reloading policy (e.g. /usr/sbin/load_policy)
> 
> Or you should be able to effectively turn off caching by setting the
> cache threshold down (performance will naturally suffer as a result):
> echo 0 > /selinux/avc/cache_threshold
> cat /selinux/avc/cache_threshold
> 
> 
> > Thanks,
> > 
> > - Rezaul.
> >   
> > 
> > -----Original Message-----
> > From: Eric Paris [mailto:eparis@parisplace.org] 
> > Sent: Wednesday, October 17, 2007 5:19 PM
> > To: Hasan Rezaul-CHR010
> > Cc: Stephen Smalley; Daniel J Walsh; selinux@tycho.nsa.gov
> > Subject: Re: Recurring SELinux events for similar violations...
> > 
> > Are you running without enforcing just for testing?  When you turn
off
> > enforcing it only logs once (by design) but I think it should log
the
> > denial every single time in enforcing mode.
> > 
> > -Eric
> > 
> > On 10/17/07, Hasan Rezaul-CHR010 <CHR010@motorola.com> wrote:
> > > Hi All,
> > >
> > > I am using a Fedora 6 STRICT policy as my base, and have written
> some
> > > additional custom policies on top.
> > >
> > > For example, I have allowed certain domains (e.g. staff_t) to
modify
> > > file types of  etc_t
> > > And I have disallowed other domains (e.g. user_t) to modify file
> types
> > > of etc_t.
> > >
> > > When user_t makes the first attempt to modify an etc_t file, I do
> get
> > > DENY events  :-)
> > >
> > > But subsequent attempts by user_t to modify etc_t files  *DO NOT*
> > > generate any more events ?!?
> > >
> > > - Is this by design ???
> > >
> > > - Is there something I can do such that  EVERY time user_t
attempts
> > to
> > > modify a file type etc_t , I will get a corresponding DENY ?
> > >
> > > - In other words, I would like every violation attempt to be
> reported
> > in
> > > the audit.log file, even if the same violation occurs multiple
times
> > in
> > > the same session.
> > >
> > > Thanks in advance,
> > >
> > > - Rezaul.
> > >
> > >
> > > --
> > > 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.
> > >
> > 
> > 
> > --
> > 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.
-- 
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.


--
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: Recurring SELinux events for similar violations...

[Stephen Smalley]

On Thu, 2007-11-29 at 16:26 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Stephen,
> 
> Thanks as always for your response  :-)
> 
> I have already created a set of allow rules necessary. So we're using
> SELinux is to capture info about EVERY attempt an unauthorized/rogue
> user makes to access something they're NOT supposed to! So the reason I
> want to see the DENY events in audit.log, is *NOT* for creating
> corresponding allow rules. 
> 
> The "frequent periodic violation" I was referring to is as follows:
> 
> type=AVC msg=audit(1196369398.427:126): avc:  denied  { read } for
> pid=1040 com
> m="klogd" name="kmsg" dev=proc ino=-268435446
> scontext=system_u:system_r:kernel_
> t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file

So you never transitioned out of kernel_t (initial kernel task and
kernel threads) into appropriate domains for userland (starting with a
transition to init_t upon /sbin/init, init_exec_t).  Normally klogd
would run in klogd_t, and the above would be allowed by policy.

> With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
> audit.log every second !  I would like to create an allow rule, to get
> rid of this event. When I used audit2allow to generate the allow rule, I
> got:
> 
> allow kernel_t proc_kmsg_t:file read
> 
> 
> However, the base policy I am using as my starting policy is the
> *STRICT* Fedora Core 6 policy. And with that in place, when I try to
> insert this allow rule using (semodule -i myPolicy.pp), I get an
> assertion failure for that allow rule!!! So seems like the base policy
> wont let me insert this allow rule  :-(

Which is good, because it indicates a more fundamental problem - you've
got a mislabeled klogd process.

But suppose that wasn't the case and you truly wanted to allow that.
Here is how you would do it:
1) Look for a refpolicy interface that grants access to kmsg.  In a
modern policy, that appears to be kernel_read_messages().  Then write
your policy module using that interface, ala:
$ vi myklogd.te
policy_module(myklogd, 1.0)
require {
	type kernel_t;
}
kernel_read_messages(kernel_t)
:wq
$ make -f /usr/share/selinux/devel/Makefile
$ su
# /usr/sbin/semodule -i myklogd.pp

The refpolicy interface contains the 'magic' needed to override this
assertion, namely adding an attribute to the kernel_t type.  This
ensures that you made a conscious decision to give access to this
security-relevant resource and didn't accidentally do it via
audit2allow.

-or-
2) Disable assertion checking by libsemanage (not recommended, mostly
for developers, but if you need it, it exists):
$ su 
# vi /etc/selinux/semanage.conf
:$
i
expand-check=0
:wq

> So that is my dilemma.
> With cache_threshold = 0,  I get all the denies I want to see. But I
> also get these extra denies that I cant get rid off  :-(

-- 
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: Recurring SELinux events for similar violations...

[Stephen Smalley]

On Thu, 2007-11-29 at 16:32 -0500, Stephen Smalley wrote:
> On Thu, 2007-11-29 at 16:26 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi Stephen,
> > 
> > Thanks as always for your response  :-)
> > 
> > I have already created a set of allow rules necessary. So we're using
> > SELinux is to capture info about EVERY attempt an unauthorized/rogue
> > user makes to access something they're NOT supposed to! So the reason I
> > want to see the DENY events in audit.log, is *NOT* for creating
> > corresponding allow rules. 
> > 
> > The "frequent periodic violation" I was referring to is as follows:
> > 
> > type=AVC msg=audit(1196369398.427:126): avc:  denied  { read } for
> > pid=1040 com
> > m="klogd" name="kmsg" dev=proc ino=-268435446
> > scontext=system_u:system_r:kernel_
> > t:s0 tcontext=system_u:object_r:proc_kmsg_t:s0 tclass=file
> 
> So you never transitioned out of kernel_t (initial kernel task and
> kernel threads) into appropriate domains for userland (starting with a
> transition to init_t upon /sbin/init, init_exec_t).  Normally klogd
> would run in klogd_t, and the above would be allowed by policy.
> 
> > With [ /avc/cache_threshold = 0 ], the above event keeps popping up in
> > audit.log every second !  I would like to create an allow rule, to get
> > rid of this event. When I used audit2allow to generate the allow rule, I
> > got:
> > 
> > allow kernel_t proc_kmsg_t:file read
> > 
> > 
> > However, the base policy I am using as my starting policy is the
> > *STRICT* Fedora Core 6 policy. And with that in place, when I try to
> > insert this allow rule using (semodule -i myPolicy.pp), I get an
> > assertion failure for that allow rule!!! So seems like the base policy
> > wont let me insert this allow rule  :-(
> 
> Which is good, because it indicates a more fundamental problem - you've
> got a mislabeled klogd process.
> 
> But suppose that wasn't the case and you truly wanted to allow that.
> Here is how you would do it:
> 1) Look for a refpolicy interface that grants access to kmsg.  In a
> modern policy, that appears to be kernel_read_messages().  Then write
> your policy module using that interface, ala:
> $ vi myklogd.te
> policy_module(myklogd, 1.0)
> require {
> 	type kernel_t;
> }
> kernel_read_messages(kernel_t)
> :wq
> $ make -f /usr/share/selinux/devel/Makefile
> $ su
> # /usr/sbin/semodule -i myklogd.pp
> 
> The refpolicy interface contains the 'magic' needed to override this
> assertion, namely adding an attribute to the kernel_t type.  This
> ensures that you made a conscious decision to give access to this
> security-relevant resource and didn't accidentally do it via
> audit2allow.
> 
> -or-
> 2) Disable assertion checking by libsemanage (not recommended, mostly
> for developers, but if you need it, it exists):
> $ su 
> # vi /etc/selinux/semanage.conf
> :$
> i
> expand-check=0
> :wq
> 
> > So that is my dilemma.
> > With cache_threshold = 0,  I get all the denies I want to see. But I
> > also get these extra denies that I cant get rid off  :-(

Also, it would be very simple to patch your kernel to not have this
behavior in permissive mode if you truly wanted that.  Just look in
linux-2.6/security/selinux/avc.c in the avc_has_perm_noaudit() function,
and remove where it calls avc_update_node(AVC_CALLBACK_GRANT...).  Then
it won't add those permissions to the cached entry, and it will keep
auditing them every time.  I suppose we could make that
configurable/tunable in future kernels if there is a real demand for it.

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