Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mit-eddie!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: Network Security (turing off kill in csh)
Message-ID: <382e7d17.c366@apollo.uucp>
Date: Fri, 30-Oct-87 14:55:00 EST
Article-I.D.: apollo.382e7d17.c366
Posted: Fri Oct 30 14:55:00 1987
Date-Received: Wed, 4-Nov-87 22:48:34 EST
References: <2359@super.upenn.edu> <5087@utah-cs.UUCP> <123@caldwr.caldwr.gov>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 54

In article <123@caldwr.caldwr.gov> kwongj@caldwr.caldwr.gov (James Kwong) writes:
>> > On an generic 4.2 system, kill will not allow you to signal processes that
>> > you do not own; however, under DOMAIN/IX (SR9.5) I seem to be able to kill
>> > any process that I choose (even processes owned by root !!!). Is there any way
>> > to turn off kill in the c-shell ??? Is this a bug in DOMAIN/IX ??? Is there
>> > a way around this problem other than giving remote users an AEGIS shell ??
>> > 
>> The lack of process security (except for the DM) has been a problem since
>> day zero (actually day SR6, when CRP was invented).  Restricting remote
>> users to the Aegis shell doesn't really help, because they can still go
>> blasting away with "sigp".

Not to be contentious here or anything, but let's remember that these
systems were designed to be *personal* workstations and that in general
users have physical access to the systems and could "kill" any process
simply by hitting the reset switch or, albeit with more effort, they
could subvert the system in any one of a number of less catastrophic
ways that are possible if one has physical access.

Having said that, it would clearly not be hard to fix kill(2) to fail
if applied to a process the kill-er doesn't own.  (Maybe someone will do
or has already done that -- I don't know.)  However, one shouldn't be
deluded into thinking that as a result of that fix, the system has been
made extraordinarly more secure.

>I noticed that the "/com/edacct" was set so every/anyone could execute
>it no matter which security option you picked (open, personal, system).
>This allows you to change account info. like password locally and then
>to propagate it across network later. You have to re-acl it so only
>sys_admin or root can invoked it.

I think this is really more an issue of the protection of the "/registry"
tree.  The right thing to do would be to appropriately protect that tree,
not protect the tools that manipulate it (because clearly the data could
be manipulate using "private" versions of the tools).  It seems like
a bug if our installation procedure does not at least give one the
option to protect the registry files.

>You can also "crp" or "rlogin" to another node and issue the "halt" 
>command. This will cause the node to shut down to the debugger level.

Presumably the solution is along the same line as the kill "fix" I describe
above.  We could certainly make "halt" check to see that the caller is
"root".  (There's also the issue of whether "root" permissions are allowed
to apply between nodes -- e.g. whether one can "crp -me" or "rlogin"
while logged in as "root" and become "root" on another machine.  People
will be upset if we prevent it or if we allow it.  I'd be happy to hear
comments on this topic.)  But again, physical access must be controlled
so that the would-be "halt"er can't just hit the reset switch.
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin