F21 Self Contained Change: Security Policy In The Installer

[Miloslav Trmač]

2014-03-14 17:01 GMT+01:00 Jan Lieskovsky <jlieskov at redhat.com>:

> > Jan Lieskovsky (jlieskov at redhat.com) said:
> >
> > I'm looking at this from a different angle. Do we, out of the box in
> > anaconda, have a spoke for configuring SELinux policy specifics (or
> > downloading new policies)?  Do we, out of the box in anaconda, have a
> spoke
> > for setting the F21 crypto policy feature, or password encryption
> > algorithms, or the firewall?
>
> No, we don't. But the proposal is here so we wouldn't need to have them in
> the future.
>
> Everything you listed above can be handled via SCAP rules / profiles.
> The only thing we need is an entry point required to have a chance somehow
> to signal users they should take a minute before actually hitting the
> "Begin installation" button to think about final security level (should it
> be SELinux policies, crypto policy, password encryption algorithms,
> firewall
> rules specification etc.) of the installed system, they would like the
> targeted
> installed system to have.
>

What *specific* question would they be asked?  Certainly not "think about
security" :)  especially if they may be asked to input a URL.

> But for the interactive install case, I think we're probably better
> served by
> > just choosing secure defaults rather than having a specific screen in the
> > installer for every user.
>
> Agree with secure defaults proposal. But the issue is it's wide term (what
> one user might consider secure enough for them [and it truly might be
> secure
> enough for their application / usage case of Fedora installation], might
> not
> seem as being sufficient enough to another user -- couple of examples:
> * how long passwords should the system require to allow newly created users
>   to be registered? 8, 10, 12, 14 characters long? Even longer?
> * should the partitions be encrypted by default or not?
> * should /var, /var/log, /tmp be on separate partitions or not?
>
> (I think) the answers on these (and similar questions) can't be generalized
> to be the best ones for each of the systems.


I think we have a fairly good chance to choose a *general* default, at
least in the abstract.  For these specific examples:

   - Don't make workstation passwords long; it always annoys users and
   there's not a *real* need for a them to be long (well, except for the
   disk encryption password).  Instead just disable remote access features
   (perhaps, even if enabling file sharing, only enable it with TTL=1 to avoid
   making it acessible to the Internet).
   - Yes if there is an interactive user.  We *should* be just asking the
   users to log in, and use the login process to unlock the disk, thus making
   it completely transparent, instead of having a separate LUKS passphrase.
   - No, partitions are a lame workaround for quotas.  If our quotas are
   lacking, let's enhance them.

SCAP *is* useful precisely in the situations where a *general* default is
not applicable--but those are pretty much by definition non-default
situations; we wouldn't be giving the "default" user in a "default"
installation environment a choice in security policies; see above about
"what question would you ask the user?"


> Yet another view - in the current state we provide secure defaults that
> are "reasonable enough" for majority of the systems, but require / expect
> the users to get (and stay) informed about the development / evolution in
> the security area (meaning they need to know there exist such concept like
> disk encryption, and that they probably want to start using it.


Fedora's lifetime is short enough that by the time such an evolution
happens, the user will be reinstalling and therefore automatically using
our new defaults.  (The user might be using fedup and thus perhaps miss the
defaults change, but this Change AFAICT doesn't apply to that case either.)


> In contrast to that compare a design in which the user could select
> just "level of security they want the final system to meet" [to simplify
> let's split them just into 1) low, 2) medium 3) high levels].


I'm afraid such one-dimensional measurement of security just doesn't work.
If the "high" level caused ssh connections from an old computer, or TLS to
their bank, to fail, how would they be told that they need to change from
"high" to "medium"?  How would the user know which one to choose?  (How
would they know that they shouldn't be choosing "high" in the first place
because it would break TLS to their bank?)  What if they really need ssh
connections to work (because it's on the local network anyway) but want the
TLS to their banks to be well-protected?
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140314/c02db6f4/attachment.html>