Security related defaults process

[Simo Sorce]

On the meeting today we briefly discussed how to address defaults that
may be appropriate for a server and may differ from other Fedora
products, how to find them, how to change them in the product.

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.

I'd like ideas and discussion around this topic so we can determine if
it is important, and how to deal with this 'stuff'.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/01/2014 12:15 PM, Simo Sorce wrote:
>  On the meeting today we briefly discussed how to address defaults
>  that may be appropriate for a server and may differ from other
>  Fedora products, how to find them, how to change them in the
>  product.
>  
>  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. 

Working backwards from the end here. I don't think that security
defaults are anything but a special case of products wanting different
configuration defaults. I think that conversation has been held ad
nauseam on the fedora-devel list[1] at this point. As far as the
technical changes to address this are concerned, I think it should
follow whatever policy we adopt there.


As for how we process the need, I think the process can probably be
very simple (and similar to the Change process):
1) Open a discussion on the fedora-server mailing list.
2) After a week, it gets added to the Server WG meeting agenda and is
voted on (or deferred for additional discussion on the list).

As far as guidelines to drive us, I really can think of only two:
1) Default to deny in the absence of explicit permission grant.
2) See rule one.


>  
>  I'd like ideas and discussion around this topic so we can determine
>  if it is important, and how to deal with this 'stuff'. 

[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196546.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlM67/IACgkQeiVVYja6o6N7xQCeMT0dRrKnQSMKvbF+Z/vMFvzF
> VSQAoJ9OMnQVBa0Ddcozq4cXi5u43PJN
> =1q2b
> -----END PGP SIGNATURE-----

[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