Security for decapitating/recapitating the squeak display?

Stephen Pair spair at advantive.com
Thu Feb 14 15:41:00 UTC 2002


Yes, this is something I've been thinking about.  I'm using is socket
service to handle capitation/decapition.  Here's what I think is ideal:

Squeak support for:

	SSH (as a server)
	Integration with external authentication services (like PAM)
	Integration with external directory services (like LDAP)
	A multi-user object memory

With these, we could provide the capitation service over an SSH
connection, authenticate the user against either an authorized internal
user (like the users of Swiki.net), or authenticate against and
authorized external user (like a Unix user), or use an external system
to authenticate (like PAM).

Now back to the real world: We can provide simple security by
restricting access to the capitation service by IP address (i.e.
localhost), having a list of allowed X servers, and firewalling it all.
This will allow anyone with an account on the machine to do capitation
to a fixed list of displays.  It's better than nothing.

I think it would be wrong to attempt security inside the
primitive...ulimately Squeak needs a general purpose multi-user/security
capability.  When that arrives, it could be leveraged to authenticate
users attempting to do such things as capitation (or various other
primitives).  Providing one-off security implementations would lead to a
mess I think.

Also, if squeak were multi-user, we could log off the current user
before decapitating.  In fact, squeak should support multiple heads in a
multi-user scenario.

- Stephen

> Great, thanks!
> 
> So ... is this OK from a security point of view? I would want 
> to make sure that an arbitrary user could not figure out how 
> to open the display on an X server of their choice. One of my 
> thoughts was that the recapitate primitive may need to 
> require a key or a password before permitting the display to 
> be reopened. Will Swiki.net need this, or does it provide 
> security for this through some other mechanism?
> 
> Dave




More information about the Squeak-dev mailing list