[gentoo-hardened] SELinux policy rules principles?

[gentoo-hardened] SELinux policy rules principles?

[Sven Vermeulen]

Hi all,

When writing security policies, it is important to first have a vision on
how the security policies should be made. Of course, final vision should be
with a systems' security administrator, but a distribution should give a
first start for this.

For the time being, Gentoo Hardened's policies are based upon the reference
policy's implementation, but I can imagine that this will evolve further.
The moment however we start adding policies ourselves (outside simple
patching of the reference policy's implementation) we need to have some
rules on what or how our rules should be made.

One first principle that we might need to discuss about is what we want to
allow in our policy. Do we want to allow all normal behavior (i.e. you use
an application or server the way it is meant to and we make sure no denials
are generated for this) but shield off abnormal behavior as much as possible
(by rightly aligning domains and types)? Or do we want to allow just enough
so that the applications function properly during regular operations,
causing various denials to be in place still?

And if we would opt for the latter, do we want to dontaudit those denials to
keep the logging clean, or do we then expect the administrator to manage his
own dontaudits?

Wkr,
       Sven Vermeulen

Re: [gentoo-hardened] SELinux policy rules principles?

[Chris Richards]

On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
> Hi all,
>
> When writing security policies, it is important to first have a vision on
> how the security policies should be made. Of course, final vision should be
> with a systems' security administrator, but a distribution should give a
> first start for this.
>
> For the time being, Gentoo Hardened's policies are based upon the reference
> policy's implementation, but I can imagine that this will evolve further.
> The moment however we start adding policies ourselves (outside simple
> patching of the reference policy's implementation) we need to have some
> rules on what or how our rules should be made.
>
> One first principle that we might need to discuss about is what we want to
> allow in our policy. Do we want to allow all normal behavior (i.e. you use
> an application or server the way it is meant to and we make sure no denials
> are generated for this) but shield off abnormal behavior as much as possible
> (by rightly aligning domains and types)? Or do we want to allow just enough
> so that the applications function properly during regular operations,
> causing various denials to be in place still?
My general feeling is that the system should operate FROM THE USER 
PERSPECTIVE the way it always does, i.e. the existence of SELinux should 
be relatively transparent to the user and/or administrator, at least to 
the extent that is practical.  There may be some things that you simply 
can't avoid changing, but they should generally be few and far between.
> And if we would opt for the latter, do we want to dontaudit those denials to
> keep the logging clean, or do we then expect the administrator to manage his
> own dontaudits?
>
My general feeling here is that, again where practical, we should avoid 
cluttering the logs.  Logs that are cluttered with noise don't get 
properly evaluated for the truly exceptional conditions that the 
administrator needs to be concerned about.  Obviously, there are tools 
that can help with this, but those tools should be used for the purpose 
of helping the administrator organize the information, not prune the 
logs of stuff to ignore.  If there's stuff that is going to be routinely 
ignored because it is essentially useless chatter, then it shouldn't be 
there to start with.

Those are just my thoughts.  Others who know more than I may have a 
different opinion.

Later,
Chris

Re: [gentoo-hardened] SELinux policy rules principles?

[Sven Vermeulen]

On Sun, Jan 16, 2011 at 11:06:47AM -0600, Chris Richards wrote:
> My general feeling is that the system should operate FROM THE USER 
> PERSPECTIVE the way it always does, i.e. the existence of SELinux should 
> be relatively transparent to the user and/or administrator, at least to 
> the extent that is practical.  There may be some things that you simply 
> can't avoid changing, but they should generally be few and far between.

So you want the application to function properly and that the logs have no
"cosmetic" AVC denials (fine - fully agree here). One thing that I can't 
gather from this is
- do you want to dontaudit the AVC denials which apparently have no impact
  on functionality, or
- do you want to allow the AVC denials even though they have no impact on
  functionality

I personally don't mind having Gentoo Hardened pick the latter (we use
SELinux to confine applications in the manner that no denial should ever be
triggered as long as the application doesn't go beyond what it is programmed
to do). Even though it might not be within the principle of "least
privilege" (only allow what it needs), at least it gives the SELinux policy
developer a clearer scope of his tasks.

The problem with the first approach is that other users have a higher
likelihood of having a malfunctioning system than with the last (what the
developer sees as cosmetic might be important on other systems). 

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux policy rules principles?

[Sven Vermeulen]

On Sun, Jan 16, 2011 at 08:22:03PM +0100, David Sommerseth wrote:
> Why not have a look at what Fedora and RHEL/CentOS does in that regards? 
> They've probably already been through a lot of these decisions as well, and 
> were probably also one of the earlier adopters.

Well, most of these distributions offer a targeted SELinux policy approach
(they confine specific services/daemons, but most user activity is ran in
unconfined domains) instead of a strict SELinux policy approach (no
unconfined domains). Although they still have the same problem, it's scope
is not as large as within a strict approach.

The distributions I look at (fedora mainly) doesn't really seem to use 
one or the other. I also can't find any resource that sais to developers
how they should focus their policies. From a quick chat on #selinux I seem
to deduce that It Depends (tm). Mostly on the developer in charge. 

What I do notice is that, if a module has an allow statement which is
cosmetic (not needed) it doesn't ever get removed because there's noone
"trying" to remove statements to see if they are really cosmetic (that's a
nice conundrum - how do I then know that a rule is cosmetic ;-) 

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux policy rules principles?

[Chris Richards]

On 01/19/2011 01:39 PM, Sven Vermeulen wrote:
> So you want the application to function properly and that the logs have no
> "cosmetic" AVC denials (fine - fully agree here). One thing that I can't
> gather from this is
> - do you want to dontaudit the AVC denials which apparently have no impact
>    on functionality, or
> - do you want to allow the AVC denials even though they have no impact on
>    functionality
>
> I personally don't mind having Gentoo Hardened pick the latter (we use
> SELinux to confine applications in the manner that no denial should ever be
> triggered as long as the application doesn't go beyond what it is programmed
> to do). Even though it might not be within the principle of "least
> privilege" (only allow what it needs), at least it gives the SELinux policy
> developer a clearer scope of his tasks.
>
> The problem with the first approach is that other users have a higher
> likelihood of having a malfunctioning system than with the last (what the
> developer sees as cosmetic might be important on other systems).
>

