search

ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.2k stars 696 forks source link

We need a standard RHEL7 Scan #589

Closed rhatdan closed 7 years ago

rhatdan commented 9 years ago

Peter Vrabec and Josh Bressers and I were sitting around at the Red Hat Summit, brain storming about the RHEL7 security story and building a security scanner to look at Container Images, and I asked why we don't have a default RHEL7 scan that could be run every day and would tell admins that their machines are in a known good state,

This should be something we could apply to all RHEL7 boxes, as well as Container Images. It should be fairly small, and of course it should finish in green state. I think we should start out with just a few simple scans.

1 Scan for known CVE's 2 Scan /etc/password for easily guessable passwords/no password accounts 3 Scan for SUID applications not on the RHEL7 whitelist 4 Scan for world writeable directories not on a whitelist

I am sure the experts could suggest a few others.

Once we have this content, I would like to see it packaged up into a container, and then we could work on scanning hosts and containers with it. Perhaps even have a cron job/systemd timer that would scan the machine once per day, and issue a report stating the that the machine is still in a secure mode.

Then if someone wanted to delve into more security checks they could use SCAP workbench to add additional checks, and gov't types could obviously still do their mandatory checks.

iankko commented 9 years ago

Thank you for the proposal, Daniel.

I will have a look at this (read as will create a PR, that can be enhanced with more rules as we identify them as being appropriate for this profile on the way).

iankko commented 9 years ago

The mock-up draft of such a profile is is inlined below:

<Profile id="standard">
<title>Standard System Security Profile</title>
<description>This profile contains rules to ensure standard security base of Red Hat Enterprise Linux 7 system.</description>

<!-- CONFIGURATION OPTIONS -->
<refine-value idref="var_selinux_state" selector="enforcing"/>

<!-- STANDARD SYSTEM SECURITY CHECKS -->
<select idref="security_patches_up_to_date" selected="true"/>
<select idref="no_empty_passwords" selected="true"/>
<select idref="accounts_password_all_shadowed" selected="true"/>
<select idref="file_permissions_unauthorized_sgid" selected="true"/>
<select idref="file_permissions_unauthorized_suid" selected="true"/>
<select idref="file_permissions_unauthorized_world_writable" selected="true"/>
<select idref="dir_perms_world_writable_system_owned" selected="true"/>
<select idref="root_path_no_dot" selected="true"/>
<select idref="accounts_root_path_dirs_no_write" selected="true"/>
<select idref="rpm_verify_hashes" selected="true"/>
<select idref="selinux_state" selected="true"/>
<select idref="service_auditd_enabled" selected="true"/>
<select idref="bootloader_audit_argument" selected="true"/>
<select idref="audit_rules_privileged_commands" selected="true"/>

</Profile>

The mock-up of corresponding guide for it.

The descriptions of the rules can be updated yet. We should just agree on the set of the rules to be included there.

Review / feedback appreciated!

Thanks, Jan.

iankko commented 9 years ago

The mock-up of corresponding guide for it.

The descriptions of the rules can be updated yet. We should just agree on the set of the rules to be included there.

Review / feedback appreciated!

Replying to myself - investigated further and found out the auditd.service isn't installed by default on RHEL-7 Atomic system (so the three audit rules in the draft profile from https://github.com/OpenSCAP/scap-security-guide/issues/589#issuecomment-115356122 wouldn't work). We could replace them with some rules from Security Features Matrix.

Will propose a PR for review.

shawndwells commented 9 years ago

@iankko - why not use the CCP profile?

rhatdan commented 9 years ago

Yes auditd should not be requiered, and this would definately make no sense within a container image, any check that looks to make sure a service is running should be out.

We might end up having to have two different targets, one for atomic host and one for a container image. (BOTH MUST BE GREEN) :^)

rhatdan commented 9 years ago

I talked to Peter V and @shawndwells at the summit, and the next step after we got a scan for containers, would be to package the scan and content up into a container image. We would need a SPC that could scan all container images on the service

