dev-sec / chef-os-hardening Goto Github PK

View Code? Open in Web Editor NEW

438.0 438.0 135.0 673 KB

This chef cookbook provides numerous security-related configurations, providing all-round base protection.

Home Page: http://dev-sec.io/

License: Apache License 2.0

Ruby 80.81% HTML 19.19%

chef chef-cookbook devops hardening linux security

chef-os-hardening's People

Contributors

Stargazers

Watchers

Forkers

chris-rock ehaselwanter thefighter brin100 bkw gosuri kplimack aschmidt75 rapenchukd davidkazuhiro rudymccomb johnbellone joshgarnett ekometti fernandowiek creativemarket patcon rollbrettler mikemoate foonix eodabas ripple jamesknott adampats virtadpt boldandbusted 8x8cloud agiza phillym atomic111 netflash shortdudey123 jsonorona artem-forks sbdevaws symondsandson linuxautobot ncs-alane alphagov leelavinothb mpetka kbahaxor koulio geraldolsribeiro joyofhex wtlghf rr-paras-patel psyreactor shoekstra rrottmann jhammell nickrycar artithw borgified rhass iennae bablakely hybridious thealadeen tied vincentaubert saurabh1611 jdgoins avanier ekelson-bcove dhohengassner anidil18 jesusoctavioas raghuk134 frederikbosch pankajps aeroglyphic getrostt prezi wheelq sean-nixon andrewpsp dragon040 nrgline4sec kharimurugan hieunba ssprasad100 jjustice6 rudikza dimongo princeanurag2011 thirumoorthir b-dean megioliver alexbmw00 novablack6 puneetloya meetcircle acmmendis taehyunk-github rohit-kaundal bcg62 jorson-chen mfortin asabayxx

chef-os-hardening's Issues

fixing the 4 rspec failure

rspec ./spec/recipes/login_defs_spec.rb:36 # os-hardening::login_defs uses uid_min and gid_min in /etc/login.defs
rspec ./spec/recipes/sysctl_spec.rb:31 # os-hardening::sysctl intel should detect intel cpu
rspec ./spec/recipes/sysctl_spec.rb:47 # os-hardening::sysctl amd should detect amd cpu
rspec ./spec/recipes/sysctl_spec.rb:61 # os-hardening::sysctl fallback should detect intel cp

look at travis https://travis-ci.org/dev-sec/chef-os-hardening/jobs/136357364

Conservative package update

We should separate package updates from hardening. The current version updates the dependencies for apt by using and upgrades the system on RHEL

The behavior for apt and yum is slightly different and should be harmonized. I propose, we do not a yum update because this would lead to package upgrades in production environments that we may not want.

make package upgrades optional
stick to a specific version of apt to ensure the same behavior
always update dependencies e.g. apt-get update
a default rerun should not update packages

Procps conditional failing

