1 |
On 01/16/2011 09:09 AM, Sven Vermeulen wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> When writing security policies, it is important to first have a vision on |
5 |
> how the security policies should be made. Of course, final vision should be |
6 |
> with a systems' security administrator, but a distribution should give a |
7 |
> first start for this. |
8 |
> |
9 |
> For the time being, Gentoo Hardened's policies are based upon the reference |
10 |
> policy's implementation, but I can imagine that this will evolve further. |
11 |
> The moment however we start adding policies ourselves (outside simple |
12 |
> patching of the reference policy's implementation) we need to have some |
13 |
> rules on what or how our rules should be made. |
14 |
> |
15 |
> One first principle that we might need to discuss about is what we want to |
16 |
> allow in our policy. Do we want to allow all normal behavior (i.e. you use |
17 |
> an application or server the way it is meant to and we make sure no denials |
18 |
> are generated for this) but shield off abnormal behavior as much as possible |
19 |
> (by rightly aligning domains and types)? Or do we want to allow just enough |
20 |
> so that the applications function properly during regular operations, |
21 |
> causing various denials to be in place still? |
22 |
My general feeling is that the system should operate FROM THE USER |
23 |
PERSPECTIVE the way it always does, i.e. the existence of SELinux should |
24 |
be relatively transparent to the user and/or administrator, at least to |
25 |
the extent that is practical. There may be some things that you simply |
26 |
can't avoid changing, but they should generally be few and far between. |
27 |
> And if we would opt for the latter, do we want to dontaudit those denials to |
28 |
> keep the logging clean, or do we then expect the administrator to manage his |
29 |
> own dontaudits? |
30 |
> |
31 |
My general feeling here is that, again where practical, we should avoid |
32 |
cluttering the logs. Logs that are cluttered with noise don't get |
33 |
properly evaluated for the truly exceptional conditions that the |
34 |
administrator needs to be concerned about. Obviously, there are tools |
35 |
that can help with this, but those tools should be used for the purpose |
36 |
of helping the administrator organize the information, not prune the |
37 |
logs of stuff to ignore. If there's stuff that is going to be routinely |
38 |
ignored because it is essentially useless chatter, then it shouldn't be |
39 |
there to start with. |
40 |
|
41 |
Those are just my thoughts. Others who know more than I may have a |
42 |
different opinion. |
43 |
|
44 |
Later, |
45 |
Chris |