atomic run scapscan

Would download an scapscan image and run it in scan mode. It would need to have the atomic command and docker in the image, and probably mount /run into the container. The atomic team would probably need to work with the scap team to make this work.

rhatdan commented 9 years ago

In other conversations with David Egts and Gunnar, it was suggested that if we have this working, we make this a standard part of the Certified Image program. IE If a customer submits a container image for certification by Red Hat, it must pass the OpenScap Container Image scan.

bkearney commented 9 years ago

Do you envision the output of this to be its own ARF report, or put into the ARF for the host it is on?

smarterclayton commented 9 years ago

One problem with this is that it can't scan images that are not on a system - in an OpenShift / Kube cluster there will be images that never make it to a particular system. I'd like this container to be able to target a particular image to pull (for a start) so that we can walk the image list OpenShift has and then record the images were scanned. Down the road, being able to direct mount an image into the container would be better, but this would be a good start.

bkearney commented 9 years ago

I see the value of ensuring the image, at rest, is compliant. However, I would assume I would also want to know if a machine is compliant with all running services on it, wether in the container or not. Since folks may not use states containers, both seem valuable needs.

rhatdan commented 9 years ago

FIne lets walk before we run. I think getting this scan into a SPC container is first step, adding tooling around the container to examine lots of containers, or to pull container images should not be difficult.

@bkearney don't really know what an ARF report is, but I would expect the container to be able to output a report either to STDout or to a designated volume mount point. Then allow the tooling to place the report wherever.

rhatdan commented 9 years ago

BTW SELinux state should not be checked, since inside the container, libselinux will lie and tell you SELinux is disabled, even though it is enabled.

iankko commented 9 years ago

@iankko - why not use the CCP profile?

Hi Shawn, the problem with the RHT-CCP profile is that though it contains more rules (than proposed already) for "traditional" RHEL-7 system, it also contain rules which would be irrelevant / impossible to check on container image.

Below is the current output of this profile on "traditional" RHEL-7 system:

Title   Ensure /tmp Located On Separate Partition
Rule    partition_for_tmp
Ident   CCE-27173-4
Result  fail

Title   Ensure /var Located On Separate Partition
Rule    partition_for_var
Ident   CCE-26404-4
Result  fail

Title   Ensure /var/log Located On Separate Partition
Rule    partition_for_var_log
Ident   CCE-26967-0
Result  fail

Title   Ensure /var/log/audit Located On Separate Partition
Rule    partition_for_var_log_audit
Ident   CCE-26971-2
Result  fail

Title   Ensure Red Hat GPG Key Installed
Rule    ensure_redhat_gpgkey_installed
Ident   CCE-26957-1
Result  pass

Title   Ensure gpgcheck Enabled In Main Yum Configuration
Rule    ensure_gpgcheck_globally_activated
Ident   CCE-26989-4
Result  pass

Title   Ensure gpgcheck Enabled For All Yum Package Repositories
Rule    ensure_gpgcheck_never_disabled
Ident   CCE-26876-3
Result  pass

Title   Ensure Software Patches Installed
Rule    security_patches_up_to_date
Ident   CCE-26853-2
Result  notchecked

Title   Install AIDE
Rule    package_aide_installed
Ident   CCE-26741-9
Result  pass

Title   Verify User Who Owns shadow File
Rule    userowner_shadow_file
Ident   CCE-26795-5
Result  pass

Title   Verify Group Who Owns shadow File
Rule    groupowner_shadow_file
Ident   CCE-27125-4
Result  pass

Title   Verify Permissions on shadow File
Rule    file_permissions_etc_shadow
Ident   CCE-27100-7
Result  pass

Title   Verify User Who Owns group File
Rule    file_owner_etc_group
Ident   CCE-26933-2
Result  pass

Title   Verify Group Who Owns group File
Rule    file_groupowner_etc_group
Ident   CCE-27037-1
Result  pass

