Home / ubuntu / Questions / 13599
Accepted
poolie
Asked: 2010-11-17 17:51:50 +0800 CST

How to hide process arguments from other users?

  • 772

A while ago, I used to use the grsecurity kernel patches, which had an option to hide process arguments from other non-root users. Basically this just made /proc/*/cmdline be mode 0600, and ps handles that properly by showing that the process exists but not its arguments.

This is kind of nice if someone on a multiuser machine is running say vi christmas-presents.txt, to use the canonical example.

Is there any supported way to do this in Ubuntu, other than by installing a new kernel?

(I'm familiar with the technique that lets individual programs alter their argv, but most programs don't do that and anyhow it is racy. This stackoverflow user seems to be asking the same question, but actually just seems very confused.)

security kernel

5 Answers

  1. The only way to do this currently is to put each user in a separate container (see clone with CLONE_NEWPID and CLONE_NEWNS), and mounting a new /proc in the container. (lxc will do some of this for you.)

    However, there are plans to be porting grsecurity features to the Ubuntu and upstream kernels. If you can, please sign up for something and help out.

    • 8

  2. Up to and including Natty it is not possible to change the permissions on the /proc/$pid/cmdline files with the stock kernel, the permissions bits are built into the kernel. Currently you would have to build a bespoke kernel with those patches applied.

    If the patches are simple to enable this functionality then it may be worth posting them to the Ubuntu Kernel Team list ([email protected]) and we can consider them for inclusion in future releases.

    • 6
  3. Best Answer

    There is now a hidepid mount option for procfs that lets you hide arguments from other users, and optionally allow one group to see all processes:

    The first mount option is called "hidepid" and its value defines how much info about processes we want to be available for non-owners:

    hidepid=0 (default) means the old behavior - anybody may read all world-readable /proc/PID/* files.

    hidepid=1 means users may not access any /proc/PID/ directories, but their own. Sensitive files like cmdline, sched*, status are now protected against other users. As permission checking done in proc_pid_permission() and files' permissions are left untouched, programs expecting specific files' modes are not confused.

    hidepid=2 means hidepid=1 plus all /proc/PID/ will be invisible to other users. It doesn't mean that it hides whether a process exists (it can be learned by other means, e.g. by kill -0 $PID), but it hides process' euid and egid. It compicates intruder's task of gathering info about running processes, whether some daemon runs with elevated privileges, whether another user runs some sensitive program, whether other users run any program at all, etc.

    gid=XXX defines a group that will be able to gather all processes' info (as in hidepid=0 mode). This group should be used instead of putting nonroot user in sudoers file or something. However, untrusted users (like daemons, etc.) which are not supposed to monitor the tasks in the whole system should not be added to the group.

    hidepid=1 or higher is designed to restrict access to procfs files, which might reveal some sensitive private information like precise keystrokes timings:

    http://www.openwall.com/lists/oss-security/2011/11/05/3

    hidepid=1/2 doesn't break monitoring userspace tools. ps, top, pgrep, and conky gracefully handle EPERM/ENOENT and behave as if the current user is the only user running processes. pstree shows the process subtree which contains "pstree" process.

    • 6

  4. Years ago I published the following two kernel patches:

    Those two patches still work for the current stable vanilla kernel from kernel.org. If you're interested I can post the current patch. Don't ask me why never anybody included a process hiding option in the upstream kernel.

    Warning: These patches completely hide processes of other users except for root.

    • 1

  5. You could stop them from accessing system monitor and top, by changing their permissions in the users and groups settings. I'm not certain this will be a complete solution but it should be sufficient to block this from most common users.

    • -2