Slaying Gould dragon with a wooden

[Lawrence W. McVoy]

This is probably going to blow any chances I had of working for Gould,
but given what I've heard about them over the year or so, I'm not too
interested anyway...

Flame/Snickers/Jabs On>>>

In article <1500001 at gswd-vms> andy at gswd-vms.UUCP writes:
>
>
>SUMMARY: Darryl Wagoner broke into the system and deserves
>	 (will get) the TV.
>
>         Gould is still HIGHLY confident in the security of UTX/32S
>         and is willing to 'up the ante'.

Ha.  Double or nothing, huh?  You guys are sorry losers.  And, no, 
guys, I will __NOT__ volunteer to do your homework for you.  If you
want to _pay_ me to sit down with the src to the whole system, and 
give me unlimited time, I'll bet that I can find holes.

>In the case of UNIX expo, the system administrators made a few
>*mistakes*.  The two main mistakes were putting "." as the first
>thing in their PATH and executing a user's program for him, as
>superuser no less!  

No kidding.  This is only about the _most_ well known trick in the
book.  I used it (successfully) when I was a sophomore in college.
Did you guys ever read the paper on Unix security?  Just in case...
"UNIX Operating System Security",  Grampp & Morris, AT&T Bell
Labs Tech Jour 63, pp 1649-1672, October 1984.  You might check it
out, it's a neat article.

>The system administrator's guide also says:
>
>     When you are working as superuser, any command or file
>     executed, directly or indirectly, may run with
>     superuser privileges.  Therefore, avoid running any
>     file that could have been created or modified by a
>     general user.  It is imperative that superuser
>     privileges be used as sparingly as possible.
>
>Unfortunately, our staff at the booth at the EXPO faithfully
>followed the instructions for a piece of third party S/W that
>explicitly asked that "." be put in the PATH. 

Chuckle, chuckle.  It really helps if you _read_ the documentation,
but I bet the guy running the booth _knew_ what he was doing.  He'd
already RTFM.  He was a Unix _guru_.  Snort, snicker, chuckle.

	      (My apologies if he was a "she").

>This is, however, a weak excuse, and certainly a fatal excuse in 
>an environment where security is critical.  

No kidding, really?  And you are trying to sell this product?

>In UTX/32S the setuid bit has been removed.  

Oh, I get it, it's not Unix, it just looks like Unix.  Next thing 
you know, they'll take out job control, and signals (those are really 
dangerous, ya know).

>* UTX/32S is a secure version of Gould's UTX/32  operating system
>and is certifiable at the C2 level as defined in the Department
>of Defense Trusted Computer System Evaluation Criteria (TCSEC).

Yeah, right.

<<<<Flame/Snickers/Jabs Off

OK, a few comments.  Let me see if I have this straight;  You spent
years of effort to cripple Unix, got it rated as a secure system,
and then in your first (I hope it was the first) public demonstration
you let some bozo throw all your effort down the tubes.  Good move.
(I _hope_ it was a salesman running the both, not someone who claims
to know unix).

Seriously, if I were trying to buy a secure OS, I'd stay away from
Unix.  I'd probably stay away from anything that allowed logins.
And I'd certainly stay very far away from a product that was sold
by a company that screwed up this badly.

The bottom line is this: security is not just code (as you've 
discovered).  And screwing up like this suggests that your 
security is not anywhere near as good as you'd like us to
believe.  We have no way of knowing what other holes are still
unplugged.  How can you expect us to believe that you've done
a good job when you fail the simplest test?  

And this bit about removing the setuid bit.  Tsk, tsk.  In my eyes,
you guys are just lazy.  I think it would be pretty easy to deal
with setuid programs.  For shell scripts, start them out with

	"unalias *"
	"set path=()"

For C programs, change the system(3), exec??(3), and exec(2), calls
to check and see if these programs are "known" to be safe.  You could
still allow execs; just turn off setuid in the exec call.  That gets
rid of exec-ing to csh.  And the finger bug...

And that leaves stuff like the sendmail bug.  Well, you can probably
get around that one by using groups and setgpid.  Very few things 
_have_ to be setuid to root.
-- 
Larry McVoy 	        mcvoy at rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy

"They're coming soon!  Quad-stated guru-gates!"