dev-sec / linux-baseline Goto Github PK

View Code? Open in Web Editor NEW

757.0 52.0 181.0 274 KB

DevSec Linux Baseline - InSpec Profile

Home Page: https://dev-sec.io/baselines/linux/

License: Apache License 2.0

Ruby 100.00%

inspec audit security devsec baseline hardening linux

linux-baseline's Introduction

DevSec Linux Baseline

This Compliance Profile ensures that all hardening projects keep the same quality.

Standalone Usage

This Compliance Profile requires InSpec for execution:

$ git clone https://github.com/dev-sec/linux-baseline
$ inspec exec linux-baseline

You can also execute the profile directly from Github:

$ inspec exec https://github.com/dev-sec/linux-baseline

License and Author

Author:: Patrick Muench [email protected]
Author:: Dominik Richter [email protected]
Author:: Christoph Hartmann [email protected]
Author:: Edmund Haselwanter [email protected]
Copyright 2014-2021, The Hardening Framework Team

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

linux-baseline's People

Contributors

Stargazers

Watchers

Forkers

ehaselwanter chris-rock mikemoate shadabrd netflash yo61 srjayep juju4 rx007 techraf jszalkowski rdeusser rbramwell artem-forks atomic111 bitvijays actionjack kidbrax mcgege lnxchk dmccown henrythehamster manuelprinz chunjie 5up3rc kentondrake-kaiser rndmh3ro unitedtraders acl-services icute1349 tomhaynes kmf lirany1 anniehedgpeth lhasadreams guoyu07 sydfx filipposm karnauskas nathenharvey james-stocks mansong1 tianer1211 frederikbosch yanggongwang juliandunn kmcquade flexboy rmegens skylerto kskrisss chaitu-papa openshift-training z0x010 yqyunjie cachedout rizky-musthofa decisiv wheelq smford22 sbonds hieunba neatnerdprime rquinones93 prince0205 piano-wow karthik137 motusllc lukelucode artithw 0x6b7966 jjasghar bixu walker233 kclinden ascdso2020 vvijjada szliuyujie b-dean rlig rudikza lbalak50 sysnap2012 sjain07p alexbmw00 pirenga digifors mvisonneau syncfunction kumardineshwar jeanmonet amirulaliwl moisestapia tundeajibade orange888 majma24 cybert3ch nevermin danielschlegel jammicus

linux-baseline's Issues

sysctl-34 - fs.protected_regular is Ubuntu specific

Hello!

Please refer to issue reported with ansible-collection-hardening : dev-sec/ansible-collection-hardening#536

From above note it can be understood that Kernel parameter fs.protected_regular is Ubuntu specific.
But Inspec is checking for this parameter (control sysctl-34) in our CentOS instance, and failing:

11:15:03 CentOS 7: × sysctl-34: Ensure links are protected (1 failed)
11:15:03 CentOS 7: ✔ Kernel Parameter fs.protected_fifos value is expected to match (cmp nil)
11:15:03 CentOS 7: ✔ Kernel Parameter fs.protected_hardlinks value is expected to eq 1
11:15:03 CentOS 7: × Kernel Parameter fs.protected_regular value is expected to eq 2
11:15:03 CentOS 7:
11:15:03 CentOS 7: expected: 2
11:15:03 CentOS 7: got: nil
11:15:03 CentOS 7:
11:15:03 CentOS 7: (compared using ==)

See: https://github.com/dev-sec/linux-baseline/pull/160/files

I believe fs.protected_regular parameter must be excluded from centos/redhat distros.
Could you take a look please. This is breaking one of our image build pipelines.

@rndmh3ro @schurzi @chris-rock

Thank you!

Duplicate testing for telnetd instead of rsh

https://github.com/dev-sec/linux-baseline/blob/master/controls/package_spec.rb#L39-L55

package-02 and package-03 seem to both be testing for telnetd, but seems like it intends to test for rsh.

control 'package-02' do
  impact 1.0
  title 'Do not install Telnet server'
  desc 'Telnet protocol uses unencrypted communication, that means the password and other sensitive data are unencrypted. http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf, Chapter 3.2.2'
  describe package('telnetd') do
    it { should_not be_installed }
  end
end

control 'package-03' do
  impact 1.0
  title 'Do not install rsh server'
  desc 'The r-commands suffers same problem as telnet. http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf, Chapter 3.2.3'
  describe package('telnetd') do
    it { should_not be_installed }
  end
end

New release

Can you trigger a new release please ?

The current one is 6 months behind the master branch.

disable rpcbind

Is your feature request related to a problem? Please describe.
I received a notice of a open rpcbind port on my fresh installed Debian 10.6 system yesterday.
The rpcbind port is normally used for nfs mounts. In hacks this port 111 is mostly used for ddos reflection attacks.

Describe the solution you'd like
I would like a variable which controls if the port is closed or not. The variable could set if the service is stopped and disabled or started and enabled.

Describe alternatives you've considered
An alternative would be to get a list of services you want to disable by default. Maybe there is another daemon like avahi-daemon or cups.

Additional context
If you need more information, just reply.

Add file system checks for other shadow and passwd/group files

Is your feature request related to a problem? Please describe.
We currently have os-02 and os-03 which checks the permissions of /etc/shadow and /etc/passwd.

There are other files related to those, which are currently ignored:

