Toolbox functions from non-console terminals

73550000 matthew at ucscb.UCSC.EDU
Fri Jul 29 15:30:05 AEST 1988


In article <111 at obie.UUCP> wes at obie.UUCP (Barnacle Wes) writes:
>In article <4230 at saturn.ucsc.edu>, matthew at ucscb.UCSC.EDU (73550000) writes:
>> Unfortunately, toolbox-based programs are runnable by anyone who is
>> logged in.  This can cause problems if I am trying to use the Mac
>> monitor/keyboard as the console terminal.  If some other user runs
>> /usr/toolboxbin/term,... I get a terminal window for THEIR account on
>> MY screen.
>
>Actually, there are several things you can do.  The easiest is to make
>sure none of the accounts other than yours have /usr/toolboxbin in their
>path.  Any experienced Unix user can get around this pretty easily, but
>if your users aren't Unix people, it will suffice for a while.

My users are UNIX people.
UNIX hackers in college, in fact.

>
>Another trick is to make the tools in /usr/toolboxbin part of a special
>group, say `toolbox'.  Then chmod all the executables there to be owner
>and group execute, and no world priveledges.  Then add yourself and
>nobody else to the group `toolbox' (in the file /etc/group).  Then when
>you want to run a toolbox program, just type `chgrp toolbox' before
>typing the command to run the program.  This scheme is much more secure
>than the first suggestion.

I've thought about this. See below.

There are things other than the supplied toolbox programs that can cause
problems. Such as a user who has the source to 'qdsamp'
'qdsamp' can run with or without the toolboxdaemon running, and causes
the console screen to be overwritten. There are also the possibilites
of someone sending ADB commands to reprogram the mouse or keyboard.
Even programming the keyboard to send 'bad' commands to the user's shell
logged in on the console.
Do I need to put the libraries and include files in a special group also?...
and hope that noone else can compile things for my users?
There should be some way of locking access to physical screen memory, etc...
so that it can only be controlled from a process running on the console.

Matthew Kaufman
matthew at ucscb.ucsc.edu
...!ucbvax!ucscc!ucscb!matthew



More information about the Comp.unix.aux mailing list