Re: [CAD_CAM_EDM_DRO] Re: EMC Kit

[shackle-at-cme.nist.gov (Will Shackleford)]

> From emc-at-nist.gov Mon Nov 15 10:55:26 1999
> Date: Mon, 15 Nov 1999 10:54:49 -0500 (EST)
> Originator: emc-at-nist.gov
> From: Fred Proctor <proctor-at-cme.nist.gov>
> To: Multiple recipients of list <emc-at-nist.gov>
> Subject: Re: [CAD_CAM_EDM_DRO] Re: EMC Kit
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> Content-Transfer-Encoding: 7bit
> X-To: CAD_CAM_EDM_DRO-at-onelist.com, emc-at-nist.gov
> MIME-Version: 1.0
> 
> Ray Henry wrote:
> 
> > In a recent post, Jan raised the issue of security concerning the EMC
> > software on a shop floor machine .  IMO this issue is common to all pc
> > based systems but since parts of the EMC must run as root, and now all of
> > it runs as root in a standard setup, the system is extra vulnerable.
> ..
> > What can we do?
> 
> If you need to protect the system against inadvertent changing or
> removal of files, it's fairly easy. Protecting against determined
> hackers is more of a problem. Easy way:
> 
> 1. Set up a normal Linux user account, say "ray", with a home directory,
> say /home/ray.
> 
> 2. Ray won't be able to run the EMC for three reasons:
>   a. it requires running the /sbin/insmod, /sbin/rmmod, and /sbin/lsmod
> programs to install/remove/list the EMC motion controller;
>   b. it requires accessing /dev/mem to use the shared memory interface;
> and
>   c. it requires running privileged inb/outb instructions for the
> parallel port IO.
> 
> 3. You can get around the first problem by changing the permissions on
> /sbin/insmod and /sbin/rmmod so that they are "setuid root". This means
> that they run as if root is running them. Set this up, as root, by
> doing:
> 
> 	chmod u+s /sbin/insmod /sbin/rmmod /sbin/lsmod
> 
> Now, anyone can run insmod. So, for example, a talented programmer could
> write his own kernel module that ran through the file system looking for
> protected user files; remove files; etc. Writing a kernel module is not
> something you do inadvertently.
> 
> 4. You can do the same sort of thing with /dev/mem, by making it
> read-write for everyone. As root, do:
> 
> 	chmod a+rw /dev/mem
> 
> Now, anyone can access /dev/mem and access Linux memory directly. This
> isn't something that can be done inadvertently. You can set up Unix
> pipes to write 0's into memory and clobber Linux, but you can also flip
> the power switch on the front.
> 
> 5. You can change the permission on emc/plat/<whatever>/bin/bridgeportio
> so that it runs setuid root also. As root, do:
> 
> 	chmod u+s /usr/local/nist/emc/plat/<whatever>/bin/bridgeportio
> 
> Now it runs as root and can execute the privileged inb/outb
> instructions.
> 
> There are better ways to set things up using groups of semi-trusted
> users so not everyone can run the EMC, and so those who can still aren't
> root. If anyone has any other ideas let me know.
> 
> --Fred
> 


Would another possibility be to run  the rtlinux stuff and the modules 
that directly connect to them in some .rc file at startup and then let "ray" run 
only the user interface?  I think that this would mean "ray" would have to 
completely reboot the machine to restart the main controller, but not have 
access to the /dev/mem or insmod"

Of course if "ray" is truly evil and talented and knows how to reboot in 
single-user mode with a floppy. The only thing that might prevent tampering 
would be to lock the PC with the EMC controller on it in a box and force "ray" 
to use a user interface connected remotely to the EMC controller.


-- Will