Saturday, December 1, 2007

Old Style ps On Solaris 10

A lot of admin's may have heard this complaint already, but I'm just starting to hear it now from users who are upset about the change in functionality of the /usr/ucb/ps command (as opposed to the standard /bin/ps command).

Up to Solaris version 9, "/usr/ucb/ps -aguxwwwww" would give you extremely detailed ps output (like the entire 2 pages of output from a java command, for instance). Theoretically, in Solaris 10, it still does. Alas, in reality, it doesn't. Here's a link to the publicly available Sun Alert Notification that explains the issue in more detail.

The reason for this stems back to a vulnerability (feature ?) that was discovered in Solaris 8 and 9, regarding /usr/ucb/ps, whereby a user could use the program to view another user's environment settings/variables if they used the "-e" switch. Patches were released for both Solaris 8 and 9, and Solaris 10 was claimed to not be affected by it.

However, all the security patches for Solaris 8 and 9 really did was strip the setUID bit on /usr/ucb/ps and Solaris 10 was released with a /usr/ucb/ps binary that came with 0555 permissions standard (users could no longer get the extended output, but root still could). This would suggest that, perhaps, Solaris 10 wasn't ever really "immune" to the vulnerability, but, more simply, came with the work-around set as the standard. A quick test shows that this is, indeed, the case. Check out the following on a simple /usr/ucb/ps test against the cron process. Note that this is run on a Solaris 10 box, with very recent patch-levels, and I've changed the permissions of /usr/ucb/ps from 0555 to 4555: # uname -r
5.10 # /bin/ps -ef|grep "[2]35"
root 235 1 0 Sep 12 ? 0:07 /usr/sbin/cron # /usr/ucb/ps -eaguxwwww|grep "[2]35"
root 235 0.0 0.0 2840 1864 ? S Sep 12 0:06 /usr/sbin/cron LC_COLLATE=en_US.ISO8859-1 LC_CTYPE=en_US.ISO8859-1 LC_MESSAGES=C LC_MONETARY=en_US.ISO8859-1 LC_NUMERIC=en_US.ISO8859-1 LC_TIME=en_US.ISO8859-1 PATH=/usr/sbin:/usr/bin SMF_FMRI=svc:/system/cron:default SMF_METHOD=/lib/svc/method/svc-cron SMF_RESTARTER=svc:/system/svc/restarter:default TZ=US/Central

Looks like the problem hasn't actually been "solved."

So, there you have it; /usr/ucb/ps on Solaris 10 actually does still show regular users the environments of any user that calls a program. Of course, stripping the setUID bit makes that impossible again, but it also makes it impossible for regular users to get extended output for those long java command lines that they need to see.

There are several work-arounds for this work-around. For instance, you could try to use "pargs." It won't work without the setUID bit either, but at least it will tell you that it can't and not just shoot you truncated output with no explanation. > pargs -e 235
pargs: cannot examine 235: permission denied

Probably the best way to work-around this, and satisfy Sun's security requirements is to make use of a program called sudo (comes with Solaris 10). Just include a rule like the one below, so that users can only run "/usr/ucb/ps -aguxwwww" and can't run /usr/ucb/ps with any other command arguments, except straight-up with no arguments. They'll get the long output they need and will be prohibited from running /usr/ucb/ps with any other command line switches, like the terrible "-e." Example rule below:

ALL ALL = (root) /usr/ucb/ps -aguxwwww, /usr/ucb/ps ""

We'll go into more detail about sudo in a future post, in all probability. For now, here's a quick rundown on how this rule plays out:

ALL <--- All users can use this sudo rule
ALL <--- This command can be used on any host.
= <--- Pretty self explanatory ;)
(root) <--- These command will be run as the user root
/usr/ucb/pas -aguxwwww, /usr/ucb/ps "" <--- This is the list of allowed commands. The first command specifies that /usr/ucb/ps can only be run with the "-aguxwwww" switches. The second command (multiple commands separated by commas) specifies that the user can also run /usr/ucb/ps with no switches at all (The "" (double-double quotes) indicate that no switches are allowed after the command)

Now, everyone should be happy. You've kept the security flaw from being exploited, retained the /usr/ucb/ps permissions, satisfied the Sun Alert requirements and allowed users to be able to get their extended ouput.

If only every annoying problem were so easy solved ;)

, Mike