F21 Self Contained Change: Security Policy In The Installer

[Jan Lieskovsky]

> Jan Lieskovsky (jlieskov at redhat.com) said:
> > > Is any Fedora 21 product targeted
> > > mainly for enterprise deployment?
> > 
> > The vice versa view. Rather effort to use security configuration,
> > vulnerability and patch
> > management also in Fedora product(s) (provide necessary tools to allow it).
> > The
> > content itself will differ depending on the fact if it's used in
> > enterprise-level
> > or academic / personal-level (enterprise-level companies required their
> > systems
> > to meet the federal agencies standards for example etc.), but security
> > hardening guides / tips
> > are applicable to Fedora OS instances too (IOW you don't need to be an
> > enterprise-level company
> > to require / prefer system to be secured and have ways how to tune in
> > various aspects
> > of system's security). So this proposal is to provide such tools.
> > 
> > > Is OpenSCAP being retargeted for general
> > > purpose level infrastructure.
> > 
> > Not sure it was ever dedicated / restricted to be enterprise-level only.
> > From [3]:
> > 
> > "The Security Content Automation Protocol (SCAP), pronounced “ess-cap”,
> > combines
> > a number of open standards that are used to enumerate software flaws and
> > configuration
> > issues related to security ...  It is a method for using those open
> > standards for
> > automated vulnerability management, measurement, and policy compliance
> > evaluation."
> > 
> > There's nothing about it being exclusive just to enterprise-level
> > infrastructure
> > (actually in contrast the open standards are highlighted couple of times
> > above). Of course
> > writing the content requires time & resources. So it's more likely
> > enterprise-companies
> > will have dedicated funds to support content creation of their needs. But
> > the standard
> > itself (AFAICT) doesn't enforce / allows it to be used in enterprise-level
> > infrastructure only.
> > 
> > > If so, will (or should) at least a significant
> > > minority, say 33%, of GUI installer using end-users make use of this
> > > feature?
> > 
> > The answer depends how many Fedora users care about security of their
> > Fedora systems and would
> > be interested / willing to spend some time to harden it via the
> > possibilities provided
> > by this proposal.
> 
> 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.

> 
> 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.
> 
> 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. Of course it is possible
to provide reasonable defaults against currently existing threats / attacks
(to the level of actual knowledge), but there still is a risk of not
hitting a group of possible users due that.

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. Let's
another such feature be recent systemd's log file fingerprinting. And there
are many aspects of the operating system evolving too quick to expect /
require the users (each of them) to be aware of each of the new possibilities.

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]. The levels
in our draft correspond to profiles. SCAP security guide is a community
evolved effort, thus if certain user would obtain a feeling they are missing
some rule in particular profile, they could initiate a discussion on scap-security-guide
mailing list to get this rule added / changed etc.

The proposal could allow the common Fedora user just select a security
profile they want, let Anaconda to ensure it's installed as requested,
and directly focus on the work they plan to perform at Fedora system
(should it be writing custom application, or preparing worksheets for
university course's exercises or whatever other one). On the other hand
also users more interested / experienced in topic of security would have
a way how to simply reach the level of security they consider to be sufficient
for their (possibly) additional / specific requirements [*]

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

[*] Of course it's possible to perform it now too. But what the proposal
    brings being it simplifies the adaptability to changed requirements
    (would be sufficient to take some profile, select only wanted ones plus
    add the desired / missing ones to adapt to different target area).

> 
> Bill
> 
> --
> 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