Hello Bruno, thank you for reaching out and checking with us! ----- Original Message ----- 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. 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). 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.

----- Original Message ----- Thanks for sharing further details about your use case. 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. Don't have user experience with Nexpose => can't comment / compare on that. 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. Yes, aware of that, and working on improvement. Is this possible also for security updates? Or "just" for feature updates? 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

On Wed, 16 Sep 2015 15:28:18 -0500 Bruno Wolff III <bruno(a)wolff.to&gt; wrote: I think its a matter of man power vs priorities. I think attention will turn to Fedora once RHEL6 & 7 content is stable. 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. Right. Its a matter of getting other things done first. -Steve