[Sunhelp] About top

[Doug McLaren]

On Thu, Oct 19, 2000 at 10:39:48PM +0100, Leon Halford wrote:

| Top & for that matter freeware programs are not generally as useful
| as they first appear.

That is one of the most idiotic statements I've ever seen.

`freeware' programs are a very large part of what make *nix far more
useful than most other OS's.

| top in particular introduces security problems to Solaris.

?
 
| Solaris 8 has a "top" clone called /usr/bin/prstat - I suggest
| you use that.

Alas, the Solaris 2.6 box I'm looking at doesn't have it.  So that
doesn't help much unless you have 2.8 ...

| Whilst we're on the topic, top should definately never be made
| available to any user other than root on a production server.
| A mistake I have seen all too often.

Uh-huh.
 
| Why?
| 
| Well as you rightly point out it gives users the ability to easily
| kill processes. Bad pratice even if its their own application.
| That however is nothing compared to this:
| 
| top requires any given user running it to be a member of group
| "sys" on Solaris such that they can read /dev/kmem - ie physical
| memory!

Oh really?

   % id
   uid=2318(dmclaren) gid=10(staff)

I'm obviously not a member of group kmem.

   % ls -la `where top`
   -rwxr-xr-x   1 root     staff        267 Mar 25  1999 /usr/local/bin/top

top obviously isn't setuid or setgid.

   % top | head -15
   ...
   Memory: 256M real, 85M free, 176M swap in use, 593M swap free
   ...
     PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
    2325 dmclaren   1  28    0 1448K 1352K cpu     0:00  1.16% top3.5-2.6
    2304 dmclaren   1  38    0 2336K 2184K sleep   0:00  0.09% tcsh
    2326 dmclaren   1  48    0  856K  784K sleep   0:00  0.05% head
    1450 nobody     4  50    0   21M 4032K sleep   1:12  0.00% ctlds
    1462 nobody     4  10    0   21M 3960K sleep   0:55  0.00% ctlds
    1615 nobody     4  20    0   22M 4736K sleep   0:43  0.00% ctlds
     335 oracle    40  59    0   27M   10M sleep   0:37  0.00% oracle

and top is obviously working.  Fancy that!

To be fair, I thought top did need access to read kmem on Solaris.
After all, the `ps' command is setuid root -

   % ls -la `where ps`
   -r-sr-xr-x   1 root     sys        26372 Jul 15  1997 /bin/ps
   -r-sr-xr-x   1 root     sys        26372 Jul 15  1997 /usr/bin/ps
   -rwsr-xr-x   1 root     sys        21536 Jul 15  1997 /usr/ucb/ps

... but apparantly top works fine without it.

As for top requiring that a user be a member of the kmem group to use
it, you've never heard of a setuid/setgid program, have you?  They
allow a programmer to set up a program that runs as a different uid or
gid than the user running it.  This is how a *nix box allows users to
do things that require enhanced priviledges, like changing your
password or doing an ICMP ping.

If top DID need to read /dev/kmem, you'd just make it setgid kmem and
it would work fine -- you wouldn't need to make your users a member of
the kmem group.  Yes, this does require some dilligence on the part of
the person who writes programs that are setgid or setuid to make it
secure, but done properly they're safe.  And top should have been done
properly, because in some cases it does need to be setgid kmem.

Yes, it's possible that a program like top could have a bug in it to
where *if it were setgid kmem* that this could be used by a user to
gain read access (not write access!) to /dev/kmem.  I'm unaware of any
such bugs.

Note that /bin/ps could also have bugs like this, and since it's
setuid root, the possible danger is much greater.  And it's not the
only such program -- for a list of other setuid/setgid programs that
*could* have such bugs on your system, run this -

   find / -type f -perm -2000 -o -perm -4000 -ls

Just because they came with Solaris doesn't mean they're secure.

| If that wasnt bad enough, group "sys" happens to be a
| very powerful group on Solaris, because not only does it have
| read access to /dev/kmem it has read access to every disk device
| too - which implies a member of group sys can read ANY file on
| any local file system including root owned files (ie /etc/shadow
| etc). I leave this as an experiment for you all, but it's easier
| than you may think, certainly no programming is required.

Actually, I leave this as an exercise to you.

In my installation, top is not setgid kmem, so you can't use it to
read /dev/kmem.  But I suggest that you go ahead and set it to setgid
kmem on your site.  Make sure your user is NOT in the kmem group (he
shouldn't be) and then use top to gain arbitrary read access to
/dev/kmem.  I don't think you can do it, even if you DO do some
programming.

| Alternatively as a work around to adding users to group "sys"

What does group `sys' have to do with /dev/kmem -

   % ls -la /dev/kmem /devices/pseudo/mm at 0:kmem
   lrwxrwxrwx   1 root     root          27 May 19  1998 /dev/kmem -> ../devices/pseudo/mm at 0:kmem
   crw-r-----   1 root     sys       13,  1 May 19  1998 /devices/pseudo/mm at 0:kmem

Let me answer for you - *absolutely nothing*.

| you can start fiddling permissions on /dev/kmem to make top
| available to non root users - but as soon as you do that you
| break other programs and of course pkgchk will immediateley
| complain.

| Dont do it! Stick to using "prstat" or "/usr/ucb/ps -aux" on
| pre Solaris 8 machines as they are *much* safer.

Uh-huh.

-- 
Doug McLaren, dougmc at frenzy.com
`But officer, I was only trying to gain enough speed so I could coast
 to the nearest gas station.'