7

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.)

5 Answers 5

8

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.

6

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

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.

1

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.

-2

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.

3
  • 1
    Which setting is this? When I start Users and Groups then click Advanced I see a bunch of settings, corresponding to different Unix groups, but nothing about running the system monitor or top. Obviously I could chmod those programs, but that is a bit too weak.
    – poolie
    Nov 17, 2010 at 3:30
  • I think if you stop them from being able to administer the system it blocks them. I can't confirm this at this time unfortunately because I'm the only user on my laptop :(
    – RolandiXor
    Nov 17, 2010 at 3:32
  • 1
    I'm pretty sure that controls membership in group admin, which is by default the group of users allowed to sudo to root on Ubuntu. If we had this proc acccess control feature, we could let only those users see other users' command lines. But we apparently don't.
    – poolie
    Nov 17, 2010 at 3:37

You must log in to answer this question.

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