rg@msel.unh.edu (Roger Gonzalez) (06/04/91)
We'll be using SPARCstations to develop code for our underwater
vehicle which will run VxWorks. How do people restrict access to
VxWorks targets over the net? Do you set up a subnet? A gateway? If
you'll be having some high bandwidth traffic running between a VxWorks
target and say, a SPARC running a simulation, is it best to set up
a gateway or subnet? Somehow I can just picture a hacker telnetting
to our robot and accidentally turning thrusters on...
-Roger
--
Geek joke: Why did the plane taking off from Warsaw crash?
Too many poles in the right half of the plane.
rg@[msel|kepler].unh.edu | UNH Marine Systems Engineering Laboratory
| Durham, NH 03824-3525paulus@arcturus.anu.oz.au (Paul Mackerras) (06/04/91)
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.
vestal@SRC.Honeywell.COM (Steve Vestal) (06/04/91)
paulus@arcturus.anu.oz.au (Paul Mackerras) writes: Paul> rg@msel.unh.edu (Roger Gonzalez) writes: > Somehow I can just picture a hacker telnetting > to our robot and accidentally turning thrusters on... Paul> University) and we had the same concerns. The solution which I came up Paul> with is a real hack, but it was sufficient for our environment: I patched Paul> the rlogin code in VxWorks so that it compared the username supplied This raises another issue that, for lack of a better term, I'll call timing security. I did some careful timing measurement & analysis on a VxWorks system and discovered that there were sporadic bursts of activity that couldn't be accounted for by any of the application tasks or application-required VxWorks services. I speculated that some of these bursts were due to VxWorks occasionally handling ethernet messages. Although the overall load was small -- maybe 1% utilization in our environment -- the actual duration of a sporadic burst wasn't negligible, especially as the frequency of application tasks increased. The time spent rejecting an rlogin attempt might possibly, in some applications, cause an application timing fault (missed deadline). Steve Vestal Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 Phone: (612) 782-7049 Internet: vestal@src.honeywell.com
fjr@sgfb.ssd.ray.com (Fred J. Roeber) (06/26/91)
In article <1991Jun4.133608.24773@src.honeywell.com> vestal@SRC.Honeywell.COM (Steve Vestal) writes: > >This raises another issue that, for lack of a better term, I'll call timing >security. I did some careful timing measurement & analysis on a VxWorks >system and discovered that there were sporadic bursts of activity that >couldn't be accounted for by any of the application tasks or >application-required VxWorks services. I speculated that some of these bursts >were due to VxWorks occasionally handling ethernet messages. Although the >overall load was small -- maybe 1% utilization in our environment -- the >actual duration of a sporadic burst wasn't negligible, especially as the >frequency of application tasks increased. The time spent rejecting an rlogin >attempt might possibly, in some applications, cause an application timing >fault (missed deadline). > I'm just getting caught up on this group so I may be missing a little future information. I have been off doing some detailed timing analysis of VxWorks operations with concentration on the networking code. As far as the occasional traffic, that is probably the fact that periodically (every 30 seconds) the VxWorks networking code "times out" the ARP addressing table entries and then goes out to try to get new addressing information. There is some way to mark the ARP table entries as permanent (through an ioctl call) but we haven't bothered doing that yet. As far as the security issue on rlogin, the 5.x release of VxWorks has an optional security package that can be built in. It supports password security and should be able to handle your problem. We haven't bothered to configure it in. Hope this helps. Fred