2014-03-14 16:03 GMT+01:00 Bill Nottingham <nott...@splat.cc>:
> 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?
>
We don't, and I don't think we should. The experts in this area (combined
with our testing of real-world usability) have much better chance to choose
a suitable default than a random user that is an expert in something else
than security.
When choosing such a default, we *are*, though, limited to making choices
that don't noticeably inconvenience the user and don't change their usual
workflow, and that is a *fairly significant* limitation.
There are two ways to avoid this limitation and get better security: either
be a security expert or paranoid yourself (and in that case you don't need
anaconda's handholding), or have an expert (that you trust or have to
listen to) make an informed choice for you.
Larger-scale security policies, the kind that would be verified using SCAP,
are usually (if their usage is not just a cargo cult) the latter: a way to
defer to an expert.
For example, the policy may require longer passwords. Such a requirement
could not be a general default, but the reasons why it can't be a general
default doesn't apply to the institution imposing the non-default security
policy, namely:
- It would be based on an *informed* analysis of the threats and attacks
applicable in that environment that calls for the longer value.
- It would be *acceptable to impose* because within the institution
"having an inconveniently long password" is being accepted as a part of
people's jobs, not as a reason to give up on the OS and install Windows /
use a tablet instead.
- It would be *verifiably followed*--that's the primary "technical
function" of SCAP. (... but note that this anaconda add-on would actually
use SCAP to *modify* the configuration, not just* validate* it).
I think a similar level works here - I see no issues with support of this in
> anaconda that's exposed in kickstart, or post-install support for easily
> applying a policy that an organization might have.
>
The nice thing about during-install support is that it gives the policy
writer/maintainer a really specific and static target: it's fairly easy to
test that with the static installation environment and a known set of
packages, the policy can be applied and results in full compliance. Then,
immediately after installation, one could e.g. (yum update), and if that
caused a policy violation, there would be a known starting point from which
one could look for the cause of the violation.
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.
>
It seems to me that "please input an URL for the policy to follow" is not a
reasonable interactive installation step. Having more than one policy, or
policy profile, within the repository, and asking the user to choose ("is
this a server / wired workstation / laptop you will be taking out of the
building") might be appropriate even for an interactive installation done
by uninformed users--I don't know whether the proposed code supports this
feature or even how desirable it would be.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