Title   Verify Permissions on group File
Rule    file_permissions_etc_group
Ident   CCE-26949-8
Result  pass

Title   Verify User Who Owns gshadow File
Rule    file_owner_etc_gshadow
Ident   CCE-27161-9
Result  pass

Title   Verify Group Who Owns gshadow File
Rule    file_groupowner_etc_gshadow
Ident   CCE-26840-9
Result  pass

Title   Verify Permissions on gshadow File
Rule    file_permissions_etc_gshadow
Ident   CCE-27162-7
Result  pass

Title   Verify User Who Owns passwd File
Rule    file_owner_etc_passwd
Ident   CCE-27138-7
Result  pass

Title   Verify Group Who Owns passwd File
Rule    file_groupowner_etc_passwd
Ident   CCE-26639-5
Result  pass

Title   Verify Permissions on passwd File
Rule    file_permissions_etc_passwd
Ident   CCE-26887-0
Result  pass

Title   Verify that Shared Library Files Have Restrictive Permissions
Rule    file_permissions_library_dirs
Ident   CCE-26966-2
Result  pass

Title   Verify that Shared Library Files Have Root Ownership
Rule    file_ownership_library_dirs
Ident   CCE-26648-6
Result  pass

Title   Verify that System Executables Have Restrictive Permissions
Rule    file_permissions_binary_dirs
Ident   CCE-27075-1
Result  pass

Title   Verify that System Executables Have Root Ownership
Rule    file_ownership_binary_dirs
Ident   CCE-27119-7
Result  pass

Title   Ensure SELinux State is Enforcing
Rule    selinux_state
Ident   CCE-26800-3
Result  pass

Title   Configure SELinux Policy
Rule    selinux_policytype
Ident   CCE-27135-3
Result  pass

Title   Ensure that System Accounts Do Not Run a Shell Upon Login
Rule    no_shelllogin_for_systemaccounts
Ident   CCE-26448-1
Result  fail

Title   Verify Only Root Has UID 0
Rule    accounts_no_uid_except_zero
Ident   CCE-27175-9
Result  pass

Title   Prevent Log In to Accounts With Empty Password
Rule    no_empty_passwords
Ident   CCE-27010-8
Result  pass

Title   Verify All Account Password Hashes are Shadowed
Rule    accounts_password_all_shadowed
Ident   CCE-27144-5
Result  pass

Title   Set Password Minimum Length in login.defs
Rule    accounts_password_minlen_login_defs
Ident   CCE-27123-9
Result  pass

Title   Set Password Minimum Age
Rule    accounts_minimum_age_login_defs
Ident   CCE-27002-5
Result  pass

Title   Set Password Warning Age
Rule    accounts_password_warn_age_login_defs
Ident   CCE-26486-1
Result  pass

Title   Set Password Retry Prompts Permitted Per-Session
Rule    accounts_password_pam_retry
Ident   CCE-27131-2
Result  pass

Title   Set Password Strength Minimum Digit Characters
Rule    accounts_password_pam_dcredit
Ident   CCE-27163-5
Result  pass

Title   Set Password Strength Minimum Uppercase Characters
Rule    accounts_password_pam_ucredit
Ident   CCE-26988-6
Result  fail

Title   Set Password Strength Minimum Special Characters
Rule    accounts_password_pam_ocredit
Ident   CCE-27151-0
Result  fail

Title   Set Password Strength Minimum Lowercase Characters
Rule    accounts_password_pam_lcredit
Ident   CCE-27111-4
Result  fail

Title   Set Password Strength Minimum Different Characters
Rule    accounts_password_pam_difok
Ident   CCE-26631-2
Result  pass

Title   Set Deny For Failed Password Attempts
Rule    accounts_passwords_pam_faillock_deny
Ident   CCE-26891-2
Result  fail

Title   Limit Password Reuse
Rule    accounts_password_pam_unix_remember
Ident   CCE-26923-3
Result  fail

