I was looking at what is available for checks in Fedora compared to RHEL by using scap-workbench customization and found tha Fedora was missing a lot, even when the test commands were available (e.g yum check-update) in Fedora.
I can believe that doing CVE checks for Fedora would be a significant amount of ongoing work that no one might want to do, but most stuff that works in RHEL is probably available in Fedora. And new stuff in Fedora that requires changes is likely to eventually show up in future RHEL versions and not be completely extra work.
Hello Bruno,
thank you for reaching out and checking with us!
----- Original Message -----
From: "Bruno Wolff III" bruno@wolff.to To: scap-security-guide@lists.fedorahosted.org Sent: Wednesday, September 16, 2015 10:28:18 PM Subject: Why is Fedora xccdf missing so much compared to RHEL?
I was looking at what is available for checks in Fedora compared to RHEL by using scap-workbench customization and found tha Fedora was missing a lot, even when the test commands were available (e.g yum check-update) in Fedora.
The SCAP content provided by SSG is split among multiple products (therefore it's partly question of resources we can in each release dedicate in order to improve the set of existing checks already provided for that product).
Another point is prioritization. Due to lack of feedback from Fedora users community [1] we prioritize which checks should be added for Fedora in the next release after the following scheme: * system security settings first (e.g. password strength settings, SELinux policy settings, auditd settings, network configuration & firewalls settings), * then most commonly used network services (checks for ntpd, sshd, httpd, sendmail / exim, snmpd, nfsd, nscd, named, or smbd would be here), * then the checks for the rest of available services or system settings (not that frequently used services or rare system settings would fall into this category).
Above scheme is based on assumption we first need to harden the underlying OS, then focus on services (sshd being an exception in this case). Another point being we want the content to be universal (applicable regardless of the area of use of the target Fedora system). Therefore instead of taking one concrete section (e.g. dedicated to database services) and finishing that one out first, we tend to add less rules, but rather into multiple sections.
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.
I can believe that doing CVE checks for Fedora would be a significant amount of ongoing work that no one might want to do, but most stuff that works in RHEL is probably available in Fedora.
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. This topic (producing CVE content for Fedora) has been couple of times discussed on various mailing lists already, without a substantial movement / progress done so far. It's partly because it's difficult to manage correctly (a lot of security updates for Fedora are available yet before the official CVE id has been assigned to that security issue) on one hand, and partly because it's requires substantial amount of work to be done on regular basis (all the new security updates issued would need to be converted into OVAL form). Another point is doing CVE scan of Fedora system with incomplete data might lead to "false sense of security" (the tool using incomplete data might claim the system is secure, when it actually wouldn't be). IMHO to claim this type of false statements about security state of particular system, it's better not to even try to scan that rule, and let Fedora community users to keep their systems updated on regular basis (IOW follow the recommendations from the Fedora Security Guide).
And new stuff in Fedora that requires changes is likely to eventually show up in future RHEL versions and not be completely extra work.
We realize the importance of Fedora product (it's not a "second-class citizen"). Vice versa approach is actually valid -- some time ago there hasn't been security hardening content available for Fedora. We started its development based on the content being available for Red Hat Enterprise Linux 6 system in that moment. Gradually (in each release) are improving it. It's taking time just due the differences between RHEL-6 and Fedora systems (SystemV init scripts vs systemd at the very least / to mention some). We also need to modify the tools used for checks in order they to be able to overcome / properly deal with those differences (IOW it's not just a question of porting some rule from RHEL-6 to Fedora).
What can be improved right away: * if you are missing some rule / group of them for some system part (e.g. rules for httpd service, rules for databases, etc.), let us know about it by filing a bug (downstream or upstream), so we can adjust the prioritization.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[1] P.S.: We are aware that lack of feedback from the Fedora users community might be partly caused by insufficient SSG upstream presentation of the tool to these users, and already are working on improving the status quo.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On Thu, Sep 17, 2015 at 10:33:27 -0400, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Bruno,
thank you for reaching out and checking with us!
Thanks for responding.
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.
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. 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. Plus the config checking has a lot less stuff available. 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.
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.
----- Original Message -----
From: "Bruno Wolff III" bruno@wolff.to To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@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@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
On Fri, Sep 18, 2015 at 07:43:31 -0400, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Bruno Wolff III" bruno@wolff.to
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?
I think we would care if security updates weren't getting applied.
- 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'),
I didn't realize that. That makes things harder.
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?
Yes, security updates can be blocked by this. This would mostly happen in branched and rawhide where the update could easily become available before all dependents of a library have been rebuilt. It is less likely to happen with updates, as soname bumps are to be avoided if possible for updates.
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.
It looks like scap-workbench makes it pretty easy to turn on features to make modified profiles as long as the features are in the xccdf file.
Would it make sense to create more specific ('Server', 'Cloud', or even 'Workstation') profiles, possibly containing less rules && therefore being complete sooner?
I would think that it would make sense to eventually have profiles for each of those. I think this would be more for prioritizing what order tests might be developed. It's possible that some people from the cloud or server groups might want this and find some resources to work on it.
Thanks for your comments about the current and future state of scap support.
On Wed, 16 Sep 2015 15:28:18 -0500 Bruno Wolff III bruno@wolff.to wrote:
I was looking at what is available for checks in Fedora compared to RHEL by using scap-workbench customization and found tha Fedora was missing a lot, even when the test commands were available (e.g yum check-update) in Fedora.
I think its a matter of man power vs priorities. I think attention will turn to Fedora once RHEL6 & 7 content is stable.
I can believe that doing CVE checks for Fedora would be a significant amount of ongoing work that no one might want to do, but most stuff that works in RHEL is probably available in Fedora.
I have proposed a number of times to have bodhi generate OVAL code for every security release of a package. It would be simple to add a couple fields to the page for maintainers to fill out. Then we can have CVE scans of Fedora. This would be a nice addition.
And new stuff in Fedora that requires changes is likely to eventually show up in future RHEL versions and not be completely extra work.
Right. Its a matter of getting other things done first.
-Steve
scap-security-guide@lists.fedorahosted.org