I only noticed this on a Ubuntu server 14.04 with chef 11.16.0. This is from a chef-solo run:

    ================================================================================
    Error executing action `start` on resource 'service[procps]'
    ================================================================================

    ArgumentError
    -------------
    wrong number of arguments (2 for 0)

    Cookbook Trace:
    ---------------
    /chef/cookbooks-2/os-hardening/recipes/sysctl.rb:88:in `block (2 levels) in from_file'

    Resource Declaration:
    ---------------------
    # In /chef/cookbooks-2/os-hardening/recipes/sysctl.rb

     84:   service 'procps' do
     85:     provider service_provider
     86:     supports restart: false, reload: false
     87:     action [:enable, :start]
     88:     only_if { cookbook_version('sysctl', '< 0.6.0') }
     89:   end
     90: end

    Compiled Resource:
    ------------------
    # Declared in /chef/cookbooks-2/os-hardening/recipes/sysctl.rb:84:in `from_file'

    service("procps") do
      provider Chef::Provider::Service::Upstart
      action [:enable, :start]
      supports {:restart=>false, :reload=>false}
      retries 0
      retry_delay 2
      guard_interpreter :default
      service_name "procps"
      pattern "procps"
      cookbook_name :"os-hardening"
      recipe_name "sysctl"
      only_if { #code block }
    end

Actually log martians?

Comment seems to indicate we want to log, but setting is not to:

https://github.com/hardening-io/chef-os-hardening/blob/b5a0a3e34776bd93d6c553f133c46527ebd2d965/attributes/sysctl.rb#L125

This slide also seems to indicate that we want to log:
http://www.slideshare.net/myowntelco/centos-linux-server-hardening#18

Installation doesn't work

Hey guys,

awesome work :D

Currently I cant install this nice cookbook.

I've done all the stuff which was in TUTORIAL.md

/usr/local/rvm/gems/ruby-2.2.0/gems/chef-12.0.3/lib/chef/data_bag_item.rb:161: warning: circular argument reference - data_bag
Starting Chef Client, version 12.0.3
Compiling Cookbooks...

Running handlers:
[2015-01-19T20:13:58+01:00] ERROR: Running exception handlers
Running handlers complete
[2015-01-19T20:13:58+01:00] ERROR: Exception handlers complete
[2015-01-19T20:13:58+01:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
Chef Client failed. 0 resources updated in 1.342882106 seconds
[2015-01-19T20:13:58+01:00] ERROR: Cookbook os-hardening not found. If you're loading os-hardening from another cookbook, make sure you configure the dependency in your metadata
[2015-01-19T20:13:58+01:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Ruby version:
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-linux]

Debian 7 x64

Könnt auch auf Deutsch antworten! :)

properly handle sysctl again

Some sysctl parameters aren'r propagated correctly. Adjust it.

auditd package is not installed

According to https://github.com/dev-sec/linux-baseline/blob/master/controls/package_spec.rb#L79-L103 we need to add the package auditd

tests fail in travis

There is an issue with ruby dependencies in combination with travis:

Gem::InstallError: varia_model requires Ruby version >= 2.0.0.
An error occurred while installing varia_model (0.5.0), and Bundler cannot
continue.
Make sure that `gem install varia_model -v '0.5.0'` succeeds before bundling.

forwarding isn't configured

When setting forwarding to true, it is not configured in the destination box, neither vor IPv4 nor for IPv6.

This is due to issue #8. Listed here separately to let anyone know who stumbles upon this issue.

pam node attribute namespace error

Missed an attribute in the name space merge.

chef-os-hardening/recipes/pam.rb

Line 111 in 106585d

action node['auth']['pam']['passwdqc']['enable'] ? :install : :remove

null: Recipe Compile Error in /tmp/packer-chef-solo/cookbooks-0/os-hardening/recipes/default.rb
    null: ================================================================================
    null:
    null: NoMethodError
    null: -------------
    null: undefined method `[]' for nil:NilClass
    null:
    null: Cookbook Trace:
    null: ---------------
    null: /tmp/packer-chef-solo/cookbooks-0/os-hardening/recipes/pam.rb:111:in `block in from_file'
    null: /tmp/packer-chef-solo/cookbooks-0/compat_resource/files/lib/chef_compat/monkeypatches/chef/resource_builder.rb:90:in `instance_eval'
    null: /tmp/packer-chef-solo/cookbooks-0/compat_resource/files/lib/chef_compat/monkeypatches/chef/resource_builder.rb:90:in `build'
    null: /tmp/packer-chef-solo/cookbooks-0/os-hardening/recipes/pam.rb:109:in `from_file'
    null: /tmp/packer-chef-solo/cookbooks-0/os-hardening/recipes/default.rb:26:in `from_file'
    null:
    null: Relevant File Content:
    null: ----------------------
    null: /tmp/packer-chef-solo/cookbooks-0/os-hardening/recipes/pam.rb:
    null:
    null: 104:      package 'pam-cracklib' do
    null: 105:        package_name node['os-hardening']['packages']['pam_cracklib']
    null: 106:        action node['os-hardening']['auth']['pam']['passwdqc']['enable'] ? :remove : :nothing
    null: 107:      end
    null: 108:
    null: 109:      package 'pam-passwdqc' do
    null: 110:        package_name node['os-hardening']['packages']['pam_passwdqc']
    null: 111>>       action node['auth']['pam']['passwdqc']['enable'] ? :install : :remove
    null: 112:      end
    null: 113:    else
    null: 114:      # In RH-family distros > 7, 'pam_pwquality' obsoletes both pam_cracklib and pam_passwdqc
    null: 115:      # See https://linux.web.cern.ch/linux/rhel/releasenotes/RELEASE-NOTES-7.0-x86_64/
    null: 116:      package 'pam_pwquality' do
    null: 117:        package_name node['os-hardening']['packages']['pam_pwquality']
    null: 118:      end
    null: 119:    end
    null: 120:
    null:
    null: [2016-06-01T16:23:42-07:00] ERROR: Running exception handlers
    null: [2016-06-01T16:23:42-07:00] ERROR: Exception handlers complete
    null: [2016-06-01T16:23:42-07:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
    null: [2016-06-01T16:23:42-07:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
    null: [2016-06-01T16:23:42-07:00] ERROR: undefined method `[]' for nil:NilClass
    null: [2016-06-01T16:23:42-07:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit cod

attributes need to be localized to the `node['chef-os-hardening']` namespace

Issue to track #88 in case that PR gets closed without getting merged because its out of date now.

The way this cookbook stomps on attributes namespaces violates long-standing policy regarding cookbook attribute namespacing (that predates our RFC process by many years so I don't have a convenient authoritative URL to point at).

See chef/chef#4849 for example issue getting cut against core chef which we've closed pointing to this cookbook needing to get fixed.

PAM conflicts between os-hardening and sssd_ldap cookbooks

I use the sssd_ldap cookbook on my nodes which uses authconfig to modify PAM settings. Now I've started testing this cookbook and see that it's overriding the modifications the sssd_ldap cookbook has made. I can still SSH into the node using my LDAP creds, but attempting to use sudo fails with a bad or incorrect password warning.

I'm willing to create a pull request, but I'm not sure which direction to go.

Detect if sssd_ldap is in use and add those modifications to the rhel_system_auth.erb template in this cookbook?
Create an optional attribute to disable the pam modifications in this cookbook and just make the pam modifications in the sssd_ldap cookbook?
Some other option?

On CentOS 7 the ldap_sssd cookbook creates /etc/pam.d/system-auth like this:

auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

I've done some testing on CentOS 7, and adding the additional 'pam_sss.so' lines to the the template in os-hardening seems to fix my sudo issue.

possible incompatibility with Chef client release 12.4

Our deployments started failing after the new Chef client release last week; I am currently working on modifying our cloud-init based bootstrap to pin the version of the Chef omnibus installer (unfortunately the cloud-init Chef support doesn't provide any way to do this, so I have to do the installation manually to pin it to a particular version) so I haven't had the time to dive in deep to try to understand what changed in 12.4 to cause it to fail, but the fatal error is in the os-hardening/sysctl.rb recipe, so thought I would give you a "heads up" on this problem...

Here are the most-likely-to-be-relevant info and warnings from the logs of the initial Chef client run:

[2015-06-26T16:01:01+00:00] INFO: Loading cookbooks [[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]]
[2015-06-26T16:01:01+00:00] WARN: You are overriding windows_package on {:os=>"windows"} with Chef::Resource::WindowsCookbookPackage: used to be Chef::Resource::WindowsPackage. Use override: true if this is what you intended.
[2015-06-26T16:01:01+00:00] WARN: You declared a new resource Chef::Provider::GitClient::Source for resource git_client, but it comes alphabetically after Chef::Provider::GitClient::Package and has the same filters ({:os=>"linux"}), so it will not be used. Use override: true if you want to use it for git_client.
...
================================================================================
Recipe Compile Error in /var/cache/chef/cookbooks/publicserver-tlabs/recipes/default.rb
================================================================================

NoMethodError
-------------
No resource or method named `File' for `Chef::Recipe "sysctl"'

Cookbook Trace:
---------------
  /var/cache/chef/cookbooks/os-hardening/recipes/sysctl.rb:46:in `from_file'
  /var/cache/chef/cookbooks/os-hardening/recipes/default.rb:30:in `from_file'
  /var/cache/chef/cookbooks/publicserver-tlabs/recipes/default.rb:56:in `from_file'[0m

Relevant File Content:
----------------------
/var/cache/chef/cookbooks/os-hardening/recipes/sysctl.rb:

 39:  rescue
 40:    log 'WARNING: Could not properly determine the cpu vendor. Fallback to intel cpu.' do
 41:      level :warn
 42:    end
 43:  end
 44:  
 45:  # protect sysctl.conf
 46>> File '/etc/sysctl.conf' do
 47:    mode 0440
 48:    owner 'root'
 49:    group 'root'
 50:  end
 51:  
 52:  # NSA 2.2.4.1 Set Daemon umask
 53:  # do config for rhel-family
 54:  case node['platform_family']
 55:  when 'rhel', 'fedora'
[2015-06-26T16:01:48+00:00] ERROR: Running exception handlers
[2015-06-26T16:01:48+00:00] ERROR: Exception handlers complete

[0m[2015-06-26T16:01:48+00:00] FATAL: Stacktrace dumped to /var/cache/chef/chef-stacktrace.out
[2015-06-26T16:01:48+00:00] ERROR: No resource or method named `File' for `Chef::Recipe "sysctl"'
[2015-06-26T16:01:48+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Archlinux doesn't have a limits.d directory by default

/etc/security/limits.d doesn't exist by default. It works and is included when it does exist, but needs to be made before https://github.com/hardening-io/chef-os-hardening/blob/master/recipes/limits.rb#L21 is ran. A simple wrapper recipe works:

directory '/etc/security/limits.d' do
  owner 'root'
  group 'root'
  mode '0755'
end
include_recipe 'os-hardening::default'

pam_passwdqc installation fails on CentOS 7.1

* No candidate version available for pam_passwdqc
           ================================================================================
           Error executing action `install` on resource 'yum_package[pam-passwdqc]'
           ================================================================================

           Chef::Exceptions::Package
           -------------------------
           No candidate version available for pam_passwdqc

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cookbooks/os-hardening/recipes/pam.rb

           111:     package 'pam-passwdqc' do
           112:       package_name node['packages']['pam_passwdqc']
           113:     end
           114: 

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cookbooks/os-hardening/recipes/pam.rb:111:in `from_file'

           yum_package("pam-passwdqc") do
             action [:install]
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             package_name "pam_passwdqc"
             flush_cache {:before=>false, :after=>false}
             declared_type :package
             cookbook_name :"os-hardening"
             recipe_name "pam"
           end

ERROR: No resource or method named `File' for `Chef::Recipe "sysctl"'

The following error appears on machines running chef-client 12.4.0. Reverting to 12.3.0 resolves the issue.

================================================================================
         Recipe Compile Error in /tmp/kitchen/cache/cookbooks/tm_base/recipes/default.rb
         ================================================================================

         NoMethodError
         -------------
         No resource or method named `File' for `Chef::Recipe "sysctl"'

         Cookbook Trace:
         ---------------
           /tmp/kitchen/cache/cookbooks/os-hardening/recipes/sysctl.rb:46:in `from_file'
           /tmp/kitchen/cache/cookbooks/tm_base/recipes/hardening.rb:26:in `from_file'
           /tmp/kitchen/cache/cookbooks/tm_base/recipes/default.rb:25:in `from_file'

         Relevant File Content:
       ----------------------
         /tmp/kitchen/cache/cookbooks/os-hardening/recipes/sysctl.rb:

          39:  rescue
          40:    log 'WARNING: Could not properly determine the cpu vendor. Fallback to intel cpu.' do

          42:    end
          43:  end
          44:  
          45:  # protect sysctl.conf
          46>> File '/etc/sysctl.conf' do
          47:    mode 0440
          48:    owner 'root'
          49:    group 'root'
          50:  end

          52:  # NSA 2.2.4.1 Set Daemon umask
          53:  # do config for rhel-family
          54:  case node['platform_family']
          55:  when 'rhel', 'fedora'


         Running handlers:

         Running handlers complete
       [2015-06-24T23:43:49+00:00] ERROR: Exception handlers complete
         Chef Client failed. 3 resources updated in 14.720096092 seconds
       [2015-06-24T23:43:49+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2015-06-24T23:43:49+00:00] ERROR: No resource or method named `File' for `Chef::Recipe "sysctl"'
       [2015-06-24T23:43:50+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Umask

If I use the os-hardening framework, several cookbooks like rabbitmq and sensu(-plugins) fail to install.

It looks like chef itself uses umask 0007 for all operations. If I install any gem it is not readable by others anymore. How would you solve these issues?

pam_passwdqc package install idempotence

In some situations, there's an idempotence issue with (at least) the pam_passwdqc package. If the package is already installed, the chef run will fail and error out:

       Recipe Compile Error in /tmp/kitchen/cache/cookbooks/os-hardening/recipes/default.rb
       ================================================================================

       Chef::Exceptions::ValidationFailed
       ----------------------------------
       Property package_name must be one of: String, Array!  You passed {"epoch"=>"0", "version"=>"1.0.5", "release"=>"8.el6", "installdate"=>"1481734892", "arch"=>"x86_64"}.

       Cookbook Trace:
       ---------------
         /tmp/kitchen/cache/cookbooks/os-hardening/recipes/pam.rb:110:in `block in from_file'
         /tmp/kitchen/cache/cookbooks/os-hardening/recipes/pam.rb:109:in `from_file'
         /tmp/kitchen/cache/cookbooks/os-hardening/recipes/default.rb:26:in `from_file'

       Relevant File Content:
       ----------------------
       /tmp/kitchen/cache/cookbooks/os-hardening/recipes/pam.rb:

       103:      # remove pam_cracklib, because it does not play nice with passwdqc in versions less than 7
       104:      package 'pam-cracklib' do
       105:        package_name node['packages']['pam_cracklib']
       106:        action node['auth']['pam']['passwdqc']['enable'] ? :remove : :nothing
       107:      end
       108:
       109:      package 'pam-passwdqc' do
       110>>       package_name node['packages']['pam_passwdqc']
       111:        action node['auth']['pam']['passwdqc']['enable'] ? :install : :remove
       112:      end
       113:    else
       114:      # In RH-family distros > 7, 'pam_pwquality' obsoletes both pam_cracklib and pam_passwdqc
       115:      # See https://linux.web.cern.ch/linux/rhel/releasenotes/RELEASE-NOTES-7.0-x86_64/
       116:      package 'pam_pwquality' do
       117:        package_name node['packages']['pam_pwquality']
       118:      end
       119:    end

This problem can be reproduced by converging twice. It wouldn't be picked up by automated testing because the first run is fine. I discovered the issue because I'm trying to use the cookbook on images which already have the pam_passwdqc package installed.

However, the issue does not appear to be consistent across platforms listed in the test kitchen configuration. For example, centos-6.4 and centos-6.5 exhibit the problem behavior, but centos-7.1 does not.

It looks like the hash in the error that the package resource is trying to process (rather than the string or array it was expecting) might be coming from ohai.

Testing of chef 13 in the CI

It makes sense to have chef 12 and chef 13 testing in the CI, I'll have a look here

Edit: initially it was a bug report about chef 13 support, in the end I discovered a mistake in my test environment

packages with known issues are not actually removed on debian/ubuntu

My colleague @JJClements already mentioned this in Gitter at https://gitter.im/hardening-io/general alongside another issue we have encountered.

We have observed that the functionality to remove the list of packages with known issues has only be implemented for the redhat/fedora family of distributions, the debian family implementation is missing. We have also tested this on Ubuntu 14.04 by installing the xinetd package and then confirming applying this cookbook does not remove the package, even if ['security']['packages']['clean'] = true is set.

We intend to contribute a pull request to address this, following the guidance at http://hardening.io/docs/coding/contributing/

Tagged Release

Is there anything I can help finish up so a new release can be tagged?

remove ntp

ntp sould move to its own hardening configuration and should not be pulled into base os hardening by default

Fails when used in conjunction with openldap::auth recipe

When using both recipes in same machine I get error:

 ---- Begin output of pam-auth-update --package ----
STDOUT: 
STDERR: Use of uninitialized value in join or string at /usr/sbin/pam-auth-update line 111, <STDIN> line 4.
Failed to open terminal.debconf: whiptail output the above errors, giving up!
 ---- End output of pam-auth-update --package --

deactivate pw_max_age

HI,
is it possible, to completely deactivate the pw_max_age security feature? We don't use passwords anyway. As an alternative we could set an maximum password age (maybe something around 10 years?)

can't convert String into Integer for package 'pam-ccreds'

I added include_recipe 'os-hardening' to my base recipe and ran into this:

TypeError
  ---------
  can't convert String into Integer

  Cookbook Trace:
  ---------------
    /var/chef/cache/cookbooks/os-hardening/recipes/pam.rb:29:in `[]'
    /var/chef/cache/cookbooks/os-hardening/recipes/pam.rb:29:in `block in from_file'
    /var/chef/cache/cookbooks/os-hardening/recipes/pam.rb:28:in `from_file'
    /var/chef/cache/cookbooks/os-hardening/recipes/default.rb:26:in `from_file'
    /var/chef/cache/cookbooks/base/recipes/default.rb:21:in `from_file'
    /var/chef/cache/cookbooks/base/recipes/users.rb:10:in `from_file'
    /var/chef/cache/cookbooks/app_ruby/recipes/default.rb:10:in `from_file'
    /var/chef/cache/cookbooks/app_ruby/recipes/deploy.rb:11:in `from_file'

  Relevant File Content:
  ----------------------
  /var/chef/cache/cookbooks/os-hardening/recipes/pam.rb:

   22:  execute 'update-pam' do
   23:    command 'pam-auth-update --package'
   24:    action :nothing
   25:  end
   26:
   27:  # remove ccreds if not necessary
   28:  package 'pam-ccreds' do
   29>>   package_name node['packages']['pam_ccreds']
   30:    action :remove
   31:  end
   32:
   33:  case node['platform_family']
   34:  # do pam config for ubuntu
   35:  when 'debian'
   36:
   37:    passwdqc_path = '/usr/share/pam-configs/passwdqc'
   38:    tally2_path   = '/usr/share/pam-configs/tally2'


  Running handlers:
[2014-09-29T23:12:12+00:00] ERROR: Running exception handlers
[2014-09-29T23:12:12+00:00] ERROR: Report handler Chef::Handler::Datadog raised #<NoMethodError: undefined method `length' for nil:NilClass>
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-handler-datadog-0.6.0/lib/chef/handler/datadog.rb:196:in `emit_metrics_to_datadog'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-handler-datadog-0.6.0/lib/chef/handler/datadog.rb:27:in `report'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:226:in `run_report_unsafe'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:214:in `run_report_safely'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:118:in `block in run_exception_handlers'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:117:in `each'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:117:in `run_exception_handlers'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/handler.rb:127:in `block in <class:Handler>'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:133:in `call'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:133:in `block in run_failed'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:132:in `each'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:132:in `run_failed'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:447:in `rescue in do_run'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:459:in `do_run'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:213:in `block in run'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:207:in `fork'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/client.rb:207:in `run'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/application.rb:236:in `run_chef_client'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/application/client.rb:338:in `block in run_application'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/application/client.rb:327:in `loop'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/application/client.rb:327:in `run_application'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/lib/chef/application.rb:55:in `run'
[2014-09-29T23:12:12+00:00] ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.0/bin/chef-client:26:in `<top (required)>'
[2014-09-29T23:12:12+00:00] ERROR: /usr/bin/chef-client:23:in `load'
[2014-09-29T23:12:12+00:00] ERROR: /usr/bin/chef-client:23:in `<main>'
    - Chef::Handler::Datadog
  Running handlers complete
[2014-09-29T23:12:12+00:00] ERROR: Exception handlers complete
[2014-09-29T23:12:12+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
  Chef Client failed. 1 resources updated in 11.471867911 seconds
[2014-09-29T23:12:13+00:00] ERROR: can't convert String into Integer
[2014-09-29T23:12:13+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1

ChefSpec and Ohai/Fauxhai: cpu

Using ChefSpec (with Fauxhai, either Debian 7.6 or Ubuntu 12.04)

    Failure/Error: let(:chef_run) { ChefSpec::Runner.new.converge(described_recipe) }
     NoMethodError:
       undefined method `[]' for nil:NilClass

in: os-hardening/recipes/sysctl.rb

 25>> cpu_vendor = node['cpu']['0']['vendor_id']
 26:    .sub(/^.*GenuineIntel.*$/, 'intel')
 27:    .sub(/^.*AuthenticAMD.*$/, 'amd')

turns out, typical fauxhai node attributes don't contain the attribute required:

https://github.com/customink/fauxhai/blob/master/lib/fauxhai/platforms/debian/7.6.json#L585
https://github.com/customink/fauxhai/blob/master/lib/fauxhai/platforms/ubuntu/14.04.json#L494

This will byte everyone using ChefSpec and your cookbook.

You either want to soft-fail or try to convince the fauxhai guys to add the attribute.

Workaround until then:

  let(:chef_run) {
    ChefSpec::Runner.new do |node|
      node.automatic['cpu']['0']['vendor_id'] = 'GenuineIntel'
    end.converge(described_recipe)
  }

see https://github.com/sethvargo/chefspec#automatic-attributes

Tests for suid bits

We need a way to test that suid bits are properly set.

Selinux enforcing support for RHEL/Centos?

Question: should selinux support be included in this cookbook? If yes, that are the views on implementation?

Suggestion:

New attribute like selinux_mode with following options: enforcing, permissive, unmanaged(default).
No option disabled because reboot is required for that change
selinux_mode = enforcing | permissive results to the change of /etc/sysconfig/selinux and setenforce execution

Better error handling for cpu detection

As reported by @rmoritz we need to identify the CPU properly. If we cannot determine the cpu, we need to fallback to an intel cpu. The affected code is in sysctl.rb

sysctl dependency

Hi,

currently sysctl is tied to a very old version of the sysctl cookbook. Is there a reason for that?

https://github.com/TelekomLabs/chef-os-hardening/blob/master/metadata.rb#L32

vs.

https://supermarket.getchef.com/cookbooks/sysctl

thanks

release 2.0 in supermarket

@artem-sidorenko Do you see anything that prevents us to release the current master as v 2.0.0? Supermarket still uses 1.4.1

Chef::Exceptions::Exec: yum_package[xinetd] (os-hardening::yum line 50)

I run Centos 6.5. If i run the os-hardening the first time, it fails with the following error. But the second chef run is successful. I can provide you the virtual machine for testing.

chef-stacktrace ouput:

Generated at 2014-10-21 14:40:56 +0200
Chef::Exceptions::Exec: yum_package[xinetd] (os-hardening::yum line 50) had an error: Chef::Exceptions::Exec:  returned 1, expected 0
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/mixin/command.rb:158:in `handle_command_failures'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider/package/yum.rb:1021:in `yum_command'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider/package/yum.rb:1177:in `remove_package'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider/package/yum.rb:1188:in `purge_package'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider/package.rb:129:in `block in action_purge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/mixin/why_run.rb:52:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/mixin/why_run.rb:52:in `add_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider.rb:156:in `converge_by'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider/package.rb:128:in `action_purge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/provider.rb:121:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource.rb:648:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/resource_collection.rb:96:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/client.rb:345:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/client.rb:431:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/client.rb:213:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/client.rb:207:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/client.rb:207:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/application.rb:236:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/application/solo.rb:226:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/application/solo.rb:218:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/application/solo.rb:218:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/lib/chef/application.rb:55:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.16.4/bin/chef-solo:25:in `<top (required)>'
/usr/bin/chef-solo:23:in `load'
/usr/bin/chef-solo:23:in `<main>'#

['os-hardening']['desktop']['enable'] is missing in 2.0.0

how it looks like it was removed in GH-114 and never got back

For me it broke some deployments, I would provide a fix for 2.0.1 patch release

login.defs.erb contains a non-ASCII character which causes a knife cookbook upload failure

$ knife cookbook upload os-hardening
ERROR: ArgumentError: invalid byte sequence in US-ASCII

$ grep --color='auto' -P -n "[\x80-\xFF]" cookbooks//templates//*
cookbooks/os-hardening/templates/default/login.defs.erb:95:# If set to yes, userdel will remove the user**??**s group if it contains no more members, and useradd will create by default a group with the name of the user.

Original content:
# If set to yes, userdel will remove the user´s group if it contains no more members, and useradd will create by default a group with the name of the user.

Could you please use a ' instead of a ´ ?

Validate suid-bit removal from /bin/screen

For multi-user sessions this doesn't work without SUID-bit. Either create an explicit list for these kinds of situations with suid/sgid bits in the readme, or determine if this SUID-bit is an issue or not.

1.3.0 release on supermarket is broken

Get an error when doing a 'berks upload' that includes the new 1.3.0 from supermarket.

turns out in the packaged released ( but not in the source ) there's a file os-hardening/templates/.DS_Store which chef server doesn't know how to handle and flips out. setting Berksfile to pull it from git repo at tag v1.3.0 works fine.

login.defs - CREATE_HOME

Is there a way to add CREATE_HOME yes to the login.defs file during deployment?

Integration testing of this cookbook in the CI

Currently we only run unit tests/lints. Its not easily possible to test this cookbook in the same way like we do with chef-ssh-hardening (kitchen-dokken): we change here tonns of OS parameters.

What about to have a proper integration testing via IaaS?

I already did it with digitalocean and it works just fine
Another option would be maybe the Google Cloud with an advantage - its billed per minute. I do not want to consider the ec2/azure, they are a bit complexer for this simple job (and require a bit more configuration/setup)

My suggested way:

to go with DigitalOcean (I'll provide a token within my account)
to go with travis environment variables for storing of access token

Via this way we get following:

integration tests of main repository
people with forks can configure their own DO access token in travis and get integration tests too
in case of PRs without integration tests, we can repush them to our forks/main repo and get them tested

@atomic111 @chris-rock opinions?

Openhub is not up to date

Hi,

your site on https://www.openhub.net/p/chef_os_hardening is not up to date.

BR
Gino

If I "enable" core dumps with chef-os-hardening, am I really fully enabling core dumps?

We have a need to enable core dumps on production to assist our developers in troubleshooting "interesting" problems. While I see that chef-os-hardening has facilities to disable core files, is the converse true?

Basically, I'll want to do this: http://www.kibinlabs.com/re-enabling-core-dumps-redhat-7/

Thanks! :)

Support Centos 7

Fix: pam_passwdqc handling

`execute[update-pam]` copied resource fails on chef-client 12.5

Failure log output: https://gist.github.com/patcon/32e942c560dee6727f43

Line in question: https://github.com/hardening-io/chef-os-hardening/blob/master/recipes/pam.rb#L96

I assume this has something to do with the fact that resource copying has been deprecated to awhile, and the behaviour this resource-use pattern depends on is no longer how Chef works.

We could fix this by instead adding this to one of the resources that runs during this condition:

some_resource 'foo' do
  some_key some_value
  notifies :run, 'execute[update-pam]', :immediately
end

passwordless users not able to log in

After applying the os-hardening recipe, I could no longer login into the default user via ssh.
Here is what happened:

The machine was an ubuntu 14.04 LTS vm set up by openstack heat. This creates a default user "ec2-user".
Without further provisioning, this user has no password. This usually poses no problem for me, since ssh is configured to allow RSA key based login only.
The user is locked ("!" in /etc/shadow) since he has no password. ssh will allow logins anyway, since the password is not involved.
After pam was enabled by this recipe, the "locked" flag IS being evaluated, resulting in the following entries in /var/log/auth.log:

sshd[xxx]: User ec2-user not allowed because account is locked
sshd[xxx]: input_userauth_request: invalid user ec2-user [preauth]
sshd[xxx]: Disconnecting: Too many authentication failures for ec2-user [preauth]

I believe this may hit many users. I'm not sure how to deal with this, at least we should document it, since it is not only a surprising side effect of using this recipe, but also one with possibly severe consequences.

Solutions I can think of, off the top of my head:

Try to find out what the "default" user is an forcefully unlock it, as long as we enforce rsa-only ssh logins
supply a list of accounts to be unlocked as an attribute, possibly with sane defaults. If an account of that name exists, unlock it, emit a warning (or an exception even?) it that account has no password.
supply an exception for ssh with passwordless accounts ssh in pam, as long as rsa-only authentification is activated.

Other thoughts?

update tutorial.md

use chefdk
use chef zero
download dependencies with berks

enable_sysrq-check is faulty

if sysrq is allowed, the secure sysrq should be pulled in. instead it's being set to false right now, which non-numeric, i.e. wrong

pam recipe failing with chef client > 12.8.1

OS image: Amazon Linux AMI release 2015.09 (ami-f0091d91)
chef-solo: 12.9.38
ohai: 8.14.0
chef-solo log: https://gist.github.com/rljohnsn/36cdf0e8525f5113a56afd8a69c85cfc
ohai output: https://gist.github.com/rljohnsn/8cd4b428e73c3d465376b072183787ba

Some where along the way, it appears, the node attributes are wonky on Amazon Linux Image
node['packages']['pam_ccreds'] attribute get set to JSON of the package ohai output.

{"version"=>"10", "release"=>"4.9.amzn1"}

ensure packages are deleted if the flag is set
try to install unsigned packages
install insecure package and do a rerun of os-hardening

dev-sec / chef-os-hardening Goto Github PK

chef-os-hardening's People

Contributors

Stargazers

Watchers

Forkers

chef-os-hardening's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs