[Sunhelp] About top

[Leon Halford]

Game Over.

-----Original Message-----
From: sunhelp-admin at sunhelp.org [mailto:sunhelp-admin at sunhelp.org]On
Behalf Of Doug McLaren
Sent: 21 October 2000 00:45
To: sunhelp at sunhelp.org
Subject: Re: [Sunhelp] About top


On Sat, Oct 21, 2000 at 12:02:37AM +0100, Leon Halford wrote:

| It helps if you read messages correctly before replying. There is
| no such group "kmem" on Solaris - I referred to "sys". By your own
| foolish admission "sys" has group ownership of /dev/kmem
| (`ls -lL /dev/kmem`). Therefore "sys" *does* have a very
| significant role in this debate (unlike the reference you make in
| your final paragraph).

You're right.  Sorry about that.  Solaris isn't the only OS I deal
with.  It doesn't change the rest of my points, however.
 
| FYI, you are using the unpriviledged version of top (stripped down)

Stripped down how?  I don't see any missing features.

Stripped down or not, it's extremely useful, something no system
should be without.

| thats why it works without /dev/kmem access.. which I accept is
| safer.

s/safer/completely, utterly safe/.

A non setgid, non setuid copy of top on your system does NOTHING to
decrease the overall security of your system.

If properly written, even being setgid or setuid won't comprimise your
system either.

| As for your suggestion of making top setuid root - that would give
| every user the ability to kill another users process from within
| "top" (using the [k]ill command) ... not a very clever thing at all.

I didn't suggest making top setuid root.  I suggested setgid kmem
(yes, for Solaris, it should be setgid sys instead, I know.)

Also, even if setuid root, top doesn't allow you to kill other
people's processes.  If you read the README file -

   CAVEAT: version 3 of top has internal commands that kill and renice
   processes.  Although I have taken steps to insure that top makes
   appropriate checks with these commands, I cannot guarantee that these
   internal commands are totally secure.  IF YOU INSTALL top as a SETUID
   program, you do so AT YOUR OWN RISK!  I realize that some operating
   systems will require top to run setuid, and I will do everything I can
   to make sure that top is a secure setuid program.

Of course, Sun makes no guarantee that /bin/ps is totally secure
either :)

| Then you refer to making /dev/kmem setgid - an interesting concept

I said no such thing.  What I said was -

   If top DID need to read /dev/kmem, you'd just make it setgid kmem and

`it' refers to top, not /dev/kmem.  I do realized that the English
language tends to be ambiguous, but context tells what I meant.

| given its a device not an executable file. But even if you meant
| making top setgid "sys", for the reasons I outlined before you may as
| well hand out the root password if you're granting "sys" membership to
| 3rd party programs which most people never even test for authenticity.

As opposed to 1st party programs, like Solaris's /bin/ps, which nobody
but Sun can even test for `authenticity'?  (though a better term would
be `security')

At least with top you can check it yourself, even if most people
don't.  And since it seems to work on Solaris just fine, even when
it's not setuid or setgid, I can't see any reason whatsoever not to
put it on your Solaris system if you think it'll be useful.

| As for your challenge.. Let's do it. Create me a user account on
| your Solaris internet server with group membership "sys". Given
| shell access I guarantee you that I can mail you the /etc/shadow
| file within 5 minutes.

No, that was not my challenge.  That was your `experiment'.  My
`challenge' (not my choice of terms) was :

  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.

(Replace kmem with sys, of course.)  Adding users to the sys group
(your `how to make top work, but don't do it!' workaround) is very
different from making top setgid sys.

I'll give you extra points if you can use this arrangement to get
*root access* (not just group sys) on the box.  To be fair, at least
on the box I'm looking at there's lots of directories that are
writable by sys (why?!@) so it shouldn't be that difficult to slip in
a trojan program or two.  But you'll still have to trick top into
giving you a GID sys shell first.

| Put your money where your mouth is! I'm ready and waiting... :-)

Put my money where your mouth is, you mean.  No thanks.

-- 
Doug McLaren, dougmc at frenzy.com
"Bother," said Pooh as he depleted the ozone layer.
_______________________________________________
SunHELP maillist  -  SunHELP at sunhelp.org
http://www.sunhelp.org/mailman/listinfo/sunhelp