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

[msiebeneicher]

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: https://github.com/dev-sec/linux-baseline/blob/81ce2ab60cc4bc29aad3822897de1c55593e3f73/controls/sysctl_spec.rb#L420

fs.protected_symlinks: https://github.com/dev-sec/linux-baseline/blob/81ce2ab60cc4bc29aad3822897de1c55593e3f73/controls/sysctl_spec.rb#L426

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

[schurzi]

This is a bit puzzling. The sysctls should be available on any current Linux. Can you post your kernel version? Also, are you running this as a user or as root?

[msiebeneicher]

Can you post your kernel version?

# cat /proc/version
Linux version 4.14.281-212.502.amzn2.x86_64 (mockbuild@ip-10-0-54-84) (gcc version 7.3.1 20180712 (Red Hat 7.3.1-13) (GCC)) #1 SMP Thu May 26 09:52:17 UTC 2022

Also, are you running this as a user or as root? we running inspec via packer in a default setup (https://www.packer.io/plugins/provisioners/inspec):

provisioner "inspec" {
    inspec_env_vars = ["CHEF_LICENSE=accept"]
    profile = "https://github.com/dev-sec/linux-baseline"
  }

So the user is not root and we don't use sudo to execute the specs here.

[schurzi]

Can you execute the profile as root once? I believe some of the sysctls are only present, when you query them with root privileges. This might be another issue with our nil solution.

[msiebeneicher]

Looks like the "--sudo" execution will do the job:

provisioner "inspec" {
    inspec_env_vars = ["CHEF_LICENSE=accept"]
    profile = "https://github.com/dev-sec/linux-baseline"
    extra_arguments = [ "--sudo" ]
  }

    CIS-AMZN2.amazon-ebs.amz-ami:   ✔  sysctl-34: Ensure links are protected
    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:      ✔  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

But it have a weird touch for me to execute the specs with --sudo for one check only 😝

[schurzi]

Your concern is understandable. I did some digging in the Linux sources and it seems the problem with permissions for the sysctls was already identified and fixed in https://github.com/torvalds/linux/commit/c7031c144043c5b9a9b8827aaf44a67937559418

So at the moment, you have the option to update your kernel or run this profile as root. I'm not sure how we can fix this any other way.

@chris-rock @rndmh3ro do you have any opinion on this? I think we should check for our permissions before we give an error. There are several possible options:

• add a only_if to the sysctl check, so we will skip these sysctls if we do not have permissions for them
• add a requirement to run as root
• make it a hard fail in any case we cannot read the sysctls (possibly add an access check to make the error more clear)

[rndmh3ro]

add a only_if to the sysctl check, so we will skip these sysctls if we do not have permissions for them

This could lead to thinking that there's no problem, so we should not do that.

add a requirement to run as root

Sounds plausible as a workaround to document it.

make it a hard fail in any case we cannot read the sysctls

It is a hard fail right now.

(possibly add an access check to make the error more clear)

I guess this is the easiest way (apart from just documenting the workaround). If the user has no permissions to reaad the proc, it should fail.