F21 Self Contained Change: Security Policy In The Installer

[Vratislav Podzimek]

On Thu, 2014-03-13 at 13:38 -0400, David Malcolm wrote:
> On Thu, 2014-03-13 at 15:27 +0100, Vratislav Podzimek wrote:
> > On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote:
> > > > > There are many known tips and tricks how to make a system more secure,
> > > > > often
> > > > > depending on the use case for the system. With the OSCAP Anaconda Addon [1]
> > > > > and the SCAP Security Guide [2] projects, we may allow users choosing a
> > > > > security policy for their newly installed system.
> > > > > 
> > > > > What is the proposed default configuration/policy?
> > > > 
> > > > FWIW WRT to scap-security-guide content there's only one (common) profile
> > > > at the moment. But it depends on the target group / volume / spin we would
> > > > like
> > > > this to be by default part of -- once this is clear in that case the profile
> > > > can
> > > > be adjusted / modified to prefer / select by default just rules intended for
> > > > the
> > > > target group of that system
> > > > 
> > > > So, let me be more specific: If I install using the most default setup
> > > > possible (not touching the policy spoke), will the installed system be
> > > > affected by the policy / different from what is packaged in the RPMs?
> > > 
> > > No (by default AFAICT). But since there will be oscap-anaconda-addon present
> > > in the compose / distro (if this proposal got approved), the user *before* /
> > > *in the moment* of the install will have chance to select which profile the
> > > installed system should be compliant to / in conformance with once installed.
> > > 
> > > But should their preference be not to change / configure anything, they will
> > > still have chance to "ignore" the proposed "Security Profile" anaconda field,
> > > and use vanilla Fedora installation (as there wouldn't be the proposed enhancement
> > > present at all).
> > > 
> > > Vrata, pls correct me if / where appropriate.
> > The current behaviour of the addon is to *not* select any profile by
> > default. So unless the user visits the spoke and chooses some profile
> > (and doesn't toggle the "Apply security policy" switch), no changes will
> > be done to the installed system. So it's "opt in" solution, not an "opt
> > out" one.
> 
> Will the spoke's label have some text like "No security profile
> selected" or somesuch when that's the case?
> 
> Presumably the "Begin Installation" is insensitive until the "Security
> Profile" spoke is happy, like how other spokes work?
> 
> I like the overall idea, but I'm slightly nervous about the UI.  How, if
> at all, do security policies affect the UI in the *other* spokes?
> (sorry, I wasn't able to view your videos on this box, just the
> screenshots).
> 
> For example, if you have a security profile which mandates that /tmp be
> on a separate partition or logical volume, does this affect the UI in
> the partitioning spoke?
> 
> Similarly, if the profile forbids package "telnet" from being installed,
> does this show up somehow in the "Software Selection" spoke?  (e.g. what
> if the user tries to manually select "telnet" within that spoke?).
> 
> Likewise, does the Profile's password complexity requirements affect the
> password UI?
> 
> Or is it a case of: review the issues listed in the "Security Profile"
> spoke, and figure out "how do I fix this?", switch to the appropriate
> spoke, try to fix it, see if the Security Profile spoke is now happy,
> else repeat.  That seems suboptimal, though what you've got may well be
> good enough for a first iteration (and I'm not volunteering to hack on
> it, so feel free to ignore me ;) ).
> 
> Hope this is constructive; as I said, I like the proposal.
Thanks for your feedback, it definitely is constructive! I've recorded a
video preview demostrating the feature's functionality. Hope that
answers at least some of your and others' questions.

https://vimeo.com/89243587

-- 
Vratislav Podzimek

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