Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't modify /etc/sysctl.conf #343

Closed
sprat opened this issue Dec 14, 2020 · 4 comments
Closed

Don't modify /etc/sysctl.conf #343

sprat opened this issue Dec 14, 2020 · 4 comments

Comments

@sprat
Copy link
Contributor

sprat commented Dec 14, 2020

Describe the bug
/etc/sysctl.conf is probably overwritten when the procps package is updated, which would break the security, so this role should not modify /etc/sysctl.conf.

Expected behavior
The sysctl parameters should be defined in a specific file in /etc/sysctl.d

Actual behavior
The sysctl parameters are defined in /etc/sysctl.conf

Example Playbook

---
- name: NAS
  hosts: nas
  become: true
  tasks:
    - import_role:
        name: devsec.hardening.os_hardening

OS / Environment

Ubuntu 20.04
Linux nas-test 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Ansible Version

ansible 2.10.3
  config file = /home/sylvain/Dev/ansible-nas/ansible.cfg
  configured module search path = ['/home/sylvain/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/sylvain/.virtualenvs/ansible-nas/lib/python3.8/site-packages/ansible
  executable location = /home/sylvain/.virtualenvs/ansible-nas/bin/ansible
  python version = 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0]

Role Version

devsec.hardening:7.0.0

Additional context
I suggest making the sysctl.d file name/path configurable so that we can put our overrides in another file with a higher priority.

@sprat sprat changed the title Don't modify sysctl.conf Don't modify /etc/sysctl.conf Dec 14, 2020
@sprat
Copy link
Contributor Author

sprat commented Dec 15, 2020

I am not sure how to handle this feature request/bug in the role since the role also enforce permissions on /etc/sysctl.conf file. I suppose we must enforce the permissions on both /etc/sysctl.conf and the alternative file, right?

@rndmh3ro
Copy link
Member

Thanks for raising this!

/etc/sysctl.conf is probably overwritten when the procps package is updated, which would break the security, so this role should not modify /etc/sysctl.conf.

Is this an assumption or did you notice this anywhere? I'd like to reproduce this.

@sprat
Copy link
Contributor Author

sprat commented Dec 16, 2020

No maybe I am mistaken. In the past I had some problems with Arch Linux, that's why I am now reluctant to modify the files that are provided by a package. I know there's a dpkg-divert tool which relocates the package-provided files but I have never really tested what happens during updates. The conf.d approach tend to be generalized to all packages, I suppose there's a good reason for that, but I am pretty much ignorant in this respect :)

@rndmh3ro
Copy link
Member

In rhel-OS'es /etc/sysctl.conf is already a symlink to a file in /etc/sysctl.d/ so I don't think we're breaking anything here. Feel free to reopen this issue if you notice otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants