feigin@linc.cis.upenn.edu.UUCP (10/28/87)
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 ??
(n.b. acls on sigp and /bin/kill have been set so that only members of our
'organization' can execute them)
Any help is much appreciated. Thanx.
Adam
------------------------------------------------------------------------------
Internet: adam@hyper.lap.upenn.edu
UUCP: {harvard,decwrl,mit-eddie,ihnp4}!linc.cis.upenn.edu!feigin
(in decreasing order of preference)
Adam Feigin
"Knowledge is a deadly friend, Network Administrator
if noone sets the rules; the Language Analysis Project
fate of all mankind, I see, University of Pennsylvania
is in the hands of fools" Dept. of Linguistics
Room 440, Williams Hall
King Crimson Philadelphia, PA 19104-6305
(215) 898-1955
-----------------------------------------------------------------------------peterson@utah-cs.UUCP (John W Peterson) (10/28/87)
> > 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". I wouldn't be surprized if SR10 fixed this, but it's been a "known bug" for some time. Cheers, jp
kwongj@caldwr.caldwr.gov (James Kwong) (10/29/87)
> > 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". > > I wouldn't be surprized if SR10 fixed this, but it's been a "known bug" > for some time. > > Cheers, > jp How about: Write a script/program call "kill/sigp" Rename the real kill and sigp to something else. In the new "kill/sipg" do the following: Get the paramenter(s) passed to it. Parse it for PID/UID and other options Do a ps -auxN . Obtain the environment variable of the username. Compare the enivronment name with the user name obtained from the "ps -auxN".If the names match, call the real kill/sigp with the parameters. Otherwise print error message. You may have to do something about the real kill/sigp so that they are "hidden" from normal users.... We're running SR9.5 also and have noticed other minor security problems 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. 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. I been hearing rumors that Apollo may go to a more "native UNIX" later. Cross your fingers. James Kwong 1416 9th Street Rm. 249 Sacramento, CA 95802 (916) 322-9430 Calif. Depart. of Water Resources ucdavis.edu!caldwr!kwongj (Internet) ...!ucbvax!ucdavis!caldwr!kwongj (UUCP) Disclaimer: The opinions expressed above are mine, not those of the State of California or the California Department of Water Resources.
mishkin@apollo.uucp (Nathaniel Mishkin) (10/30/87)
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