<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-01 18:15 GMT+02:00 Simo Sorce <span dir="ltr"><<a href="mailto:simo@redhat.com" target="_blank">simo@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am personally more looking to determine a process, when we find out<br>
something may need to change. How do we analyze the issue, what<br>
guidelines will drive our decision and finally how, technically, changes<br>
are made that affect just the server product.<br></blockquote><div><br></div><div>At this abstract level, I'm not quite sure I'm talking about the same thing :)<br></div><div><br></div></div>The very highest level, the process is easy enough: specify policy goals. <a href="https://fedoraproject.org/wiki/Privilege_escalation_policy">https://fedoraproject.org/wiki/Privilege_escalation_policy</a> 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.<br>
<br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's the <i>middle</i> 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.<br>
<br></div><div class="gmail_extra">(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".)<br>
<br><br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"> Mirek<br></div></div>