F21 Self Contained Change: Security Policy In The Installer

Jan Lieskovsky jlieskov at redhat.com
Fri Mar 14 16:38:59 UTC 2014


> On Fri, Mar 14, 2014 at 09:25:16AM -0400, Eric H. Christensen wrote:
> 
> > I disagree with this assessment.  The workstation is exactly where much of
> > these hardening needs to take place.  I can't see an installation that
> > wouldn't benefit from this feature.
> 
> If there's a default policy that would make sense for most workstation
> users, we should just make that the default.

I am afraid there isn't a default policy that would suit every possible
use case Fedora OS can be used at. Yes, there's something like "common
understanding / agreement" which technologies can be considered safe at
current level of (security) knowledge (i.e. that certain cryptographic
algorithms should be preferred for usage before the others etc.)

But the current Fedora defaults approach has one limitation - even when
we set up the defaults reasonable enough, there is possibility users
can return back to the use of less secure ways (example how many users
are still using telnet or rsh today?)

> If there isn't, how are we
> going to educate users as to which choice they should be making?

We can do the following (three alternatives comes to mind):
* use sane defaults, allow the less secure ones (if I am not wrong
  this is the current approach),

* use and enforce sane defaults (prohibiting users from using the less
  secure ones). Not good since they might turn back,

* use sane defaults, allow the less secure ones. But provide a way
  how to instruct users what should be the expected secure default today [*]
  (IOW having Anaconda to install the system to conform with some profile
  might instruct them to investigate why it was configured the way it was).

  Besides that there should be possibility to scan the system against the
  (by the security community) accepted defaults to indicate there's something
  wrong in the configuration of their system. The vision (maybe naive) being
  that this (having selected system properties / configurations marked wit red
  colour) could make them to think about the reasons of that state (and hopefully
  subsequently in the next stage make them to change these OS expectation
  patterns).

> *I*
> don't understand the terms used in the proposed UI,

Can you be more concrete which term(s) you don't understand? Maybe you are
right and the concept needs to be better explained / presented differently 
prior wider adoption [**].


> so I'd be willing to
> put money on the number of potential users who do being pretty close to
> statistically indistinguishable from 0.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

[*] I am not speaking about the security of the default Fedora installation
     right now. Rather about the (possibly insecure) ways it can be (still)
     used (despite have sane defaults)

[**] It has been designed by folks for which SCAP is daily bread, so it's
    possible it needs simplification (wider view) prior being able to
    be commonly accepted.

> 
> --
> Matthew Garrett | mjg59 at srcf.ucam.org
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


More information about the devel mailing list