Why is Fedora xccdf missing so much compared to RHEL?

Jan Lieskovsky jlieskov at redhat.com
Fri Sep 18 11:43:31 UTC 2015


----- Original Message -----
> From: "Bruno Wolff III" <bruno at wolff.to>
> To: "Jan Lieskovsky" <jlieskov at redhat.com>
> Cc: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> Sent: Thursday, September 17, 2015 9:22:44 PM
> Subject: Re: Why is Fedora xccdf missing so much compared to RHEL?
> 
> On Thu, Sep 17, 2015 at 10:33:27 -0400,
>   Jan Lieskovsky <jlieskov at redhat.com> wrote:
> >
> > Hello Bruno,
> >
> >  thank you for reaching out and checking with us!
> 
> Thanks for responding.

Thanks for sharing further details about your use case.

> 
> >
> >This is where further feedback from the Fedora users community (via
> >downstream
> >bugs or via upstream tickets would be appreciated). For example would we
> >know there are a lot of tickets requesting support for httpd service scans,
> >we could prioritize that service before others in that release, etc.
> 
> Where this question comes from is at work a number of us use linux desktops
> with a mix of Fedora, OpenSUSE and other distros. We also run RHEL on a lot
> of severs. The security office would like audits of these machines, mostly
> to make sure they are "patched". Though we think config checking would
> be more useful as we all are good about keeping our machines up to date.
> Their proposal is to provide them with credentials (elevated access rights
> may or may not be requested) to allow more detailed scans than they now do.
> We aren't too comfortable with opening up machines this way, especially root
> access.

Can understand the concerns related with providing such access.

While it's true SSG scans to provide meaningful / appropriate results, the scan needs
to run with elevated privileges too (when the scanner is run under unprivileged
user account it reports in-appropriate results -- read as error messages, just
due the fact it wasn't able to collect the necessary data from the system). On
the other hand scap-workbench already provides means how to run the scan under
sudo for both (local & remote system assessment) IIRC. For oscap itself it would
be necessary to write the sudo rules on your own AFAICT.

> 
> I knew about SCAP and did some digging and it seemed like it could be used
> to do a better job (than nexpose) for our RHEL boxes.

Don't have user experience with Nexpose => can't comment / compare on that.

> We have plently of
> workstation licenses and could standardize on RHEL 7 based workstations and
> do
> centralized scap reporting. However it would be nice to be able to continue
> to run Fedora. The SCAP support there doesn't currently check for being up
> to date, even without CVE checks.

Two points here:
* what it means to be updated wrt to Fedora -- all updates from 'fedora' repo
  are installed? All updates from 'fedora-updates' or even all updates from
  'fedora-updates-testing' repo are installed?

  Or is it more like 'if fedora-updates' repo is enabled, then system is updated
  when all updates from that repo are installed. Same for 'fedora-updates-testing'
  repository case,

* second maybe even more crucial being OVAL as a language forbids to run some
  shell command to perform the check. And since yum / dnf doesn't provide a system
  flag e.g. in /etc/yum.conf or /etc/dnf/dnf.conf if system is updated (read as
  the only way to check if system is updated or not is to run 'yum | dnf check-update'),
  it's hard to: 1) simultaneously follow this OVAL requirement 2) and be able to tell
  system in question is updated or not. Hopefully we could use the SCE [1] engine
  to implement this check to overcome this OVAL requirement for Fedora.  

> Plus the config checking has a lot less
> stuff available.

Yes, aware of that, and working on improvement.

> Update checking in Fedora also has problems that RHEL
> doesn't, as soname bumps can block some updates, particularly when running
> rawhide, branched or updates-testing.

Is this possible also for security updates? Or "just" for feature updates?

> 
> I'll eventually look at using SCAP at home, but for now my main interest
> is for work.
> 
> >Doing CVE checks (vulnerability assessment) and security hardening are
> >two different things. In order to perform reliable "CVE checks" we would
> >need to have authorized and updates source of CVE OVAL definitions for
> >Fedora.
> 
> I expected this to be hard. It is a nice feature of RHEL, but Red Hat
> has income from RHEL to pay for people to do that. Getting people to
> reliably do that work in Fedora would be hard unless it could be automated
> using bohdi and bugzilla data somehow.
> 

Can't promise anything wrt to the last item. But we will definitely try
to search for possible ways of automation of this in some of future sprints.

One check wrt to "However it would be nice to be able to continue to run Fedora."
statement above -- currently content for Fedora provides just 'Common' profile
(trying to be universal). But that universality means a lot of rules need to
be ported yet before the profile can be considered complete.

Would it make sense to create more specific ('Server', 'Cloud', or even 'Workstation')
profiles, possibly containing less rules && therefore being complete sooner?

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

[1] http://www.open-scap.org/page/SCE


More information about the scap-security-guide mailing list