As I mentioned previously, my concern with having harmless AVCs in the 
log is that we create a situation where the System Admin gets so used to 
seeing all of these AVCs that he gets in the habit of ignoring them.  
Being in the habit of ignoring stuff in the logs is, IMO, a Bad Thing 
because it increases the likelihood of ignoring something important.

That being said, troubleshooting a system where legitimate AVCs are 
being dontaudited can be difficult, and determining if an AVC should be 
dontaudited can involve digging through a LOT of code.  Perhaps we 
should leave the AVCs we aren't certain of for a bit, with an eye to 
either dontauditing or fixing them at a later date?

Later,
Chris

Re: [gentoo-hardened] SELinux policy rules principles?

[Sven Vermeulen]

On Wed, Jan 19, 2011 at 02:05:39PM -0600, Chris Richards wrote:
> As I mentioned previously, my concern with having harmless AVCs in the 
> log is that we create a situation where the System Admin gets so used to 
> seeing all of these AVCs that he gets in the habit of ignoring them.  
> Being in the habit of ignoring stuff in the logs is, IMO, a Bad Thing 
> because it increases the likelihood of ignoring something important.
> 
> That being said, troubleshooting a system where legitimate AVCs are 
> being dontaudited can be difficult, and determining if an AVC should be 
> dontaudited can involve digging through a LOT of code.  Perhaps we 
> should leave the AVCs we aren't certain of for a bit, with an eye to 
> either dontauditing or fixing them at a later date?

Hmm, perhaps with a tunable_policy called `gentoo_try_dontaudit' or
something similar. The boolean could provide additional benefit as it sais
to the end user "hey, if you enable this, you'll get less AVC denials but we
are not fully confident yet that they are true ignorable denials", unlike
the "semodule -D" approach which also disables all real ignorable dontaudit
denials. 

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux policy rules principles?

[Chris Richards]

On 01/19/2011 02:25 PM, Sven Vermeulen wrote:
> On Wed, Jan 19, 2011 at 02:05:39PM -0600, Chris Richards wrote:
>> As I mentioned previously, my concern with having harmless AVCs in the
>> log is that we create a situation where the System Admin gets so used to
>> seeing all of these AVCs that he gets in the habit of ignoring them.
>> Being in the habit of ignoring stuff in the logs is, IMO, a Bad Thing
>> because it increases the likelihood of ignoring something important.
>>
>> That being said, troubleshooting a system where legitimate AVCs are
>> being dontaudited can be difficult, and determining if an AVC should be
>> dontaudited can involve digging through a LOT of code.  Perhaps we
>> should leave the AVCs we aren't certain of for a bit, with an eye to
>> either dontauditing or fixing them at a later date?
> Hmm, perhaps with a tunable_policy called `gentoo_try_dontaudit' or
> something similar. The boolean could provide additional benefit as it sais
> to the end user "hey, if you enable this, you'll get less AVC denials but we
> are not fully confident yet that they are true ignorable denials", unlike
> the "semodule -D" approach which also disables all real ignorable dontaudit
> denials.
>

