Getting started

Word of precaution

This role was written in 2018 to change hidepid for the whole system. On 2020-11-26 systemd 247 was released which introduced the ProtectProc setting. Setting hidepid for the whole system has drawbacks. Read Is mounting /proc with "hidepid=2" recommended with RHEL7 and later? and Why is the mount option "hidepid=2" not used by default, is there a danger in using it?.

The way to move forward is to contribute ProtectProc to all upstream projects, wait until Debian releases them and then potentially deprecate this role. Until then, this role provides hardening with the potential of breaking things.

Handling of polkit

> Confirmed, giving access to /proc to polkitd user (running polkitd) is not > enough, the authentication agent seems to requires that as well (and granting > my user access to /proc denies the interest of hidepid).

https://github.com/Kicksecure/security-misc/issues/173

https://github.com/systemd/systemd/issues/29893

So if polkit is detected or planned to be installed on a host, this hardening on a system level will not be enabled.

Static GID assignment

The procadmins group uses a static GID 70, chosen based on the default set of system groups provided in Debian with usable range between 61-99. This becomes important in environments with LXC containers where, depending on the configuration, host and container GIDs could differ, resulting in a different set of users being able to see the /proc contents. Thus, the need to synchronize the GID between distinct environments sharing the same GID namespace (the same kernel).

Ansible local facts

The debops.proc_hidepid role provides a set of Ansible local facts available in the ansible_local.proc_hidepid.* hierarchy. You can use the facts to add application UNIX accounts to the correct UNIX system group that allows them access to the /proc filesystem.

Example inventory

The debops.proc_hidepid role is included by default in the common.yml DebOps playbook; you don't need to add hosts to any Ansible groups to enable it.

Example playbook

If you are using this role without DebOps, here's an example Ansible playbook that uses the debops.proc_hidepid role:

---

- name: Manage /proc hidepid= configuration
  collections: [ 'debops.debops', 'debops.roles01',
                 'debops.roles02', 'debops.roles03' ]
  hosts: [ 'debops_all_hosts', 'debops_service_proc_hidepid' ]
  become: True

  environment: '{{ inventory__environment | d({})
                   | combine(inventory__group_environment | d({}))
                   | combine(inventory__host_environment  | d({})) }}'

  roles:

    - role: proc_hidepid
      tags: [ 'role::proc_hidepid', 'skip::proc_hidepid' ]

Ansible tags

You can use Ansible --tags or --skip-tags parameters to limit what tasks are performed during Ansible run. This can be used after a host was first configured to speed up playbook execution, when you are sure that most of the configuration is already in the desired state.

Available role tags:

role::proc_hidepid

Main role tag, should be used in the playbook to execute all of the role tasks as well as role dependencies.