9

While searching for an answer to the question "how to hide command arguments from ps/proc etc", I came across the hidepid mount option, which hides a user's own processes from another user (of course also command args launched from another user).

Why such a useful option is not used by default?

I want to remount mount -o remount,hidepid=2 /proc with this option for one of the modes (which I choose when starting via GRUB, the restricted mode for surfing the Internet) during the boot process.

2

2 Answers 2

4

When using Linux the /proc filesystem can be remounted with additional arguments:

mount -o remount,rw,hidepid=2 /proc

  • hidepid=1 hides all processes information but not the process itself from other users, except root.
  • hidepid=2 hides all processes from other users, except root.

Reasons not using hidepid=2:

This can be a problem for a lot of system and monitoring tools, which are executed with a specific user. Those tools should not run as root user.

For example, you are using htop to monitor your whole system, htop needs to be run as root user or with sudo to get the right privileges.

In a corporate network tools like Monit or Nagios are installed on servers and each tool has it's own user.

Using hidepid can result in using root accounts more often and this can result in a higher risk to get compromised.

Advantages when using hidepid=1 or hidepid=2:

The system becomes harder to compromise. For example you have a shared server and other users can connect via ssh to this server. Each user can access all processes and read process information.

Some applications can be started with username and password as an argument. Those information can be read by any user. Using hidepid=1 or hidepid=2 hides this information from other users.

Conclusion:

Using hidepid can improve the security, but you have to know the disatvantages. For most users and systems it's not necessary to hide the information.

For example, if you have a single user system (desktop) you have already root privileges and it's likely, that you are the only user working on this system.

A dedicated company webserver should allow ssh logins only for system administrators and most of them needs root privileges for administrative tasks.

There are also some best practices which can reduce the risk of information lost. You should never provide a password as a command line argument. Most applications provide a dedicated prompt to enter the password. If you need the application in a batch job, you should use configuration files, which are only accessible by the service user, to configure credentials.

1
  • 1
    Note: The gid mount option of the proc filesystem can be used to alleviate some of the issues you described, especially around system monitoring tools. Such tooling can receive the group set on the proc mount as a supplementary group to retain access to process information without granting full superuser permissions. Aug 13, 2023 at 13:14
4

Here is an article that discusses some problems with hidepid=1 and hidepid=2, and recommends against using it on RHEL, at least until software like systemd is able to handle it better.

RHEL systemd Engineering considers that using hidepid=2 is not recommended at all on RHEL7 and later due to many reasons exposed below.

The main purpose of the hidepid= mount option is the ability to not disclose information (to the given user) about processes of other users running on the same system.

There are at least three problems that arise when this option is used.

First, the proc filesystem mount is a global entity that exists inside a given mount namespace. Hence, if any mount option is used on proc filesystem mount then it affects every process which runs in the same filesystem namespace. In many cases this is not desirable and causes further issues.

Previous issue leads to the second problem. If hidepid= option is used then some system services like (PolicyKit or D-Bus) are not able to query information about the clients which are connecting to them. This is because all these services run as non-privileged (i.e. euid != 0) and hence don't see needed information in /proc/[pid] directory of the client, unless the client runs under the same uid which is never the case (at least for PolicyKit and D-Bus).

Last problem, that we would like to highlight is potential information leak and false sense of security that hidepid= provides. Information (PID numbers, command line arguments, UID and GID) about system services are tracked by systemd. By default this information is available to everyone to read via systemd's D-Bus interface. When hidepid= option is used systemd doesn't take it into consideration and still exposes all this information at the API level.

Because of these issues we don't recommend at this time using hidepid= option on RHEL7 and later.

This guidance may change in future as we work on improvements to kernel's proc filesystem implementation as well as on systemd and other system services (e.g. PolicyKit and D-Bus) that are negatively affected by enabling hidepid= mount option.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .