2014-03-14 16:03 GMT+01:00 Bill Nottingham <notting@xxxxxxxx>:
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.
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.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:
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.
Mirek
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
