Re: F21 Self Contained Change: Security Policy In The Installer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014-03-14 17:01 GMT+01:00 Jan Lieskovsky <jlieskov@xxxxxxxxxx>:
> Jan Lieskovsky (jlieskov@xxxxxxxxxx) 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
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux