----- Original Message ----- > From: "Chris Murphy" <li...@colorremedies.com> > On Mar 14, 2014, at 1:06 PM, "Eric H. Christensen" <spa...@fedoraproject.org> > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On Fri, Mar 14, 2014 at 06:59:18PM +0000, Matthew Garrett wrote: > >> On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: > >>> On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: > >>>> Having separate server, workstation and cloud products means we can > >>>> apply separate defaults without requiring user interaction. Beyond that, > >>>> why would an end user want to choose common criteria during an > >>>> interactive install? Isn't that something that should be imposed on them > >>>> by their local admin? > >>> > >>> Yes, and I believe the kick start would do that. I would also even see a > >>> case > >>> where an admin takes the base policy and tailors it with site specific > >>> settings > >>> and puts that into effect instead of the default one we provide. I like > >>> the > >>> idea of choice. > >> > >> Exactly, this is functionality that makes sense for enterprise and > >> automated deployments. I don't see it making sense for an interactive > >> install. > > > > You're making an assumption that I wouldn't want my personal box to be > > hardened at install or that the enterprise has an automated way of doing a > > deployments. Why make it harder to use the operating system when a > > simpler way of configuration has been suggested? > > I think Matthew is making a reasonable assumption that many (probably even > most) other users will become confused to the point of being disturbed by > something that seems to require their attention, has a UI with terms they > aren't likely familiar with, while suggesting choices, yet at the moment > there's only one policy (?) so why is a UI needed for this right now? > > This is usually what kickstart installs are for. > > > > > The feature isn't going to be a massive change to the UI and only adds to > > the awareness that users have a choice on how hardened their system is at > > install time. Whether you chose to use it is your business. > > At this point it doesn't appear to need a UI. There's no off or on switch, or > opt in or opt out. There's one policy. I'd say even with three policies > available I'm much better off with a slider that says Standard Security - > More Secure - Most Secure. I mean, that's sufficiently dumbed down I still > don't know what those things actually mean in terms of policy or behaviors, > but relative to each other I've made a more informed decision than what I'm > currently presented with.
The problem with this proposal (Standard Security - More - Most within slider) being it's binding the current SCAP security guide content with Anaconda add-on too "much" (IOW it's not flexible). What if in the future we would like to have five instead of three profiles? Another point is that due to different targeted use of profiles (server vs cloud security etc.) it's not possible to decide which of the profiles is more safer (i.e. use linear scaling from less secure to the most secure). It would be possible if each profile would be implemented as inheriting from his predecessor. But this is not the case always (server vs cloud) - on one hand there would be rules both of them would derive from their parent (common), but on the other hand there would be also usage specific rules (IOW server not having those from cloud and vice versa). > I mean honestly how complicated does an OS install > need to be? It's like piling on the user. > > It does need a default, like Timezone spoke, even though sometimes that too > is set wrong for a particular user. The default avoids the requirement the > user enter the spoke. It should be a minimum recommended security policy. > > The next question I have is how this spoke can affect other spokes, as well > as affect the installation process itself? What I'm looking for is some > assessment of impact on QA resources needed to test this feature, if any > resources are needed at all. If there's no default but the user must > interact with this spoke to proceed with installation, that's definitely a > QA impact. Common profile from SCAP security guide would be the default policy (if to apply security policy toggle button was toggled on). Would we know more details about the system from the start (i.e. if it's to be standalone server installation or movable laptop "edition" we could use even more specific default profile). > There's maybe one or two toothbrush wrappers of spare resources > in QA (and I'm already imagining Adam feverishly writing a reply, "UMMM, I > don't think so, where?!") So if it's even remotely possible for a security > policy to be chosen that later causes some sort of install, or even a first > boot failure to happen - that's too much QA impact right now, short of a > recruitment drive. There would be two "levels" of testing required: * one group to test the functionality of OSCAP Anaconda Addon (i.e. if it works properly). Assuming, this would be done within Fedora Anaconda install testing, * the second to test if rules in common profile don't lead to boot failure condition (IOW test the SCAP content itself). The upstream SCAP security guide content is tested before allowed to be included in the repository. But even in case a boot failure would happen, there is easy way how in the policy to (temporarily) disable the particular rule causing boot failure from being evaluated against the system feature till the moment it's fixed. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > Chris Murphy > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