Title   Set Password Hashing Algorithm in /etc/pam.d/system-auth
Rule    set_password_hashing_algorithm_systemauth
Ident   CCE-27104-9
Result  pass

Title   Set Password Hashing Algorithm in /etc/login.defs
Rule    set_password_hashing_algorithm_logindefs
Ident   CCE-27124-7
Result  pass

Title   Set Password Hashing Algorithm in /etc/libuser.conf
Rule    set_password_hashing_algorithm_libuserconf
Ident   CCE-27053-8
Result  pass

Title   Verify /boot/grub2/grub.cfg User Ownership
Rule    file_user_owner_grub2_cfg
Ident   CCE-26860-7
Result  pass

Title   Verify /boot/grub2/grub.cfg Group Ownership
Rule    file_group_owner_grub2_cfg
Ident   CCE-26812-8
Result  pass

Title   Verify /boot/grub2/grub.cfg Permissions
Rule    file_permissions_grub2_cfg
Ident   CCE-27054-6
Result  fail

Title   Set Boot Loader Password
Rule    bootloader_password
Ident   CCE-26809-4
Result  fail

Title   Require Authentication for Single User Mode
Rule    require_singleuser_auth
Ident   CCE-27170-0
Result  pass

Title   Verify iptables Enabled
Rule    service_iptables_enabled
Ident   CCE-RHEL7-CCE-TBD
Result  fail

Title   Disable DCCP Support
Rule    kernel_module_dccp_disabled
Ident   CCE-26828-4
Result  fail

Title   Disable SCTP Support
Rule    kernel_module_sctp_disabled
Ident   CCE-27106-4
Result  fail

Title   System Audit Logs Must Have Mode 0640 or Less Permissive
Rule    file_permissions_var_log_audit
Ident   CCE-27004-1
Result  pass

Title   Disable telnet Service
Rule    service_telnetd_disabled
Ident   CCE-27158-5
Result  pass

Title   Uninstall telnet-server Package
Rule    uninstall_telnet_server
Ident   CCE-27165-0
Result  pass

Title   Remove telnet Clients
Rule    package_telnet_removed
Ident   CCE-27039-7
Result  pass

Title   Disable Automatic Bug Reporting Tool (abrtd)
Rule    service_abrtd_disabled
Ident   CCE-26872-2
Result  fail

Title   Allow Only SSH Protocol 2
Rule    sshd_allow_only_protocol2
Ident   CCE-27038-9
Result  fail

Title   Set SSH Idle Timeout Interval
Rule    sshd_set_idle_timeout
Ident   CCE-26611-4
Result  fail

Title   Set SSH Client Alive Count
Rule    sshd_set_keepalive
Ident   CCE-27066-0
Result  fail

Title   Disable SSH Support for .rhosts Files
Rule    sshd_disable_rhosts
Ident   CCE-27035-5
Result  pass

Title   Disable Host-Based Authentication
Rule    disable_host_auth
Ident   CCE-26870-6
Result  pass

Title   Disable SSH Root Login
Rule    sshd_disable_root_login
Ident   CCE-26946-4
Result  fail

Title   Disable SSH Access via Empty Passwords
Rule    sshd_disable_empty_passwords
Ident   CCE-26864-9
Result  fail

Title   Enable SSH Warning Banner
Rule    sshd_enable_warning_banner
Ident   CCE-27314-4
Result  fail

Title   Do Not Allow SSH Environment Options
Rule    sshd_do_not_permit_user_env
Ident   CCE-26974-6
Result  fail

Title   Use Only Approved Ciphers
Rule    sshd_use_approved_ciphers
Ident   CCE-27051-2
Result  fail

All of those partition rules (Atomic uses it's own partition layout), gpgcheck related rules (Atomic doesn't use yum to install updates), aide rules (not possible to install aide rpm in Atomic in "traditional way"), SELinux rules (as Dan clarified above even checking SELinux wouldn't be trivial to perform in Atomic), from the other rules all of:

would be irrelevant on the clean Atomic system (of course if the container would run sshd service those sshd rules might be applicable).

When you take out all the rules that would be irrelevant / not applicable to RHEL-7 Atomic system, you would get the list of rules proposed above (some of them like gshadow / shadow checking ones could be kept yet). But RHT-CCP profile by default as is isn't usable for scanning RHEL-7 Atomic host (it checks also features which aren't available there by default).

Of course, if we would split the requirement to have two categories of these standard checks:

then agree it would make sense to use the 'RHT-CCP' profile for the first group, then the "minimal standard security base" profile for the second group.

iankko commented 9 years ago

@rhatdan I talked to Peter V and @shawndwells at the summit, and the next step after we got a scan for containers, would be to package the scan and content up into a container image. We would need a SPC that could scan all container images on the service

atomic run scapscan

Would download an scapscan image and run it in scan mode. It would need to have the atomic command and docker in the image, and probably mount /run into the container. The atomic team would probably need to work with the scap team to make this work.

@rhatdan What to go even further with this? -- My understanding of the original request is that we want something like standard security base profile to have following properties:

Once we got such a profile why not to request it:

Once we have got such a optimized profile able to finish in ~10 seconds (the whole RHT-CCP profile now finishes in ~15 seconds), why not to modify the RHEL-7 initscripts / boot sequence so the scan would be run each time as part of the boot sequence? (for RHEL-7 Atomic maybe modify rpm-ostree to include it by default?)

iankko commented 9 years ago

@bkearney Do you envision the output of this to be its own ARF report, or put into the ARF for the host it is on?

IMHO this basic system content sanity scan from security PoV should produce it's own / separated report regardless of the content which is installed on the final system (separated from subsequent scans of final rpm packages installed on "traditional" RHEL-7 system, separated from subsequent scans of RHEL-7 Atomic build, and separated from possible subsequent scans of underlying's container content). Therefore the set of rules it would contain would be universal enough to run everywhere, while simultaneously being able to report critical misconfigurations (like empty passwords in /etc/passwd, or some unknown SUID binary present on the system etc.)

Maybe it's pretty high expectation, but basically it should be viewed like message if the underlying system is safe to be used right after boot, or not. And if not, which concrete deficiency needs to be fixed yet before the: 1) traditional RHEL-7 system 2) cloud RHEL-7 image 3) RHEL-7 Atomic system 4) particular container can be used for their originally intended purposes (like custom content to be installed there and possible subsequent content scans to be performed against desired profiles).

bkearney commented 9 years ago

@rhatdan Arf report is the output which can be aggregated and viewed to know if a machine is in compliance or not.

@iankko IANAA (I am not an auditor) but I would assume auditors would want to know if a running system is compliant, not just at boot time. As I said, scanning at rest is great.. but I would assume scanning at runtime and aggregating to the host is also required as some point.

rhatdan commented 9 years ago

@rhatdan What to go even further with this? -- My understanding of the original request is that we want something like standard security base profile to have following properties:

it to be small (contain 10-15 rules at most) to perform / finish quickly,
it to scan basic security sanity of the system (is system up2date wrt to security patches, all are SUID/SGID binaries coming exclusively from official image, are there world writable files etc.),
it should finish with "green" state,
if it wouldn't finish with "green" state it should indicate, there's really something wrong with the underlying system (unauthorized SUID file for example), and such a system shouldn't be used till the issue isn't fixed

Once we got such a profile why not to request it:

to be run on each RHEL-7 Atomic system during system boot? ,

I would not want the scan to slow down boot, so having it run in the back ground or as a cron job would be fine. to be run on each RHEL-7 "traditional" system during system boot for the case that system isn't persistent server (IOW rather than running permanently it's started & shutdown frequently) ?, to be run regularly on RHEL-7 standalone server?

Yes.

Once we have got such a optimized profile able to finish in ~10 seconds (the whole RHT-CCP profile now finishes in ~15 seconds), why not to modify the RHEL-7 initscripts / boot sequence so the scan would be run each time as part of the boot sequence? (for RHEL-7 Atomic maybe modify rpm-ostree to include it by default?) I would prefer to run this in a container on Atomic, since the content would need to be updated quickly if a new CVE happened. We don't want people to have to reboot to a newer OS in order to realise then need to update. :^)

But I think we have come to the understanding that we would need 2 profiles, one for standard RHEL7/Atomic systems, and one for RHEL7 based container images. I would see the container as being having both content descriptions in it.

rhatdan commented 9 years ago

@bkearney I do have a concern that this ARF report is auditor centric. I would want the report to be something that is simple for an admin to read and understand. Not a long report. It should be one page of what is wrong with the system, not a lot of information about what is right with the problem buried on page 15.

It would be nice if this data was in the admins face when he logs into the system like /etc/motd, although I am not sure we would want non admins seeing it. Visible in cockpit eventually also.

SYSTEM is in GREEN|YELLOW|READ state. Read /var/log/scapscan for further info.

Perhaps talk to a UI expert on the report.

iankko commented 9 years ago

@rhatdan

But I think we have come to the understanding that we would need 2 profiles, one for standard RHEL7/Atomic systems, and one for RHEL7 based container images. I would see the container as being having both content descriptions in it.

Just to clarify - in the future there are dedicated / more specific RHEL-7 Atomic product (to scan e.g. proper settings of security options of docker daemon etc.), and dedicated container profiles (e.g. to verify used cgroup, namespaces, capabilities settings) planned to be implemented (in upcoming quarters). Therefore I am taking this request as request for yet another base security settings scan (minimized, having just universal rules), which would be applied:

redhatrises commented 9 years ago

@iankko - why not use the CCP profile?

Hi Shawn, the problem with the RHT-CCP profile is that though it contains more rules (than proposed already) for "traditional" RHEL-7 system, it also contain rules which would be irrelevant / impossible to check on container image.

@rhatdan But I think we have come to the understanding that we would need 2 profiles, one for standard RHEL7/Atomic systems, and one for RHEL7 based container images. I would see the container as being having both content descriptions in it.

What about 'rht-atomic' for RHEL Atomic and 'rht-docker' or 'rht-container' for containers for profile(s)?

shreyankg commented 9 years ago

If the profile for Docker would have rules which are relevant across all containers (Docker, rkt, etc.) it should be called 'rht-container', otherwise if we expect new set of content for scanning non-Docker containers, we should go ahead with 'rht-docker'. Alternatively we could look at using a base content for containers ('rht-container'), being extended by 'rht-docker', 'rht-rkt' etc.

bkearney commented 9 years ago

@rhatdan tools like foreman_openscap are aggregating the ARF reports and proving that yellow, red, green type of reporting. That is why I was hoping to get it into ARF reports for both the image (container at rest) and host (container in use).

rhatdan commented 9 years ago

Sounds good to me. As long as the final report we generate for the customer is simple to understand for NON Security people.

rhatdan commented 9 years ago

rht-container rather then rht-docker, only use rht-docker for something very specific to docker. Not really sure what you would be scanning for though.

rhel7 and rhel7-atomic should share lots of content, Only scans for particular daemons should be different, since most daemons would not be running on atomic.

mpreisler commented 8 years ago

More activity related to this in #966

yuumasato commented 7 years ago

If I understand correctly this issues is about creating a profile to be run on a daily basis, and this profile should work with bare metal machines, containers and container images.

Now we have CPEs to identify and differentiate bare-metal and VMs (`cpe:/a:machine') from containers and container images ('cpe:/a:container'). This allows us to mark individual rules as relevant for machines or containers only, and should keep us away from the need for separate profiles for containers and container images. PR #1766 improves the standard profile with these new CPEs in mind.

I don't see anything keeping us from closing this. Am I missing something?

yuumasato commented 7 years ago

Closing this, if standard Profile is missing some Rule you consider important, please file an issue or open pull requests.