/etc/shadow- (backup for /etc/shadow
/etc/gshadow (might contain group password hashes)
/etc/gshadow- (backup for /etc/gshadow)
/etc/passwd- (backup for /etc/passwd)
/etc/group (contains available groups and memberships)
/etc/group- (backup for /etc/group)

Describe the solution you'd like
Add checks for those files as well

Ensure links are protected

Is your feature request related to a problem? Please describe.
Currently linux-baseline does not check if link protection is enabled.

Describe the solution you'd like
Create a additional check for those sysctls:

fs.protected_fifos == 1 or 2
fs.protected_hardlinks == 1
fs.protected_regular == 2
fs.protected_symlinks == 1

Additional context
Unprotected symlinks are a long-standing cause for security issues. See the official kernel docs about this.

Those settings should be default on most current Linux distributions, but it still makes sense to check those. Other security check projects like Lynis already checks those as well. See here

Deprecation of contain_duplicates in inspec

[DEPRECATION] `contain_duplicates` is deprecated and will be removed for InSpec 1.0. See https://github.com/chef/inspec/issues/738 for more details
[DEPRECATION] `contain_duplicates` is deprecated and will be removed for InSpec 1.0. See https://github.com/chef/inspec/issues/738 for more details

Related issue: inspec/inspec#738

The related code is in the os_spec.rb

Remove package-07 test

I propose to remove package-07 test:

control 'package-07' do
  impact 1.0
  title 'Install syslog server package'
  desc 'Syslog server is required to receive system and applications logs'
  # Fedora doesn't install with a syslogger out of the box and instead uses
  # systemd journal; as there is there is no affinity towards either rsyslog
  # or syslog-ng, we'll skip this check on Fedora hosts.
  only_if { os.name != 'fedora' && !container_execution }
  describe package(val_syslog_pkg) do
    it { should be_installed }
  end
end

Reasons:

Most modern OS use journald instead of syslog now
Merely having syslog installed does not provide any additonal security. Logs should be send to another system to make them temper-proof. If they only exist on the server where they originated, an attacker can easily alter them.
Since there are a myriad of options available to send logs to other systems, I see no easy and reliable way to test wether logs are sent to another sytem.

Remove control 'os-08' because entropy is always at 256

Is your feature request related to a problem? Please describe.
inspec is failing at the control 'os-08' step on most of the newer kernels. This happened because of changes in newer Linux versions to RNG’s crypto and backports to older LTS Kernels. Basically, the entropy_avail number is now meaningless.

Describe the solution you'd like
Remove the control check os-08 here: https://github.com/dev-sec/linux-baseline/blob/master/controls/os_spec.rb#L230

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
see here:
https://askubuntu.com/questions/1427470/entropy-is-stuck-at-256-after-upgrading-to-kernel-5-15-0-47

package-08 error on amazon linux

Amazon recently updated their platform_family from "rhel" to "amazon". With this change the package-08 control is now broken for amazon linux.

The package-08 control is set to look for an auditd package on all os flavors save for rhel and suse.

Please add "amazon" to the list of os platforms to use the "audit" package.

systctl-33 - undefined method `expect'

Describe the bug

After updating inspect from 3.0.25 to 3.0.42 we have started to see an issue with undefined method `expect' and tests fail

Expected behavior
the test should finish successfully

Actual behavior

sudo inspec exec https://github.com/dev-sec/linux-baseline

    amazon-ebs:   ✔  sysctl-32: kernel.randomize_va_space
    amazon-ebs:      ✔  Kernel Parameter kernel.randomize_va_space value should eq 2
    amazon-ebs:   ×  sysctl-33: CPU No execution Flag or Kernel ExecShield
    amazon-ebs:      ×  /proc/cpuinfo Flags should include NX
    amazon-ebs:      undefined method `expect' for #<RSpec::ExampleGroups::ProcCpuinfo:0x0000000002d70508>
    amazon-ebs:
    amazon-ebs:
    amazon-ebs: Profile Summary: 52 successful controls, 1 control failure, 1 control skipped
    amazon-ebs: Test Summary: 124 successful, 1 failure, 1 skipped
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: Destroying volume (vol-0971ba41c98f72259)...
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' errored: Script exited with non-zero exit status: 1

grep nx /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 ida arat pku ospke

OS / Environment

cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

Inspec Version

3.0.25 - finishes with success
3.0.42 - fails

Baseline Version

latest 
https://github.com/dev-sec/linux-baseline/commit/149a2589ab08a135461986c878205669d4df2f33

Additional context
building AWS machine image with packer and testing it with inspect

SUCCES
	{
	    "type": "shell",
	    "inline": ["sudo sh inspec/install.sh -v 3.0.25 -P inspec"]
	},
	{
	    "type": "shell",
	    "inline": ["sudo inspec exec https://github.com/dev-sec/linux-baseline"]
	},

FAILURE
	{
	    "type": "shell",
	    "inline": ["sudo sh inspec/install.sh -P inspec"]
	},
	{
	    "type": "shell",
	    "inline": ["sudo inspec exec https://github.com/dev-sec/linux-baseline"]
	},

Container conditions to skip tests?

I'm start running puppet-os-hardening and testing inside travis and kitchen/docker.

I have tests failing while using base module without any customization while fully working on upstream (travis digitalocean or VM).
I fully expect some tests to fail inside docker because some sysctl are not allowed or systemd daemons start/stop/restart not working.

Is there a condition that can be added to skip test if inside docker?
like ansible virtualization fact

Looking at tests
(centos7) https://travis-ci.org/juju4/puppet-meta-harden-linux/jobs/417935981
(bionic) https://travis-ci.org/juju4/puppet-meta-harden-linux/jobs/417935982
(centos7) https://travis-ci.org/juju4/puppet-meta-harden-linux/jobs/420516104#L2823
(bionic) https://travis-ci.org/juju4/puppet-meta-harden-linux/jobs/420516105#L3408

Thanks

CI: run linux-baseline with master branch of chef-os-hardening

See this discussion.

We should have a CI job here with master branch of chef-os-hardening

permissions /etc/shadow

The default permissions for /etc/shadow are:

Debian/Ubuntu:

root@986e440df792:/home/kitchen# ll /etc/shadow
-rw-r----- 1 root shadow 683 May 23 15:43 /etc/shadow

see https://help.ubuntu.com/community/FilePermissions

RHEL:

[root@b5704779e84f kitchen]# ll /etc/shadow
---------- 1 root root 670 Mar 23 17:20 /etc/shadow

see https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2013-02-05/finding/RHEL-06-000035

The Deutsche Telekom security assesment process (which this hardening project loosely follows) proposes:

Passwords must be stored only as hashes (bcrypt, scrypt), never in clear text. Files containing password hashes must be protected against unauthorized access.

Motivation: Passwords are in need of protection that only account owners or authorized persons may know and change. This measure is designed to ensure that unauthorized persons cannot gain knowledge of these passwords or have the chance to change them.

Implementation example: For system passwords, the file /etc/shadow shall be used in Linux. For other operating systems, the respectiveequivalent file shall be used, which is only readable for the root and only contains the hashes of the systempasswords.

In my opinion we should follow the operating-system standards here.
On rhel-based systems the os-standards are even safer than the standards in this repo.

control os-10 fails (/etc/modprobe.d/dev-sec.conf)

Guys,

From where does /etc/modprobe.d/dev-sec.conf come from? The control os-10 fails on all my linux nodes (Ubuntu 16.04, CentOS 7.3 and Amazon Linux), I just can't find any reference for it

control 'os-10' do
impact 1.0
title 'CIS: Disable unused filesystems'
desc '1.1.1 Ensure mounting of cramfs, freevxfs, jffs2, hfs, hfsplus, squashfs, udf, FAT'
describe file('/etc/modprobe.d/dev-sec.conf') do
its(:content) { should match 'install cramfs /bin/true' }
its(:content) { should match 'install freevxfs /bin/true' }
its(:content) { should match 'install jffs2 /bin/true' }
its(:content) { should match 'install hfs /bin/true' }
its(:content) { should match 'install hfsplus /bin/true' }
its(:content) { should match 'install squashfs /bin/true' }
its(:content) { should match 'install udf /bin/true' }
its(:content) { should match 'install vfat /bin/true' }
end
end

Best,

Audit Daemon Fails on Amazon Linux 2

Describe the bug
Tested against chef-os-hardening.

Expected behavior
Tests should pass.

Actual behavior
Tests fail.

$ kitchen verify
-----> Starting Kitchen (v1.24.0)
-----> Verifying <default-amazon2-2018>...
[2019-01-28T16:29:48+00:00] WARN: URL target https://github.com/dev-sec/linux-baseline transformed to https://github.com/dev-sec/linux-baseline/archive/master.tar.gz. Consider using the git fetcher
       Loaded linux-baseline 

Profile: DevSec Linux Security Baseline (linux-baseline)
Version: 2.2.2
Target:  ssh://[email protected]:22

<tests passing...>

  ✔  package-07: Install syslog server package
     ✔  System Package rsyslog should be installed
  ×  package-08: Install auditd (1 failed)
     ✔  System Package audit should be installed
     ✔  Audit Daemon Config log_file should cmp == "/var/log/audit/audit.log"
     ✔  Audit Daemon Config log_format should cmp == "raw"
     ✔  Audit Daemon Config flush should match /^INCREMENTAL|INCREMENTAL_ASYNC$/
     ×  Audit Daemon Config max_log_file_action should cmp == "keep_logs"
     
     expected: "keep_logs"
          got: "ROTATE"
     
     (compared using `cmp` matcher)

     ✔  Audit Daemon Config space_left should cmp == 75
     ✔  Audit Daemon Config action_mail_acct should cmp == "root"
     ✔  Audit Daemon Config space_left_action should cmp == "SYSLOG"
     ✔  Audit Daemon Config admin_space_left should cmp == 50
     ✔  Audit Daemon Config admin_space_left_action should cmp == "SUSPEND"
     ✔  Audit Daemon Config disk_full_action should cmp == "SUSPEND"
     ✔  Audit Daemon Config disk_error_action should cmp == "SUSPEND"
  ✔  package-09: CIS: Additional process hardening

<tests passing...>

Profile Summary: 52 successful controls, 1 control failure, 1 control skipped
Test Summary: 124 successful, 1 failure, 1 skipped
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Verify failed on instance <default-amazon2-2018>.  Please see .kitchen/logs/default-amazon2-2018.log for more details
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

aws-runas.main 2019/01/28 16:30:07 [CRIT] ▶ exit status 20

Example code

Policy File

# Policyfile.rb - Describe how you want Chef to build your system.
#
# For more information on the Policyfile feature, visit
# https://docs.chef.io/policyfile.html

# A name that describes what the system you're building with Chef does.
name "base-ami"

# This lets you source cookbooks from your chef-repo.
default_source :chef_repo, "cookbooks"

# Where to find external cookbooks:
default_source :supermarket

# run_list: chef-client will run these recipes in the order specified.
run_list "os-hardening"


cookbook "os-hardening"
# Specify a custom source for a single cookbook:
# cookbook 'example_cookbook', path: '../cookbooks/example_cookbook'

.kitchen.yml

---
driver:
  name: ec2
  region: eu-west-1
  instance_type: t2.micro
  shared_credentials_profile: <profile>
  iam_profile_name: <iam_profile_name>
  tags:
    Name: KitchenEC2-Base-AMI
    created-by: kitchen-ec2

provisioner:
  name: chef_zero
  always_update_cookbooks: true

verifier:
  name: inspec

platforms:
  - name: amazon2-2018

suites:
  - name: default
    verifier:
      inspec_tests:
        - supermarket://dev-sec/linux-baseline

OS / Environment

Inspec Version

$ inspec --version
3.2.6

Your version of InSpec is out of date! The latest version is 3.3.14.

Baseline Version

2.2.2

Additional context
Using the kitchen-ec2 test driver.

Support for validation of cpu vulnerabilities

Is your feature request related to a problem? Please describe.

There are several CPU vulnerabilities, where the fixes expose via sysfs the state of protection. E.g. /sys/devices/system/cpu/vulnerabilities/mds for new MDS vulnerability.

Describe the solution you'd like

This baseline should include the validation of this options.

os-10: CIS: Disable unused filesystems (1 failed)

Describe the bug
Ubuntu 18.04 image is failing after running https://github.com/dev-sec/ansible-os-hardening

Expected behavior
Checks should pass

Actual behavior

×  os-10: CIS: Disable unused filesystems (1 failed)
     ✔  File /etc/modprobe.d/dev-sec.conf content should match "install cramfs /bin/true"
     ✔  File /etc/modprobe.d/dev-sec.conf content should match "install freevxfs /bin/true"
     ✔  File /etc/modprobe.d/dev-sec.conf content should match "install jffs2 /bin/true"
     ✔  File /etc/modprobe.d/dev-sec.conf content should match "install hfs /bin/true"
     ✔  File /etc/modprobe.d/dev-sec.conf content should match "install hfsplus /bin/true"
     ×  File /etc/modprobe.d/dev-sec.conf content should match "install squashfs /bin/true"
     expected "#\n# Ansible managed\n#\n\ninstall cramfs /bin/true\ninstall freevxfs /bin/true\ninstall jffs2 /bin/...ue\ninstall tipc /bin/true\ninstall sctp /bin/true\ninstall dccp /bin/true\ninstall rds /bin/true\n" to match "install squashfs /bin/true"
     Diff:
     @@ -1,2 +1,16 @@
     -install squashfs /bin/true
     +#
     +# Ansible managed
     +#
     +
     +install cramfs /bin/true
     +install freevxfs /bin/true
     +install jffs2 /bin/true
     +install hfs /bin/true
     +install hfsplus /bin/true
     +install udf /bin/true
     +install vfat /bin/true
     +install tipc /bin/true
     +install sctp /bin/true
     +install dccp /bin/true
     +install rds /bin/true

OS / Environment
Ubuntu 18.04

Inspec Version

3.7.11

Baseline Version

2.4.6

Additional context
Seems to have broken last night with no changes

Deprecation Warnings

I see these warning messages in kitchen-inspec tests of puppet-os-hardening:

WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/os_spec.rb:20)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/os_spec.rb:22)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/os_spec.rb:23)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/os_spec.rb:24)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/os_spec.rb:34)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/package_spec.rb:20)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/sysctl_spec.rb:20)
WARN: DEPRECATION: The 'default' option for attributes is being replaced by 'value' - please use it instead. attribute name: 'Inspec::Input' (used at linux-baseline-master/controls/sysctl_spec.rb:21)

Inspec: 4.3.2
Kitchen-Inspec: 1.1.0

Test verification for package removal

We need to test a default setting for package removal, since the current state my be a little bit confusing for hardening implementors. See the following discussions:

Currently, we decided to set the default for package removal to true:

default[:security][:packages][:clean] = true

os-11 fails on vanilla Ubuntu 16.04/18.04

Tested with ansible-os-hardening

Expected behavior:

os-11 should succeed on vanilla Ubuntu 16.04/18.04 (at least after running ansible-os-hardening)

Actual behavior:

os-11 fails due to group permission

×  os-11: Protect log-directory (1 failed)
✔  File /var/log should be directory
✔  File /var/log should be owned by "root"
×  File /var/log should be grouped into "syslog"
expected `File /var/log.grouped_into?("syslog")` to return true, got false

Details

The package rsyslog is not installed by default on Ubuntu 16.04 or 18.04 resulting in /var/log being grouped into root instead of syslog. For Ubuntu 14.04 it was still the default, therefore it is working correctly there.

$ docker run -it ubuntu:14.04 ls -ld /var/log
drwxrwxr-x 5 root syslog 4096 Aug  7 06:18 /var/log
$ docker run -it ubuntu:16.04 ls -ld /var/log
drwxr-xr-x 4 root root 4096 Aug  8 02:03 /var/log
$ docker run -it ubuntu:18.04 ls -ld /var/log
drwxr-xr-x 3 root root 4096 Aug 21 21:12 /var/log

Using Kitchen on ansible-os-hardening succeeds because the used Docker images by rndmh3ro include rsyslog: https://github.com/rndmh3ro/docker-ansible/blob/master/ubuntu1604-ansible-latest/Dockerfile#L9

Suggested fix

https://github.com/dev-sec/linux-baseline/blob/master/controls/os_spec.rb#L21 should only apply to 14.04 and use root otherwise (this will break compatibility with rndmh3ro Docker images and rsyslog installations)

Check whether /var/log is owned by either root or syslog (this will keep compatibility with rndmh3ro Docker images and rsyslog installations)

systctl-33 doesn't see nx flag

sysctl-33 appears to have been broken by commit 085b428.

The change from assignment_re to assignment_regex appears to have made it stop recognizing the presence of the nx flag, causing the test to fail.

  ×  sysctl-33: CPU No execution Flag or Kernel ExecShield (1 failed)
     ×  /proc/cpuinfo Flags should include NX
     expected [] to include "nx"
     ✔  Kernel Parameter kernel.exec-shield value should eq 1

This is what the flags string looks like on a sample CentOS 6 host:

$ grep nx /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good xtopology nonstop_tsc pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx rdrand lahf_lm abm

Edit: For clarity, this might be a change that's related to the inspec version? We're currently on chefdk 1.2.22, which ships with inspec 1.11.0.

Default umask 077/027 leads into several problems installing software packages

linux-baseline/controls/os_spec.rb

Line 20 in 85bc5a3

 login_defs_umask = attribute('login_defs_umask', value: os.redhat? ? '077' : '027', description: 'Default umask to set in login.defs') 

Hi,
may you explain what's the purpose for this default umask?
It lead me in problems especially installing python modules via pip after applying the ansible remediation role "dev-sec/os-hardening".
After installing them they are not usable by unprivileged users. Ubuntu has group "staff" set on /usr/local/lib/python3.8/dist-packages/ thus one way might be to add all users that are allowed to use that python modules to the "staff" group. Or - I change back the umask-default to usual 022.

What is your recommendation?

Timeout issue with NFS mounts - Don't transverse file system

We are seeing timeout issues on control os-06

linux-baseline/controls/os_spec.rb

Line 180 in 60ae1a5

control 'os-06' do

when transversing the file system hits an NFS mount. The result is a timeout error of mixlibshellout exceeding 600s.

[2017-08-09T03:35:28+00:00] ERROR: Report handler Chef::Handler::AuditReport raised #<Mixlib::ShellOut::CommandTimeout: Command timed out after 600s:
Command exceeded allowed execution time, process terminated
---- Begin output of find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' ----
STDOUT:
STDERR:
---- End output of find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' ----
Ran find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' returned >

Is there a better way to do this control?

Support for ESXi

Is your feature request related to a problem? Please describe.
I would like to use Inspec to validate the configuration of ESXi

Describe the solution you'd like
Utilizing Inspec validate that a ESXi system is hardened appropriately.

Describe alternatives you've considered
Looked into create SCAP content. This looked very painful.

Additional context
Ideally I would like to create this for DISA STIGs eventually.

check for audit(d) fails on aws linux ami

It seems a more robust check is need to include AWS linux. For example this fails on Linux AMI evne though audit is installed,

linux-baseline/controls/package_spec.rb

Line 83 in 58810fe

audit_pkg = os.redhat? ? 'audit' : 'auditd'

/etc/shadow permissions false positive on Fedora

Hi,
permissions of /etc/shadow are like the ones RedHat uses (000)

796724 ----------. 1 root root 1321 Dec 24 02:40 /etc/shadow

Unfortunately os.redhat? is not true for Fedora systems, so the control fails. I'll work on PR (which should be only checking the os.name)

False positives in control os-06

command('find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' -print 2>/dev/null | grep -v '^find:'')
If I create an empty file and chmod 7777 empty_file (I know it's a stupid thing to do, but users do it on my systems), it comes up positive. But it's not an executable file format. Also, when this find is run as root, it traverses directories inaccessible to non-root users and reports files that may not be visible to or accessible by non-root users. (If a file is suid or sgid root and is only accessible by or executable by root is it a problem?) I know this is nitpicking, but the (non-chef) compliance check run against my systems by corporate central monitoring keeps requiring me to fix these non-problems. It would be great if moving to chef removed these issues rather than perpetuating them.
Simon

Issue after upgrading to the latest version of Inspec.

Describe the bug
Issue with uploading inspec profile to Chef Automate after Inspec upgrade from 3.5.0 to 4.16.0

Expected behavior
It should work at the same way like 3.5.0

Actual behavior

d/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	22: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	21: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/plugins/inspec-compliance/lib/inspec-compliance/cli.rb:161:in `upload'
	20: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:421:in `check'
	19: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:451:in `controls_count'
	18: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:195:in `params'
	17: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:597:in `load_params'
	16: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:604:in `load_checks_params'
	15: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:202:in `collect_tests'
	14: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:63:in `each'
	13: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:63:in `each'
	12: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:64:in `block in each'
	11: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:202:in `collect_tests'
	10: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:63:in `each'
	 9: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:63:in `each'
	 8: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dependencies/dependency_set.rb:64:in `block in each'
	 7: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:204:in `collect_tests'
	 6: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:204:in `each'
	 5: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile.rb:208:in `block in collect_tests'
	 4: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile_context.rb:145:in `load_control_file'
	 3: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile_context.rb:161:in `load_with_context'
	 2: from /opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/profile_context.rb:161:in `instance_eval'
	 1: from /root/.inspec/cache/74df8a2d5a90a0a85d649450f2aaf36d06e91eb4/controls/os_spec.rb:29:in `load_with_context'
/opt/inspec/embedded/lib/ruby/gems/2.6.0/gems/inspec-4.16.0/lib/inspec/dsl.rb:47:in `method_missing': undefined local variable or method `virtualization' for #<#<Class:0x00000000067e7e48>:0x00000000067e7538> (NameError)

Example code

inspec compliance upload linux-profile --overwrite

OS / Environment

MacOS, Centos7

Inspec Version

[root@default-centos7 inspec-4.16.0]# inspec --version
4.16.0

Baseline Version

Additional context
It works properly wit 3.5.0 version. I've tested it with 4.7.3 and 4.16.0 - the same issue.
If additional information required - please let me know.

sysctl-19 should check the sysctl_forwarding attribute

Describe the bug
when the sysctl_forwarding attribute is set to true, the sysctl-19 (IPv6 Forwarding) fails.

Expected behavior
It seems like it should behave like sysctl-01 (IPv4 Forwarding) which only runs when sysctl_forwarding is false

Actual behavior

×  sysctl-19: IPv6 Forwarding
   ×  Kernel Parameter net.ipv6.conf.all.forwarding value is expected to eq 0

   expected: 0
        got: 1

   (compared using ==)

Example code
My specific example is in the context of my packer build and kitchen test for a private RHEL 7 AMI, so I can't share that. But it seems like these steps should reproduce the error:

Create a file inputs.yml with:

inputs:
  - name: sysctl_forwarding
    value: true

Then run:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo sysctl --system
inspec exec  --input-file inputs.yml https://github.com/dev-sec/linux-baseline

OS / Environment
Running inspec via test-kitchen to test an AMI built with packer. The AMI being tested by the linux-baseline is running RHEL 7.7

Inspec Version

3.9.3

Baseline Version

2.3.0 from master (eb81362)

Additional context
In the chef-os-hardening::sysctl recipe, allowing forwarding, allows it for both IPv4 and IPv6
https://github.com/dev-sec/chef-os-hardening/blob/e993020bb2f0b0538c16167c06694e916c854fba/recipes/sysctl.rb#L48-L51

linux-baseline os-06 can not be skipped

OS-06 can't be skipped, because skip_control only skips what's in "describe", from what I understand. Anyway, if you try and skip OS-06, it still runs the find on the target server, just the result doesn't show up in the report.

Also, given it's a reasonable test to do (checking for setuid root), could we add a -xdev (do not descend into other file systems). Not many servers have their common binaries on a separate mount than /, but do have many very large mounts of local or network drives. A find that descends across mounts can take a very long time to run, even to the point where it can disrupt service (especially on glusterfs bricks).

Control Sysctl 31-b from sysctl_spec.rb causing Inspec to exit with error code

The systctl 31-b control is being skipped in the environment in which I am running the test, though it is being skipped, inspec seems to return an error code of 123 with packer

Permission search takes too long

Customers reported that the find permission command takes too long. We should find a solution to do this faster.

Running handlers:
[2017-03-16T13:17:19-04:00] INFO: Running report handlers
[2017-03-16T13:17:19-04:00] WARN: Format is json
[2017-03-16T13:17:19-04:00] INFO: Initialize InSpec
[2017-03-16T13:17:20-04:00] WARN: URL target https://github.com/dev-sec/linux-baseline transformed to https://github.com/dev-sec/linux-baseline/archive/master.tar.gz. Consider using the git fetcher
[2017-03-16T13:17:20-04:00] INFO: Running tests from: [{:name=>"linux-baseline", :supermarket=>"dev-sec/linux-baseline"}]
 
 
 
 
 
 
[2017-03-16T13:27:30-04:00] ERROR: Report handler Chef::Handler::AuditReport raised #<Mixlib::ShellOut::CommandTimeout: Command timed out after 600s:
Command exceeded allowed execution time, process terminated
---- Begin output of find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' ----
STDOUT:
STDERR:
---- End output of find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' ----
Ran find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' ! -path '/var/lib/lxd/containers/*' -print 2>/dev/null | grep -v '^find:' returned >
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/mixlib-shellout-2.2.7/lib/mixlib/shellout/unix.rb:124:in `run_command'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/mixlib-shellout-2.2.7/lib/mixlib/shellout.rb:259:in `run_command'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/train-0.22.1/lib/train/transports/local.rb:32:in `run_command'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/resources/command.rb:31:in `result'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/resources/command.rb:35:in `stdout'
[2017-03-16T13:27:30-04:00] ERROR: linux-baseline-master/controls/os_spec.rb:193:in `block in load_with_context'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/rule.rb:51:in `instance_eval'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/rule.rb:51:in `initialize'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/control_eval_context.rb:71:in `new'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/control_eval_context.rb:71:in `block (2 levels) in create'
[2017-03-16T13:27:30-04:00] ERROR: linux-baseline-master/controls/os_spec.rb:187:in `load_with_context'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile_context.rb:146:in `instance_eval'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile_context.rb:146:in `load_with_context'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile_context.rb:130:in `load_control_file'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile.rb:144:in `block in collect_tests'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile.rb:141:in `each'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/profile.rb:141:in `collect_tests'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/runner.rb:90:in `block in load'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/runner.rb:79:in `each'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/runner.rb:79:in `load'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/inspec-1.15.0/lib/inspec/runner.rb:100:in `run'
[2017-03-16T13:27:30-04:00] ERROR: /var/chef/cache/cookbooks/audit/files/default/handler/audit_report.rb:116:in `call'
[2017-03-16T13:27:30-04:00] ERROR: /var/chef/cache/cookbooks/audit/files/default/handler/audit_report.rb:47:in `block in report'
[2017-03-16T13:27:30-04:00] ERROR: /var/chef/cache/cookbooks/audit/files/default/handler/audit_report.rb:33:in `each'
[2017-03-16T13:27:30-04:00] ERROR: /var/chef/cache/cookbooks/audit/files/default/handler/audit_report.rb:33:in `report'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/handler.rb:259:in `run_report_unsafe'
[2017-03-16T13:27:30-04:00] ERROR: /var/chef/cache/cookbooks/audit/files/default/handler/audit_report.rb:59:in `run_report_safely'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/handler.rb:125:in `block in run_report_handlers'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/handler.rb:123:in `each'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/handler.rb:123:in `run_report_handlers'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/handler.rb:135:in `block in <class:Handler>'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/client.rb:441:in `block in run_completed_successfully'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/client.rb:440:in `each'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/client.rb:440:in `run_completed_successfully'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/client.rb:299:in `run'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:295:in `block in fork_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:283:in `fork'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:283:in `fork_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:248:in `block in run_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/local_mode.rb:44:in `with_server_connectivity'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:236:in `run_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application/client.rb:450:in `loop'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application/client.rb:450:in `interval_run_chef_client'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application/client.rb:434:in `run_application'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/lib/chef/application.rb:59:in `run'
[2017-03-16T13:27:30-04:00] ERROR: /opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.19.36/bin/chef-client:26:in `<top (required)>'
[2017-03-16T13:27:30-04:00] ERROR: /bin/chef-client:57:in `load'
[2017-03-16T13:27:30-04:00] ERROR: /bin/chef-client:57:in `<main>'
  - Chef::Handler::AuditReport
Running handlers complete
[2017-03-16T13:27:30-04:00] INFO: Report handlers complete
Chef Client finished, 1/11 resources updated in 10 minutes 26 seconds

Profile summary VS Test Summary

Hi there,

After launching the script/profile (how Am I supposed to call it ?)
I've the output that I was waiting for, the only thing that I couldn't understand is the difference between these two lines :

Normative specification as a benchmark in an audit - CIS or DISA

Is your feature request related to a problem? Please describe.
Currently, the project doesn't have a normative specification that can be used as a benchmark in an audit - we can use CIS or DISA . A security baseline standard should be a norm for auditing purposes.

Describe the solution you'd like
We could either add support for a baseline standard or mention deviations from it.

Here is the original issue raised in the ansible-os-hardening repo dev-sec/ansible-collection-hardening#76

Support for validation of cpu vulnerabilities (#114) needs further consideration...

Describe the bug

In closing-off issue #114, an additional check was added to search for the string [vV]ulnerable in files beneath /sys/devices/system/cpu/vulnerabilities - however, to be an effective test more nuance is needed.

The current checks are all based on the content of files which are present - but there appears to be no validation of files which must be present for the issue to be mitigated, but which aren't. It could be argued that it's unreasonable to assess an older image against flaws which weren't known when it was created - but that's exactly what's currently being done by reporting failures for hardware issues which can't be (entirely) fixed in software, such as the outstanding issues with Intel's SMT implementation.

See the Additional context section for further discussion.

Expected behavior

Failures are flagged (only) when a software mitigation is not present or not correctly deployed.

Actual behavior

Unfixable hardware errors are reported as failures, the opportunity exists for missing software mitigations to go unreported.

Amazon Linux 2, Ubuntu 20.04, Ubuntu 18.04:

amazon-ebs:   ×  os-12: Detect vulnerabilities in the cpu-vulnerability-directory (3 failed)
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/ is expected to be directory
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v2 content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v2 content is expected not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/itlb_multihit content is expected not to match "vulnerable"
amazon-ebs:      ×  File /sys/devices/system/cpu/vulnerabilities/itlb_multihit content is expected not to match "Vulnerable"
amazon-ebs:      expected "KVM: Vulnerable\n" not to match "Vulnerable"
amazon-ebs:      Diff:
amazon-ebs:      @@ -1 +1 @@
amazon-ebs:      -Vulnerable
amazon-ebs:      +KVM: Vulnerable
amazon-ebs: 
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/mds content is expected not to match "vulnerable"
amazon-ebs:      ×  File /sys/devices/system/cpu/vulnerabilities/mds content is expected not to match "Vulnerable"
amazon-ebs:      expected "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown\n" not to match "Vulnerable"
amazon-ebs:      Diff:
amazon-ebs:      @@ -1 +1 @@
amazon-ebs:      -Vulnerable
amazon-ebs:      +Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
amazon-ebs: 
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/l1tf content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/l1tf content is expected not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spec_store_bypass content is expected not to match "vulnerable"
amazon-ebs:      ×  File /sys/devices/system/cpu/vulnerabilities/spec_store_bypass content is expected not to match "Vulnerable"
amazon-ebs:      expected "Vulnerable\n" not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/tsx_async_abort content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/tsx_async_abort content is expected not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v1 content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v1 content is expected not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/srbds content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/srbds content is expected not to match "Vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/meltdown content is expected not to match "vulnerable"
amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/meltdown content is expected not to match "Vulnerable"

Ubuntu 16.04 also reports:

amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/tsx_async_abort content is expected not to match "vulnerable"
amazon-ebs:      ×  File /sys/devices/system/cpu/vulnerabilities/tsx_async_abort content is expected not to match "Vulnerable"
amazon-ebs:      expected "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown\n" not to match "Vulnerable"
amazon-ebs:      Diff:
amazon-ebs:      @@ -1 +1 @@
amazon-ebs:      -Vulnerable
amazon-ebs:      +Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
amazon-ebs:

OS / Environment

Amazon EC2 executing roles against Ubuntu 16.04LTS, 18.04LTS, 20.04LTS, Amazon Linux 2, CentOS 7 stock images - all of which fail since #138 was committed recently.

Inspec Version

4.23.15-1

Baseline Version

amazon-ebs: Profile: DevSec Linux Security Baseline (linux-baseline)
amazon-ebs: Version: 2.6.0

(from https://github.com/dev-sec/linux-baseline/archive/master.tar.gz as-of 20201208)

Additional context

Especially when validating a system image which might be deployed to a range of hardware, I would suggest that the tests performed should limit themselves to reporting failure cases where a mitigation exists (or make this an option) - the current checks will universally fail on certain (cloud) hardware, simply because there is no possible fix for that hardware (other than not to use it!). I would suggest that this security profile should try to limit itself to ensuring that all possible software work-arounds are deployed, where they exist.

Even this could be improved - for example, https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Variant4 states that a system is vulnerable if /sys/devices/system/cpu/vulnerabilities/spec_store_bypass doesn't exist - the current checks are only examining those files which do exist. In this case it seems that there a significant performance benefits to allowing Speculative Store, and so EC2 appears to continue to offer this facility to guest OS' - in which case, possibly this should be flagged as a warning rather than a failure? There doesn't seem to be any possible workaround a guest is able to employ, in any case.

It also appears that the mds error cannot be fixed within a VM - suggest passing the test if SMT Host state unknown is present (or operation within a virtualised environment by other means can be confirmed).

The itlb_multihit mitigation (https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/multihit.html#itlb-multihit-system-information) appears to be solely focused on KVM - so if that module is not present (or not loaded?) on the system, then it appears that this test should also pass.

Finally, comparing the output from different images, older kernels lack vulnerability nodes for itlb_multihit, srbds, tsx_async_abort - which I take to mean that these systems have no mitigations in place, but too old a kernel to report this.

I would suggest that the CPU Vulnerability checks should have a list of expected files and should alert if any of these is missing - but should also account for scenarios where the test is being executed on hardware not under the control of the user, and not treat mitigations that cloud providers have chosen not to apply as fatal errors. It feels as if there is the need for a 'warning' category of feedback here which isn't as strong as an error, but which is still notified to the user.

sysctl-17 title/description does not match test

As per this inline comment[1], there's a mismatch between the title/description and the actual test for systcl-17[2], martian logging.

The title says we're testing to ensure martian logging is disabled, but the actual test verifies that the logging is enabled. If I'm understanding correctly it's possible, even likely, that this is just a simple oversight in commit bb7c532 where the test was updated correctly, but the title/description were missed.

Martian logging enabled matches the chef-os-hardening cookbook behavior[3].

The CIS standards agree martian logging should be enabled. However, the chef BaseOS compliance profile says it should be disabled, perhaps because as the sysctl-17 description states, this logging can create a DoS attack vector.

There's a valid argument to be made either way - enable the logging, or disable it. I don't know which is more correct. Seems like the Chef compliance profile is perhaps the odd man out here, and that logging should be enabled.

[1] bb7c532#commitcomment-20365340
[2]

linux-baseline/controls/sysctl_spec.rb

Lines 186 to 193 in bb7c532

 control 'sysctl-17' do 

 impact 1.0 

 title 'Disable log martians' 

 desc 'log_martians can cause a denial of service attack to the host' 

 describe kernel_parameter('net.ipv4.conf.all.log_martians') do 

 its(:value) { should eq 1 } 

 end 

 end

[3] https://github.com/dev-sec/chef-os-hardening/blob/ea3c8b6634d1c75fa8e84d43b4122cb27293d78f/attributes/sysctl.rb#L124-L126

cpu-vulnerability-directory (1 failed) - Ubuntu

Describe the bug
Baseline is faling on ubuntu 18.04+ as of this morning. Likely related to #114 #138

Actual behavior

×  os-12: Detect vulnerabilities in the cpu-vulnerability-directory (1 failed)
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/ is expected to be directory
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v2 content is expected not to match "vulnerable"
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spectre_v2 content is expected not to match "Vulnerable"
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/l1tf content is expected not to match "vulnerable"
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/l1tf content is expected not to match "Vulnerable"
    amazon-ebs:      ✔  File /sys/devices/system/cpu/vulnerabilities/spec_store_bypass content is expected not to match "vulnerable"
    amazon-ebs:      ×  File /sys/devices/system/cpu/vulnerabilities/spec_store_bypass content is expected not to match "Vulnerable"
    amazon-ebs:      expected "Vulnerable\n" not to match "Vulnerable"

OS / Environment

Ubuntu 18.04

why keep_logs?

linux-baseline/controls/package_spec.rb

Line 91 in 34b215b

its('max_log_file_action') { should cmp 'keep_logs' }

Hi. This default now caused me a many times a lot of research wondering why the auditd log folder/partition fills up and up and up... depending on the activity of the system you mostly find the issue very late or early.
Why do you recommend this setting as default and what is the purpose/idea behind?
How to avoid an endless filling of this folder?
I'd say "rotate" is the better setting as default.

Thanks

sysctl-34 - fs.protected_hardlinks and fs.protected_symlinks can be nil

The sysctl-34 checks are currently failing with the latest amzn linux 2 images from aws (used ami filter amzn2-ami-hvm-*-x86_64-gp2):

CIS-AMZN2.amazon-ebs.amz-ami:   ×  sysctl-34: Ensure links are protected (2 failed)
CIS-AMZN2.amazon-ebs.amz-ami:      ✔  Kernel Parameter fs.protected_fifos value is expected to eq 1 or eq 2 or eq nil
CIS-AMZN2.amazon-ebs.amz-ami:      ×  Kernel Parameter fs.protected_hardlinks value is expected to eq 1
CIS-AMZN2.amazon-ebs.amz-ami:
CIS-AMZN2.amazon-ebs.amz-ami:      expected: 1
CIS-AMZN2.amazon-ebs.amz-ami:           got: nil
CIS-AMZN2.amazon-ebs.amz-ami:
CIS-AMZN2.amazon-ebs.amz-ami:      (compared using ==)
CIS-AMZN2.amazon-ebs.amz-ami:
CIS-AMZN2.amazon-ebs.amz-ami:      ✔  Kernel Parameter fs.protected_regular value is expected to eq 2 or eq nil
CIS-AMZN2.amazon-ebs.amz-ami:      ×  Kernel Parameter fs.protected_symlinks value is expected to eq 1
CIS-AMZN2.amazon-ebs.amz-ami:
CIS-AMZN2.amazon-ebs.amz-ami:      expected: 1
CIS-AMZN2.amazon-ebs.amz-ami:           got: nil

The issue triggered by the following lines.

fs.protected_hardlinks:

linux-baseline/controls/sysctl_spec.rb

Line 420 in 81ce2ab

its(:value) { should eq 1 }

fs.protected_symlinks:

linux-baseline/controls/sysctl_spec.rb

Line 426 in 81ce2ab

its(:value) { should eq 1 }

A possible fix is similar like the already implemented exceptions for fs.protected_regular and fs.protected_fifos:

  describe kernel_parameter('fs.protected_hardlinks') do # include nil because amzn linux does not have this parameter
    its(:value) { should eq(1).or eq(nil) }
  end

  describe kernel_parameter('fs.protected_symlinks') do
    its(:value) { should eq(1).or eq(nil) } # include nil because amzn linux does not have this parameter
  end

/etc/passwd should not contain any password hashes

/etc/shadow exists already for a while and should always be used for password hashes instead of /etc/passwd. Due to legacy it's possible that a password hash will be still stored in /etc/passwd. Maybe we should have a test here for that.
(idea is based on the real incident)

Add checks for mount options (noexec, nosuid, nodev)

Is your feature request related to a problem? Please describe.
Mount options like 'noexec', 'nosuid' and 'nodev' allow limiting the attack vector by disabling unintended functionality of mount points.

Describe the solution you'd like
Implement a rule that allows checking for those mount options

Additional context
Lynis implemented a test for this as well: https://github.com/CISOfy/lynis/blob/3.0.6/include/tests_filesystems#L554

net.ipv4.ip_forward needs to be '1' on docker hosts

Hi,

Running docker on a host, would need the net.ipv4.ip_forward to be '1' and that would make this test fail. Is there any way to work around that? I would really like a solution where I don't have to fork this module and maintain a copy my self.

linux-baseline/controls/sysctl_spec.rb

Line 33 in 1233a13

describe kernel_parameter('net.ipv4.ip_forward') do

How to deal with squashfs in Ubuntu 22

linux-baseline/controls/os_spec.rb

Line 257 in 07929ea

its(:content) { should match 'install squashfs /bin/true' }

I am currently trying to implement our hardening for Ubuntu 22. It turns out, that the included feature snap uses squashfs. I see two options for us:

exclude squashfs from our baseline in Ubuntu 22
advise to disable snap

What are your opinions?

Add missing tests for configuration

This includes TTYs and more files. Some tests are missing and we need a review here to add them.

This popped up thanks to feedback from @timogoebel and his MR here: dev-sec/puppet-os-hardening#43 . Thank you!

os-06: Check for SUID/ SGID blacklist control previously passing is now falling

Describe the bug
Control os-06 to check for the SUID/SGID blacklist, which was working as of 28 Jan 2021, is today no longer working due to changes in the control source code

Expected behavior
When running the inspec control via the inspec CLI, this control was previously found to be passing on the same version of the Ubuntu build.

19:31:59      amazon-ebs.<AMI_NAME>:   ✔  os-06: Check for SUID/ SGID blacklist
19:31:59      amazon-ebs.<AMI_NAME>:      ✔  suid_check diff should be empty

Actual behavior
Output seen now:

12:48:33      amazon-ebs.<AMI_NAME>:   ×  os-06: Check for SUID/ SGID blacklist
12:48:33      amazon-ebs.<AMI_NAME>:      ×  Control Source Code Error linux-baseline-master/controls/os_spec.rb:169
12:48:33      amazon-ebs.<AMI_NAME>:      wrong number of arguments (given 1, expected 0)

Example code
CLI Command to execute the profile:

inspec exec https://github.com/dev-sec/linux-baseline --backend ssh --host 127.0.0.1 --user worker --key-files /tmp/packer-provisioner-inspec.147623399.key --port 44157 --input-file /tmp/packer-provisioner-inspec.183185946.yml --no-distinct-exit --controls /os-(0[1-9]|1[0-1])(a|b)*$/ /package-(.*)$/ /sysctl-(.*)$/

OS / Environment
Ubuntu 18.04 AMD Server on AWS

Inspec Version

v4.26.4

Baseline Version

Version: 2.6.2
https://github.com/dev-sec/linux-baseline/commit/be16dbaa779fafda2ae7a5ef19e2b26abfc1dea8

Additional context
N/A

	control 'sysctl-17' do
	impact 1.0
	title 'Disable log martians'
	desc 'log_martians can cause a denial of service attack to the host'
	describe kernel_parameter('net.ipv4.conf.all.log_martians') do
	its(:value) { should eq 1 }
	end
	end

dev-sec / linux-baseline Goto Github PK

linux-baseline's Introduction

DevSec Linux Baseline

Standalone Usage

License and Author

linux-baseline's People

Contributors

Stargazers

Watchers

Forkers

linux-baseline's Issues

os-11 fails on vanilla Ubuntu 16.04/18.04

Expected behavior:

Actual behavior:

Details

Suggested fix

Recommend Projects

Recommend Topics

Recommend Org