Now THAT'S an idea a like!

Later,
Chris

Re: [gentoo-hardened] SELinux policy rules principles?

[Sven Vermeulen]

On Sun, Jan 16, 2011 at 11:06:47AM -0600, Chris Richards wrote:
> On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
> > When writing security policies, it is important to first have a vision on
> > how the security policies should be made. Of course, final vision should be
> > with a systems' security administrator, but a distribution should give a
> > first start for this.
[... What to allow ...]
> My general feeling is that the system should operate FROM THE USER 
> PERSPECTIVE the way it always does, i.e. the existence of SELinux should 
> be relatively transparent to the user and/or administrator, at least to 
> the extent that is practical.  There may be some things that you simply 
> can't avoid changing, but they should generally be few and far between.
[... What to hide ...]
> My general feeling here is that, again where practical, we should avoid 
> cluttering the logs.  Logs that are cluttered with noise don't get 
> properly evaluated for the truly exceptional conditions that the 
> administrator needs to be concerned about.  Obviously, there are tools 
> that can help with this, but those tools should be used for the purpose 
> of helping the administrator organize the information, not prune the 
> logs of stuff to ignore.  If there's stuff that is going to be routinely 
> ignored because it is essentially useless chatter, then it shouldn't be 
> there to start with.

Well, I've taken the liberty of writing down a sort-of policy document in
which we can include our development principles and methods. The idea is
that both existing and new developers then know how to "include" their 
suggested changes and how to configure/design the added SELinux policy
rules.

The document: http://goo.gl/2U0Zr

I've included a few of the items we discussed already, but also added
two others ones (see the "No Role-Specific Domains" and "Only Reference
Policy Suggested Roles" rules).

It's a *discussion* document, I'm really open to (many) suggestions (and
enhancements ;-)

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux policy rules principles?

[klondike]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

El 21/01/11 22:55, Sven Vermeulen escribió:
> On Sun, Jan 16, 2011 at 11:06:47AM -0600, Chris Richards wrote:
>> On 01/16/2011 09:09 AM, Sven Vermeulen wrote:
>>> When writing security policies, it is important to first have a vision on
>>> how the security policies should be made. Of course, final vision should be
>>> with a systems' security administrator, but a distribution should give a
>>> first start for this.
> [... What to allow ...]
>> My general feeling is that the system should operate FROM THE USER 
>> PERSPECTIVE the way it always does, i.e. the existence of SELinux should 
>> be relatively transparent to the user and/or administrator, at least to 
>> the extent that is practical.  There may be some things that you simply 
>> can't avoid changing, but they should generally be few and far between.
> [... What to hide ...]
>> My general feeling here is that, again where practical, we should avoid 
>> cluttering the logs.  Logs that are cluttered with noise don't get 
>> properly evaluated for the truly exceptional conditions that the 
>> administrator needs to be concerned about.  Obviously, there are tools 
>> that can help with this, but those tools should be used for the purpose 
>> of helping the administrator organize the information, not prune the 
>> logs of stuff to ignore.  If there's stuff that is going to be routinely 
>> ignored because it is essentially useless chatter, then it shouldn't be 
>> there to start with.
> Well, I've taken the liberty of writing down a sort-of policy document in
> which we can include our development principles and methods. The idea is
> that both existing and new developers then know how to "include" their 
> suggested changes and how to configure/design the added SELinux policy
> rules.
>
> The document: http://goo.gl/2U0Zr
>
> I've included a few of the items we discussed already, but also added
> two others ones (see the "No Role-Specific Domains" and "Only Reference
> Policy Suggested Roles" rules).
>
> It's a *discussion* document, I'm really open to (many) suggestions (and
> enhancements ;-
Recovering the spirit from the good old times huh? That's good to hear ^_^


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] SELinux policy rules principles?

[Chris Richards]

On 01/21/2011 03:55 PM, Sven Vermeulen wrote:
> The document: http://goo.gl/2U0Zr
>
> I've included a few of the items we discussed already, but also added
> two others ones (see the "No Role-Specific Domains" and "Only Reference
> Policy Suggested Roles" rules).
>
> It's a *discussion* document, I'm really open to (many) suggestions (and
> enhancements ;-)
I think it's an outstanding first pass Sven, and to be honest it appears 
to cover all of the necessary things at the moment.  I really can't 
think of anything to add, though I'll think about it some.

Later,
Chris