[Open-scap] Ignoring SCAP content in the OAA

[Vratislav Podzimek]

On Mon, 2014-03-03 at 13:36 -0500, Shawn Wells wrote:
> On 3/3/14, 5:51 AM, Jan Lieskovsky wrote:
> 
> > Hello Vratislav,
> > 
> > ----- Original Message -----
> > > > From: "Lee Kinser" <lkinser at redhat.com>
> > > > To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> > > > Cc: "oscap-anaconda-addon" <oscap-anaconda-addon at lists.fedorahosted.org>, "open-scap-list"
> > > > <open-scap-list at redhat.com>
> > > > Sent: Wednesday, February 26, 2014 2:53:24 PM
> > > > Subject: Re: Ignoring SCAP content in the OAA
> > > > 
> >   to share my vote / opinion - I also like the second option (ON / OFF) more.
> 
> +1 
> 
> 
> > > > Personally, I like the look of option 2, but would go with wording like
> > > > "Select Security Policy" and "Apply Security Policy".
> > "Select Security Policy / Apply Security Policy" proposed by Lee look fine to me.
> > 
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> > 
> > > >  Just my .02.
> > > > 
> > > > 
> > > > --
> > > > Lee Kinser
> > > > Solutions Architect
> > > > Navy & Marine Corps
> > > > Red Hat Federal
> > > > 843-868-1024 (Mobile)
> > > > lkinser at redhat.com
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > > From: "Vratislav Podzimek" <vpodzime at redhat.com>
> > > > > > To: "oscap-anaconda-addon" <oscap-anaconda-addon at lists.fedorahosted.org>
> > > > > > Cc: "scap-security-guide" <scap-security-guide at lists.fedorahosted.org>,
> > > > > > "open-scap-list" <open-scap-list at redhat.com>
> > > > > > Sent: Wednesday, February 26, 2014 4:07:02 AM
> > > > > > Subject: Ignoring SCAP content in the OAA
> > > > > > 
> > > > > > Hello everybody,
> > > > > > I'd like to ask you for a favour. In the development cycle of the
> > > > > > release 0.5 of the OSCAP Anaconda Addon, I've added an autodetection of
> > > > > > the SCAP Security Guide content which means that if the
> > > > > > scap-security-guide package is installed in the compose and no other
> > > > > > content is specified in the kickstart file, the addon automatically
> > > > > > loads SSG content. I believe this brings us a big improvement in UX for
> > > > > > testing and finally moves us closer to including the OAA+SSG in the
> > > > > > default composes for next Fedora (and others) release.
> > > > > > However, this also brings the need to allow user changing the content
> > > > > > used by the addon (to switch from autodetected SSG to some different
> > > > > > content) and "not applying" content to the system (to easily turn of the
> > > > > > functionality once it gets included in the default composes). Turns out
> > > > > > it's quite hard to come up with the right widgets and proper labels
> > > > > > (wording) that would explain user what's going on.
> > > > > > The two mockup suggestions I've made so far are:
> > > > > > 1. http://vpodzime.fedorapeople.org/OAA_control_buttons.png
> > > > > > 2. http://vpodzime.fedorapeople.org/OAA_control_buttons2.png
> > > > > > 
> > > > > > The 1. uses a GtkToggleButton that can be pushed down and stays in that
> > > > > > state and I think it should have some better wording catching the
> > > > > > process -- something like "Applying security rules"/"Ignoring security
> > > > > > rules" -- that would change when the button is toggled.
> > > > > > 
> > > > > > The 2. uses a switch which relies on the related label next to it and
> > > > > > again even in this case, the right wording of the label is the key, I
> > > > > > think. What about "Apply security rules"?
> > > > > > 
> > > > > > Please keep in mind the fact, that we would like this screen to be shown
> > > > > > even to unexperienced users who have no idea about SCAP and the special
> > > > > > terms/keywords it uses. We don't want to confuse users and we want to
> > > > > > give them an easy way to opt out.
> > > > > > 
> > > > > > Any suggestions welcome! I'd like to release OAA 0.5 by the end of this
> > > > > > week, so it will come with the best layout and wording we will be able
> > > > > > to come up till that time.
> 
> In regards to content autodetection, IIRC, Grubb wanted content to be
> placed into /usr/share/xml/scap/. Are you hard
> coding /usr/share/xml/scap/ssg/content, or recursively searching
> through /usr/share/xml/scap/?
> 
> Would be great to recursively search /usr/share/xml/scap/{content
> provider}, which would reenforce to content developers to properly
> place their files (or atleast symlinks) on the system.
For now, I'm hard coding the SSG's paths and consider the SSG a special
content type. To be honest, I'd like to avoid doing any additional magic
for various contents. The addon already supports RPMs, so I'd really
prefer those contents be provided and referenced as RPMs. SSG is the
only exception because it could be included in the standard composes
officially provided for "our" projects.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic