Re: Security related defaults process

[Miloslav Trmač]

2014-04-01 18:15 GMT+02:00 Simo Sorce <simo(a)redhat.com&gt;:

>  I am personally more looking to determine a process, when we find
> out
>  something may need to change. How do we analyze the issue, what
>  guidelines will drive our decision and finally how, technically, changes
>  are made that affect just the server product.
>  
At this abstract level, I'm not quite sure I'm talking about the same thing
:)

The very highest level, the process is easy enough: specify policy goals.
https://fedoraproject.org/wiki/Privilege_escalation_policy does something
of that kind in the "Scope" section (focused on physical users, but applies
basically equally to service accounts); perhaps we need to add more
requirements.

The lowest level is also, mostly, easy enough: When any security-related
configuration option is introduced (immediately as a part of some process,
or as a batch process once per year), notice it, determine values that are
acceptable, and change the configuration or set up a Server-specific
configuration deviation (as Stephen says, treating it like any other
configuration deviation), and perhaps write tests to ensure we don't
regress.   Noticing the new option is easy enough when it is a new polkit
control, but it does require a potentially laborious manual process in
application-specific mechanisms.

It's the *middle* level that is problematic: How to ensure that the code
implements, or allows implementing, the policy goals.  I don't have any
better answer than "eternal vigilance" I'm afraid; as mentioned above, we
can notice when a new option is introduced and documented, but we can't
always notice when a new patch violating the high-level policy lands
upstream without prominent user-facing documentation of that behavior or
impact.

(No, we don't have the "lowest level" solved in the way I have described
above, with a process and automation; and we could.  But with the huge
difficulty with dealing with the "middle level", it seems to me that
improving the "middle level" would be more beneficial than automating the
"low level".)


I suppose this is just a very long-winded way of saying "I don't really
know", but perhaps it has introduced a structure that allows thinking about
the different aspects of the problem.
    Mirek