* Re: concept of a permissive domain
2007-09-18 20:24 ` Stephen Smalley
@ 2007-09-18 20:50 ` Joshua Brindle
2007-09-18 21:54 ` Chad Sellers
2007-09-24 14:59 ` Karl MacMillan
2 siblings, 0 replies; 71+ messages in thread
From: Joshua Brindle @ 2007-09-18 20:50 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Eric Paris, Daniel J Walsh, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-18 20:24 ` Stephen Smalley
2007-09-18 20:50 ` Joshua Brindle
@ 2007-09-18 21:54 ` Chad Sellers
2007-09-19 12:56 ` Daniel J Walsh
2007-09-19 16:35 ` Martin Orr
2007-09-24 14:59 ` Karl MacMillan
2 siblings, 2 replies; 71+ messages in thread
From: Chad Sellers @ 2007-09-18 21:54 UTC (permalink / raw)
To: Stephen Smalley, Eric Paris; +Cc: Daniel J Walsh, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-18 21:54 ` Chad Sellers
@ 2007-09-19 12:56 ` Daniel J Walsh
2007-09-19 14:22 ` Chad Sellers
2007-10-12 13:50 ` Daniel J Walsh
2007-09-19 16:35 ` Martin Orr
1 sibling, 2 replies; 71+ messages in thread
From: Daniel J Walsh @ 2007-09-19 12:56 UTC (permalink / raw)
To: Chad Sellers; +Cc: Stephen Smalley, Eric Paris, Karl MacMillan, selinux
-----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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-19 12:56 ` Daniel J Walsh
@ 2007-09-19 14:22 ` Chad Sellers
2007-10-12 13:50 ` Daniel J Walsh
1 sibling, 0 replies; 71+ messages in thread
From: Chad Sellers @ 2007-09-19 14:22 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, Eric Paris, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-19 12:56 ` Daniel J Walsh
2007-09-19 14:22 ` Chad Sellers
@ 2007-10-12 13:50 ` Daniel J Walsh
2007-10-12 17:49 ` Joshua Brindle
2007-10-12 18:40 ` Chad Sellers
1 sibling, 2 replies; 71+ messages in thread
From: Daniel J Walsh @ 2007-10-12 13:50 UTC (permalink / raw)
To: Chad Sellers; +Cc: Stephen Smalley, Eric Paris, Karl MacMillan, selinux
-----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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 13:50 ` Daniel J Walsh
@ 2007-10-12 17:49 ` Joshua Brindle
2007-10-12 18:07 ` Eric Paris
2007-10-12 18:40 ` Chad Sellers
1 sibling, 1 reply; 71+ messages in thread
From: Joshua Brindle @ 2007-10-12 17:49 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Chad Sellers, Stephen Smalley, Eric Paris, Karl MacMillan,
selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 17:49 ` Joshua Brindle
@ 2007-10-12 18:07 ` Eric Paris
2007-10-12 19:03 ` Karl MacMillan
0 siblings, 1 reply; 71+ messages in thread
From: Eric Paris @ 2007-10-12 18:07 UTC (permalink / raw)
To: Joshua Brindle
Cc: Daniel J Walsh, Chad Sellers, Stephen Smalley, Eric Paris,
Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 18:07 ` Eric Paris
@ 2007-10-12 19:03 ` Karl MacMillan
2007-10-12 19:09 ` Stephen Smalley
0 siblings, 1 reply; 71+ messages in thread
From: Karl MacMillan @ 2007-10-12 19:03 UTC (permalink / raw)
To: Eric Paris
Cc: Joshua Brindle, Daniel J Walsh, Chad Sellers, Stephen Smalley,
Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 19:03 ` Karl MacMillan
@ 2007-10-12 19:09 ` Stephen Smalley
0 siblings, 0 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-10-12 19:09 UTC (permalink / raw)
To: Karl MacMillan
Cc: Eric Paris, Joshua Brindle, Daniel J Walsh, Chad Sellers,
Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 13:50 ` Daniel J Walsh
2007-10-12 17:49 ` Joshua Brindle
@ 2007-10-12 18:40 ` Chad Sellers
2007-10-12 19:05 ` Karl MacMillan
2007-10-12 19:07 ` Stephen Smalley
1 sibling, 2 replies; 71+ messages in thread
From: Chad Sellers @ 2007-10-12 18:40 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, Eric Paris, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 18:40 ` Chad Sellers
@ 2007-10-12 19:05 ` Karl MacMillan
2007-10-12 20:43 ` Chad Sellers
2007-10-12 19:07 ` Stephen Smalley
1 sibling, 1 reply; 71+ messages in thread
From: Karl MacMillan @ 2007-10-12 19:05 UTC (permalink / raw)
To: Chad Sellers; +Cc: Daniel J Walsh, Stephen Smalley, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 19:05 ` Karl MacMillan
@ 2007-10-12 20:43 ` Chad Sellers
2007-10-12 21:01 ` Stephen Smalley
2007-10-12 21:21 ` Karl MacMillan
0 siblings, 2 replies; 71+ messages in thread
From: Chad Sellers @ 2007-10-12 20:43 UTC (permalink / raw)
To: Karl MacMillan; +Cc: Daniel J Walsh, Stephen Smalley, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 20:43 ` Chad Sellers
@ 2007-10-12 21:01 ` Stephen Smalley
2007-10-12 21:21 ` Karl MacMillan
1 sibling, 0 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-10-12 21:01 UTC (permalink / raw)
To: Chad Sellers; +Cc: Karl MacMillan, Daniel J Walsh, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 20:43 ` Chad Sellers
2007-10-12 21:01 ` Stephen Smalley
@ 2007-10-12 21:21 ` Karl MacMillan
2007-10-12 23:38 ` Chad Sellers
1 sibling, 1 reply; 71+ messages in thread
From: Karl MacMillan @ 2007-10-12 21:21 UTC (permalink / raw)
To: Chad Sellers; +Cc: Daniel J Walsh, Stephen Smalley, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 21:21 ` Karl MacMillan
@ 2007-10-12 23:38 ` Chad Sellers
2007-10-13 13:38 ` Daniel J Walsh
0 siblings, 1 reply; 71+ messages in thread
From: Chad Sellers @ 2007-10-12 23:38 UTC (permalink / raw)
To: Karl MacMillan; +Cc: Daniel J Walsh, Stephen Smalley, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 23:38 ` Chad Sellers
@ 2007-10-13 13:38 ` Daniel J Walsh
2007-10-14 10:14 ` Stefan Schulze Frielinghaus
0 siblings, 1 reply; 71+ messages in thread
From: Daniel J Walsh @ 2007-10-13 13:38 UTC (permalink / raw)
To: Chad Sellers; +Cc: Karl MacMillan, Stephen Smalley, Eric Paris, selinux
-----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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-13 13:38 ` Daniel J Walsh
@ 2007-10-14 10:14 ` Stefan Schulze Frielinghaus
2007-10-15 12:40 ` Daniel J Walsh
0 siblings, 1 reply; 71+ messages in thread
From: Stefan Schulze Frielinghaus @ 2007-10-14 10:14 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Chad Sellers, Karl MacMillan, Stephen Smalley, Eric Paris,
selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-14 10:14 ` Stefan Schulze Frielinghaus
@ 2007-10-15 12:40 ` Daniel J Walsh
2007-10-15 16:52 ` Brett Lentz
0 siblings, 1 reply; 71+ messages in thread
From: Daniel J Walsh @ 2007-10-15 12:40 UTC (permalink / raw)
To: Stefan Schulze Frielinghaus
Cc: Chad Sellers, Karl MacMillan, Stephen Smalley, Eric Paris,
selinux
-----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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-15 12:40 ` Daniel J Walsh
@ 2007-10-15 16:52 ` Brett Lentz
2007-10-15 16:58 ` Stephen Smalley
2007-10-15 17:26 ` concept of a permissive domain Chad Sellers
0 siblings, 2 replies; 71+ messages in thread
From: Brett Lentz @ 2007-10-15 16:52 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Stefan Schulze Frielinghaus, Chad Sellers, Karl MacMillan,
Stephen Smalley, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-15 16:52 ` Brett Lentz
@ 2007-10-15 16:58 ` Stephen Smalley
2007-10-15 18:32 ` Daniel J Walsh
2007-10-15 17:26 ` concept of a permissive domain Chad Sellers
1 sibling, 1 reply; 71+ messages in thread
From: Stephen Smalley @ 2007-10-15 16:58 UTC (permalink / raw)
To: Brett Lentz
Cc: Daniel J Walsh, Stefan Schulze Frielinghaus, Chad Sellers,
Karl MacMillan, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-15 16:58 ` Stephen Smalley
@ 2007-10-15 18:32 ` Daniel J Walsh
2007-10-15 18:40 ` Stephen Smalley
0 siblings, 1 reply; 71+ messages in thread
From: Daniel J Walsh @ 2007-10-15 18:32 UTC (permalink / raw)
To: Stephen Smalley
Cc: Brett Lentz, Stefan Schulze Frielinghaus, Chad Sellers,
Karl MacMillan, Eric Paris, selinux
-----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.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: concept of a permissive domain
2007-10-15 18:32 ` Daniel J Walsh
@ 2007-10-15 18:40 ` Stephen Smalley
2007-10-15 18:57 ` Karl MacMillan
2007-10-15 19:09 ` Eric Paris
0 siblings, 2 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-10-15 18:40 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Brett Lentz, Stefan Schulze Frielinghaus, Chad Sellers,
Karl MacMillan, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: concept of a permissive domain
2007-10-15 18:40 ` Stephen Smalley
@ 2007-10-15 18:57 ` Karl MacMillan
2007-10-15 19:09 ` Eric Paris
1 sibling, 0 replies; 71+ messages in thread
From: Karl MacMillan @ 2007-10-15 18:57 UTC (permalink / raw)
To: Stephen Smalley
Cc: Daniel J Walsh, Brett Lentz, Stefan Schulze Frielinghaus,
Chad Sellers, Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: concept of a permissive domain
2007-10-15 18:40 ` Stephen Smalley
2007-10-15 18:57 ` Karl MacMillan
@ 2007-10-15 19:09 ` Eric Paris
2007-10-17 19:47 ` Stephen Smalley
1 sibling, 1 reply; 71+ messages in thread
From: Eric Paris @ 2007-10-15 19:09 UTC (permalink / raw)
To: Stephen Smalley
Cc: Daniel J Walsh, Brett Lentz, Stefan Schulze Frielinghaus,
Chad Sellers, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: concept of a permissive domain
2007-10-15 19:09 ` Eric Paris
@ 2007-10-17 19:47 ` Stephen Smalley
2007-10-17 21:50 ` Recurring SELinux events for similar violations Hasan Rezaul-CHR010
0 siblings, 1 reply; 71+ messages in thread
From: Stephen Smalley @ 2007-10-17 19:47 UTC (permalink / raw)
To: Eric Paris
Cc: Daniel J Walsh, Brett Lentz, Stefan Schulze Frielinghaus,
Chad Sellers, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* Recurring SELinux events for similar violations...
2007-10-17 19:47 ` Stephen Smalley
@ 2007-10-17 21:50 ` Hasan Rezaul-CHR010
2007-10-17 22:18 ` Eric Paris
0 siblings, 1 reply; 71+ messages in thread
From: Hasan Rezaul-CHR010 @ 2007-10-17 21:50 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Recurring SELinux events for similar violations...
2007-10-17 21:50 ` Recurring SELinux events for similar violations Hasan Rezaul-CHR010
@ 2007-10-17 22:18 ` Eric Paris
2007-10-17 22:22 ` Hasan Rezaul-CHR010
0 siblings, 1 reply; 71+ messages in thread
From: Eric Paris @ 2007-10-17 22:18 UTC (permalink / raw)
To: Hasan Rezaul-CHR010; +Cc: Stephen Smalley, Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-10-17 22:18 ` Eric Paris
@ 2007-10-17 22:22 ` Hasan Rezaul-CHR010
2007-10-18 13:13 ` Stephen Smalley
0 siblings, 1 reply; 71+ messages in thread
From: Hasan Rezaul-CHR010 @ 2007-10-17 22:22 UTC (permalink / raw)
To: Eric Paris; +Cc: Stephen Smalley, Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-10-17 22:22 ` Hasan Rezaul-CHR010
@ 2007-10-18 13:13 ` Stephen Smalley
2007-10-18 14:32 ` Hasan Rezaul-CHR010
2007-11-29 20:06 ` Hasan Rezaul-CHR010
0 siblings, 2 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-10-18 13:13 UTC (permalink / raw)
To: Hasan Rezaul-CHR010; +Cc: Eric Paris, Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-10-18 13:13 ` Stephen Smalley
@ 2007-10-18 14:32 ` Hasan Rezaul-CHR010
2007-11-29 20:06 ` Hasan Rezaul-CHR010
1 sibling, 0 replies; 71+ messages in thread
From: Hasan Rezaul-CHR010 @ 2007-10-18 14:32 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Eric Paris, Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-10-18 13:13 ` Stephen Smalley
2007-10-18 14:32 ` Hasan Rezaul-CHR010
@ 2007-11-29 20:06 ` Hasan Rezaul-CHR010
2007-11-29 20:16 ` Stephen Smalley
1 sibling, 1 reply; 71+ messages in thread
From: Hasan Rezaul-CHR010 @ 2007-11-29 20:06 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-11-29 20:06 ` Hasan Rezaul-CHR010
@ 2007-11-29 20:16 ` Stephen Smalley
2007-11-29 21:26 ` Hasan Rezaul-CHR010
0 siblings, 1 reply; 71+ messages in thread
From: Stephen Smalley @ 2007-11-29 20:16 UTC (permalink / raw)
To: Hasan Rezaul-CHR010; +Cc: Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: Recurring SELinux events for similar violations...
2007-11-29 20:16 ` Stephen Smalley
@ 2007-11-29 21:26 ` Hasan Rezaul-CHR010
2007-11-29 21:32 ` Stephen Smalley
0 siblings, 1 reply; 71+ messages in thread
From: Hasan Rezaul-CHR010 @ 2007-11-29 21:26 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* RE: Recurring SELinux events for similar violations...
2007-11-29 21:26 ` Hasan Rezaul-CHR010
@ 2007-11-29 21:32 ` Stephen Smalley
2007-11-29 21:45 ` Stephen Smalley
0 siblings, 1 reply; 71+ messages in thread
From: Stephen Smalley @ 2007-11-29 21:32 UTC (permalink / raw)
To: Hasan Rezaul-CHR010; +Cc: selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread* RE: Recurring SELinux events for similar violations...
2007-11-29 21:32 ` Stephen Smalley
@ 2007-11-29 21:45 ` Stephen Smalley
0 siblings, 0 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-11-29 21:45 UTC (permalink / raw)
To: Hasan Rezaul-CHR010; +Cc: selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-15 16:52 ` Brett Lentz
2007-10-15 16:58 ` Stephen Smalley
@ 2007-10-15 17:26 ` Chad Sellers
1 sibling, 0 replies; 71+ messages in thread
From: Chad Sellers @ 2007-10-15 17:26 UTC (permalink / raw)
To: Brett Lentz, Daniel J Walsh
Cc: Stefan Schulze Frielinghaus, Karl MacMillan, Stephen Smalley,
Eric Paris, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 18:40 ` Chad Sellers
2007-10-12 19:05 ` Karl MacMillan
@ 2007-10-12 19:07 ` Stephen Smalley
2007-10-12 19:30 ` Stephen Smalley
1 sibling, 1 reply; 71+ messages in thread
From: Stephen Smalley @ 2007-10-12 19:07 UTC (permalink / raw)
To: Chad Sellers; +Cc: Daniel J Walsh, Eric Paris, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-10-12 19:07 ` Stephen Smalley
@ 2007-10-12 19:30 ` Stephen Smalley
0 siblings, 0 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-10-12 19:30 UTC (permalink / raw)
To: Chad Sellers; +Cc: Daniel J Walsh, Eric Paris, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-18 21:54 ` Chad Sellers
2007-09-19 12:56 ` Daniel J Walsh
@ 2007-09-19 16:35 ` Martin Orr
2007-09-19 16:41 ` Eric Paris
2007-09-19 16:52 ` Stephen Smalley
1 sibling, 2 replies; 71+ messages in thread
From: Martin Orr @ 2007-09-19 16:35 UTC (permalink / raw)
To: Chad Sellers
Cc: Stephen Smalley, Eric Paris, Daniel J Walsh, Karl MacMillan,
selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-19 16:35 ` Martin Orr
@ 2007-09-19 16:41 ` Eric Paris
2007-09-20 14:41 ` Joshua Brindle
2007-09-19 16:52 ` Stephen Smalley
1 sibling, 1 reply; 71+ messages in thread
From: Eric Paris @ 2007-09-19 16:41 UTC (permalink / raw)
To: Martin Orr
Cc: Chad Sellers, Stephen Smalley, Daniel J Walsh, Karl MacMillan,
selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-19 16:41 ` Eric Paris
@ 2007-09-20 14:41 ` Joshua Brindle
2007-09-20 14:46 ` Joshua Brindle
0 siblings, 1 reply; 71+ messages in thread
From: Joshua Brindle @ 2007-09-20 14:41 UTC (permalink / raw)
To: Eric Paris
Cc: Martin Orr, Chad Sellers, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-20 14:41 ` Joshua Brindle
@ 2007-09-20 14:46 ` Joshua Brindle
0 siblings, 0 replies; 71+ messages in thread
From: Joshua Brindle @ 2007-09-20 14:46 UTC (permalink / raw)
To: Eric Paris
Cc: Martin Orr, Chad Sellers, Stephen Smalley, Daniel J Walsh,
Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-19 16:35 ` Martin Orr
2007-09-19 16:41 ` Eric Paris
@ 2007-09-19 16:52 ` Stephen Smalley
1 sibling, 0 replies; 71+ messages in thread
From: Stephen Smalley @ 2007-09-19 16:52 UTC (permalink / raw)
To: Martin Orr
Cc: Chad Sellers, Eric Paris, Daniel J Walsh, Karl MacMillan, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: concept of a permissive domain
2007-09-18 20:24 ` Stephen Smalley
2007-09-18 20:50 ` Joshua Brindle
2007-09-18 21:54 ` Chad Sellers
@ 2007-09-24 14:59 ` Karl MacMillan
2 siblings, 0 replies; 71+ messages in thread
From: Karl MacMillan @ 2007-09-24 14:59 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Eric Paris, Daniel J Walsh, selinux
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.
^ permalink raw reply [flat|nested] 71+ messages in thread