Major security problem in the UA: looking for a real fix

Alex S. Crain alex at umbc3.UMD.EDU
Mon Feb 15 12:29:25 AEST 1988


In article <184 at shlepper.ATT.COM> andys at shlepper.ATT.COM (a.b.sherman) writes:
>In article <114 at hodge.UUCP>, rusty at hodge.UUCP (Rusty Hodge) writes:
>> [Description of several well known holes in the UA]
>> 
>> Let's face it: the UA is *evil*.  Get rid of it.

>But what if you like the convenience of the UA and multiple windows? 
	[solution involving super-group deleted]

	System security is a very real problem that doesn't have a quick & 
dirty (or quick and clean) solution. Unix is an open system with security
holes up the wazoo, and closing the obvious ones only make the problem more
subtle. Sorry, but someone who needs to ask about what to do with the UA 
simply isn't qualified to do battle with a experianced hacker, period.

	A large hidden issue is this: If a system admin closes all the holes
that he knows about, then he won't have any idea how the hacker broke his 
system. So this approch doesn't work.

	The stock solution, regularly used for anonymous ftp, is to have
two groups of users, trusted and not trusted. Trusted users are given a free
run of the system, non-trusted users (guest logins, etc) get a restricted
shell and very limited access to the system (see rsh(1)). Since a 3b1 will
only support a few users, this should work for most cases, and after all,
If I don't trust someone enough to think that he won't trash my system, who
cares if he gets windows or not?

	For LANS and educational facilities, I prefer logs and traps that
track problem users instead of barriers, but thats off the subject, really.
-- 
					:alex.

nerwin!alex at umbc3.umd.edu
alex at umbc3.umd.edu



More information about the Comp.sys.att mailing list