Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!manuel!anucsd!arcturus!paulus From: paulus@arcturus.anu.oz.au (Paul Mackerras) Newsgroups: comp.realtime Subject: Re: VxWorks "security"? Message-ID: Date: 3 Jun 91 23:10:07 GMT Article-I.D.: arcturus.paulus.675990607 References: <1991Jun3.183523.8212@unhd.unh.edu> Sender: news@anucsd.anu.oz.au (USENET News software) Organization: ANU Department of Computer Science Lines: 29 rg@msel.unh.edu (Roger Gonzalez) writes: > How do people restrict access to >VxWorks targets over the net? > Somehow I can just picture a hacker telnetting >to our robot and accidentally turning thrusters on... We use VxWorks to control some robots here (the Australian National University) and we had the same concerns. The solution which I came up with is a real hack, but it was sufficient for our environment: I patched the rlogin code in VxWorks so that it compared the username supplied by the remote rlogin program with the username specified with the iam command, and rejected the rlogin (by closing the socket) if they were not equal. E.g. if you say "iam paulus" at the VxWorks system, then only someone with a username of paulus on a Unix system can rlogin to the VxWorks system. We disabled telnet access altogether when we built VxWorks. Fortunately rlogin supplies both the real username of the person logging in as well as the username that they want to log in as (supplied with the -l flag). We check against the real username. Because we don't have source to VxWorks, I had to do the patch as a binary patch---i.e. by storing the address of a substitute function into the word at address &rlogind + 620 (!). Our other concern, besides the possibility of interference with the robot, was the fact that, using VxWorks with NFS, you can access (read or write) any file on any filesystem which is exported to the VxWorks system by an NFS server.