scott@mcs-server.gac.edu (Scott Hess) (12/11/90)
As most of you now know, the problems with the microphone security hole are solved a number of ways, one of them apparently being via the public sound server flag in 2.0. This allows you to limit the use of the sound server to the person on the console. This is all well and good, but I've got some gripes with the limiting that is used. It's all or nothing. This is bad, bad, because then you either close off everyone, or you have to throw yourself wide open to the world. Say, for instance, that you've written a NextStep program to allow you to communicate with someone by opening up a context to their screen and bringing up a window on it - talk about distributed programs! Anyhow, this is obviously going to require them to set public window server. But, now all manner of people can come in and run screen hacks on them, like melting their screen or generally making it fall apart? Why!?! This isn't really needed. I would recommend that the people at next in charge of this type of thing look to rlogin for more capabilities. rlogin is nice, in that you can set it up so that certain friendly hosts who are allowed to login to the machine without passwords. For instance, I have my .rhosts file set to allow myself to simply type rlogin nic to get a shell on the machine nic at gac.edu. (actually, I've got /usr/hosts set up here, too, so all I have to do is type 'nic' :-). This gives a lot of utility, yet doesn't really compromise security in my case - because my password exists at our top level domain, if someone breaks into my account on one machine, they can get to them all, anyhow. So facilitating inter-machine connectivity inside the password barrier really doesn't harm anything. Of course, with the windowserver you are a little safer. People who connect wouldn't be removing files and reading stuff, but just putting up windows or apps. Which isn't that dangerous (unless they do workspaceWindow Above 0 orderwindow, of course). And, the fact that you can limit this to certain people on certain machines is a plus, also. Maybe this could be done via a Workspace or loginwindow default. You specify a list of machine/user couplets which are forwarded to the windowserver, who then stores them as appropriate. When someone tries to connect, this list is tested to see if they are allowed. Added niceness would be the ability to change the list at runtime, so that you can add someone for a short time and then take them away later. That would be useful for when you log into a remote NeXT, because you could then run an app over the network, and later remove those rights. Good idea? I think so. How about getting this into 2.1 . . . :-) -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."
rca@cs.brown.edu (Ronald C.F. Antony) (12/12/90)
When it comes to limiting access to the window server and the sound server there are a couple of things that need urgently to be changed. e.g. if you want to write a server application that is constantly running and provides services to a net of NeXT machines and needs access to the screen, you are screwed. I don't see why we cant go the good old unix way: create a device. e.g. /dev/winserv and /dev/sndserv that are chown'ed to the user at login and back to root at logout. These devices could have group assignments such that other applications that were installed by trusted staff for this purpose, can access the device in any case by default. In addition the user could set the permissions analog to regular file permissions in preferences. So where is the big problem with that? Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
rbeach@slate.mines.colorado.edu (Richard Beach 986-7977) (12/18/90)
Or maybe not even as sofisticated as rlogin. How about following the
road-tested xhosts program. It allows you add or remove one or more
hosts from a list that have permision to write to the X-server. In
fact the Athena release of X had an xhosts that did its job quite nicely.
NeXT could add a nice graphical inteface, and away the age of interpersonal
computing could go. :)
---------------------------------------------------------------------------
Richard Beach @ Colorado School of Mines Golden, Colorado USA
I-Net and BitNet : rbeach@mines | CS/CH
or : rbeach@slate.mines.colorado.edu |
UUCP : ...isis!csm9a!rbeach |