Re: Using unix sockets for NSPort

[Alexander Malmberg]

Richard Frith-Macdonald wrote:
> 
> 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 :-)

The current system does not work. It works when using something x11/
based and the connection to the X server is a completely 'normal' tcp/ip
connection. This is very common, but it's not the only case. As an
example, it doesn't work when I 'ssh -X' to an outside system and run
apps there, and it can't; the remote system has no way of connecting to
my system.

(Unless someone writes NSSendMessagesUsingXWindowHintsPort :).

> 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.

Sounds OK.

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

In the general case, we can't.

> 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.

But only for apps that can access the local defaults database.

[snip]
> 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.

I'm not sure I agree here. If I was running stuff on two different
displays on two different systems, I don't think I'd expect the
pasteboard to be shared. However, if I run an app as another user but on
the same display, I'd still expect the pasteboard to work.

[snip]
> 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.

There are a lot of potential security and practical problems with this,
though, so I still think it's better to restrict it to one display.

> 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.

Depends on how the connection to the display works. IMHO, the solution
to all of this is to make everything local to one display by default. In
practice, this means that it should be using local user-only ports on
the machine the display is running on, and remote apps would need to
tunnel connections over the display connection.

I plan on implementing this with rds; at least it'll show whether it
works or not. For other display systems (X, windows), this will be
tricky to handle. All the authentication would happen between the
display server and the rds backend. Exactly how is another question, but
at least it's a fairly well localized problem. Once the connection with
the display server is established, I'd want to replace
NSMessagePort/NSMessagePortNameServer (and others?) to resolve on the
displaying system instead of the system running the app.

> 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.

I agree.

[snip]
> 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.

True, this could be very useful. I don't know of any current app/tool
that transfers that much data, though.

- Alexander Malmberg