Re: Using unix sockets for NSPort

[Richard Frith-Macdonald]

On Friday, October 4, 2002, at 01:17  pm, Jeff Teunissen wrote:
> IMO, this is a case where both the OpenStep spec is clearly wrong for a
> multi-user system, and Mac OS X's implementation is partially wrong; 
> the
> default case should always be as secure as possible. NeXTstep, 
> OPENSTEP,
> and Mac OS X are essentially single-user operating systems -- two users
> can't really log on graphically at the same time, and the safety 
> aspects
> of having the pasteboard server connected to from another machine, or 
> of
> having applications being talked to by apps on other systems, isn't 
> seen
> as that big a problem -- and for the most part, it isn't on those 
> systems.
> But on the systems where GNUstep runs (except for Windows, which is
> already riddled with such security holes), it's a long series of 
> disasters
> waiting to happen.

Yep ... currently *very* insecure ... though the existing DO API 
provides
for secure DO authentication, nothing actually uses it.  While I can't 
see
gdnc information beng very important, the pasteboard info is potentially
quite sensitive.

> However, the OS X implementation does (almost) provide a way to do the
> right thing. My suggestion is:
>
> If you ask specifically for an NSMessagePort, you get the Apple 
> behavior:
> a port that is public to the machine, but not available to the network.
> Apple supports this method, so it's not a deviation from that "spec".
>
> If you ask for an NSSocketPort, you get pretty-much exactly what 
> GNUstep
> has now with NSPort -- something that works both locally and across the
> network if it's registered.
>
> The difference is: when you ask for a generic NSPort, you get a
> GSMessagePort (a subclass of NSMessagePort with a private directory as 
> its
> "staging area"). This is the only real difference from the Apple
> implementation. By default, Apple returns an NSMessagePort

Yep ... I think this would be a good default ... when we have a 
thoroughly
robust implementation of such a private DO system.

> > > 1. Security. Nobody else can connect to your services or mess with
> > > your pasteboard. Apps only connect to your ports, so nobody can set 
> > > up
> > > an evil pasteboard and store everything you cut/copy/select (or 
> > > change
> > > it; ever pasted something in a terminal?).
> >
> > It might well make sense to do this ... it would prevent use of
> > Xterminals with GNUstep apps, but that might not be important.
>
> I don't think it does. With an X terminal, all of the executables are
> always running on the app server, and so can all communicate with each
> other. There's no pasteboard server running on an X terminal, nor is 
> there
> a distributed notification server.

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.

> > Sounds like a nice overall structure, but I'm not ready to scrap the
> > existing implementation ... it's robust, efficient, safe.   Looking at
> > your code I can see a simplifying assumptions made because unix domain
> > ports are fast and reliable (would be inappropriate for a tcp sockets
> > port), and no support for threading or timeouts ... so I'd suggest
> > making a thread-safe version for local messaging, and making it work
> > non-blocking so that a failed remote process won't hang your
> > application.
>
> I don't think the existing implementation would need to be scrapped --
> rather, refactored a little. As far as I can tell, most of it can be 
> moved
> wholesale into the more comprehensive architecture.

Well, I don't care about scrapping the existing code as long as we 
replace
it with something better.

I want the following features of the existing code -

high reliability ... well tested/bug free.
fault tolerant ... mustn't hang the process if the other end fails to 
respond etc.
high performance ... must not use threads for instance.
thread safe ... so if someone wants to use threads they can use DO 
between them.

And I'd really like to add some extensions -

A security framework to provide access control for DO servers ... not 
sure about
what exactly this should do though.  Certainly it would be nice to have 
a two level
system, so that the system manager could enforce some security 
policies, and provide
defaults for others (which individual users could override).
Hooks for easy SSL encryption
Hooks for data compression perhaps


My guess is that modifying GSTcpPort to support unix sockets would be a 
much faster
route to this than adding the required features to the example code 
code alexander
supplied, on the other hand his example nameserver code looks usable 
with minimal
alteration already.