FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 01-16-2011, 02:09 PM
Sven Vermeulen
 
Default SELinux policy rules principles?

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
 
Old 01-16-2011, 04:06 PM
Chris Richards
 
Default SELinux policy rules principles?

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
 
Old 01-19-2011, 06:39 PM
Sven Vermeulen
 
Default SELinux policy rules principles?

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
 
Old 01-19-2011, 06:54 PM
Sven Vermeulen
 
Default SELinux policy rules principles?

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
 
Old 01-19-2011, 07:05 PM
Chris Richards
 
Default SELinux policy rules principles?

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
 
Old 01-19-2011, 07:25 PM
Sven Vermeulen
 
Default SELinux policy rules principles?

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
 
Old 01-19-2011, 07:34 PM
Chris Richards
 
Default SELinux policy rules principles?

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
 
Old 01-21-2011, 08:55 PM
Sven Vermeulen
 
Default SELinux policy rules principles?

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
 
Old 01-21-2011, 09:12 PM
klondike
 
Default SELinux policy rules principles?

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 ^_^
 
Old 01-21-2011, 09:43 PM
Chris Richards
 
Default SELinux policy rules principles?

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
 

Thread Tools




All times are GMT. The time now is 02:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org