----- Original Message -----
From: "Bruno Wolff III" <bruno(a)wolff.to>
To: "Jan Lieskovsky" <jlieskov(a)redhat.com>
Cc: "SCAP Security Guide" <scap-security-guide(a)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(a)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
>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
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
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
* 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
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  engine
to implement this check to overcome this OVAL requirement for Fedora.
Plus the config checking has a lot less
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
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
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
profiles, possibly containing less rules && therefore being complete sooner?
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team