Re: Using unix sockets for NSPort

[Richard Frith-Macdonald]

On Friday, October 4, 2002, at 09:41  pm, Alexander Malmberg wrote:
> > But not all executables are necessarily running on the *same* app
> > server!
> >
> > Also, an Xterminal is actually a special case of the more general
> > problem
> > of apps using -NSHost to work on a different display to the machine 
> > they
> > are executing on.
> > Really, we should try to think of a proper solution to the security
> > issues
> > implied by remote hosting.  I don't think simply disallowing it is 
> > very
> > good.
>
> Simply disallowing doesn't solve the problem, but neither does the
> current system, and simply disallowing is secure.

Not sure what you mean ... the current system works fine but is not
secure, using local private DO would be secure but wouldn't work :-)

As long as we provide a mechanism to switch to a working system,
for this (tiny ... I only know of one person who claims to use
Xterminals with GNUstep ... it's not me) case, I don't see a problem
with making the private DO solution the default, so that the
system is more secure out-of-the-box.

But I'd like a *better* security solution than that.

For instance, the pasteboard server could be extended to use the
existing DO authentication system to expect all packets to be tagged
with a private session key created when the user starts up.
In this scenario, the first app to use the pasteboard might start
the server (as a subtask on the end of a pipe), the server would
then generate a session key and write it to stdout before forking to
become a daemon, the app would read the key and save in the defaults
database, then connect to the server.  Other apps started later could
read the key from the defaults database and be able to talk to the
server. The whole process would be hidden from the user but would
give them a totally secure connection to the pasteboard.
Of course, network packet sniffing could let people get at the data ...
to avoid that we would have to encrypt the data rather than just
tagging it.  The Apple API doesn't allow that, but the GNUstep one
does since the GNUstep authorisation callbacks are allowed to replace
data being sent/received rather than just adding and removing a 
signature.

A few more thoughts about security/scope of servers.

gpbs ... should probably be limited to a single user, but should ideally
be shared between different displays that the user is working on.  So 
this
should in an ideal world use secure tcp connections (the mechanism I
outline above is not adequate ... needs something like kerberos to allow
the user to take a security token around from machine to machine).
Optionally available to other users to support cooperative working.

gdnc ... should be limited to a single logical display (may be more than
one physical screen), but likely not a security issue and therefor not
necessarily limited to one user.

apps ... generally apps are tied to users and displays, so it makes 
sense
to have them restricted to the local machine by default.  However, use 
of
-NSHost to get them to display on another machine would change this and
require the use of tcp connections.

tools (daemons) ... generally provide services to many users and 
machines
so would not be restricted.  However, a default policy of local 
connections
would do no real harm as the tool programmer can trivially override it.

So ... from this it seems to me that local/private DO is a great default
to give us a fair degree of security in the simple (overwhelmingly most
common) cases, but is *NOT* an overall solution.

I'd really like to use tcp/ip as the default transport ... giving us
access over the network, but have the connections SSL encrypted and have
access to each server controlled by certificates using a web of trust
like gpg/pgp.  However, this is all beginning to sound like to much 
work.
I'm not proposing we do anything now ... just think about it a little.

The short term solution is to add unix domain sockets and a user default
to select between them and tcp/ip sockets as the default port type...
crude but an improvement.


Incidentally, long long ago, I had this idea of an efficient pasteboard
for huge chunks of data.  When I wrote the NSData class I included a
shared memory data object - I always intended that when using local
DO connections, large  (megabyte plus) chunks of data would be placed
in shared memory data objects and passed over the DO link by reference
rather than copied.  That's still an enhancement I'd quite like ...
just waiting until there are apps around that could really use it.