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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
