F21 Self Contained Change: Security Policy In The Installer

Jan Lieskovsky jlieskov at redhat.com
Fri Mar 14 11:00:03 UTC 2014


> Existing NIST and Red Hat documentation on OpenSCAP says that it's for
> enterprise-level Linux infrastructure.

The possibilities of SCAP protocol:
  [1] http://scap.nist.gov/
  [2] http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf
  [3] http://en.wikipedia.org/wiki/Security_Content_Automation_Protocol

are not limited to enterprise-level Linux infrastructure. More from [2]:

SCAP is a multi - purpose framework of specifications that support automated
configuration, vulnerability and patch checking, technical control compliance
activities, and security measurement.

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

> 
> What does setting a security profile in Anaconda achieve that can't be done,
> or done as effectively, post-install?

Of course there exists other ways how to achieve the same. The motivation why
the proposal should get into wider user knowledge / awareness being it's flexibility
when trying to manage security configuration, vulnerability checks, and also patches.

There exists means how the provided security policy can be adjusted to reflect the particular
targeted purpose (profiles modified to contain just subset of provided rules, apply
various subsets to various systems etc.) -- for example via the scap-workbench tool:
  https://fedorahosted.org/scap-workbench/

Naturally it can be done via post-install for example too. The question is how that
implementation would be adaptable to new requirements / security policy change requirements
during the time / based on targeted system's application though.

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

> 
> 
> Chris Murphy
> --
> 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


More information about the devel mailing list