matthew@ucscb.UCSC.EDU (73550000) (07/22/88)
Does anyone know of a clean fix for the following problem: I have an A/UX system that I am planning on allowing serial-port access to so that others may log in. (I may also allow rlogin, telnet if I get a network connection) 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. Other programs could do more destructive things (like program my mouse to send 'rm -r /' to the console when the program exits) Does anyone have any ideas? Matthew Kaufman matthew@ucscb.ucsc.edu ...!ucbvax!ucscc!ucscb!matthew
wes@obie.UUCP (Barnacle Wes) (07/26/88)
In article <4230@saturn.ucsc.edu>, matthew@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. 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. Some other areas you might want to look at include the restricted shell `rsh' & restricted editor `red', and the `chroot' call for user accounts. Use of these would be pretty extreme, and would be used primarily where you have a hostile user environment, like a BBS with a lot of nasty hacking going on :-). Wes Peters -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --
matthew@ucscb.UCSC.EDU (73550000) (07/29/88)
In article <111@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <4230@saturn.ucsc.edu>, matthew@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@ucscb.ucsc.edu ...!ucbvax!ucscc!ucscb!matthew