outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote:

jelmer, hi,

i'm doing my usual thing of answering the questions you ask.
it means that the message is getting somewhat long, and issues
described several times.

if you don't mind, after i've thought about it a bit more, i may
reply with a summary message as well - later.

> |>I think what Tridge means is actually 'forwarding' the RPC data (for
> |>which Samba4 already has support, e.g. you can redirect a complete pipe
> |>to a remote server) instead of having a hack that bypasses the local
> |>endpoint and talks to a local pipe.

> |  is it possible to convey the security context that has been established
> |  up until that point?

> Not yet, currently the whole thing is root-accessible-only. We do
> actually do auth over it, as does Windows (see
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/string_binding.asp).
 
 okay... so if it's root-only-accessible, yet doesn't inherit
 security context, what is the difference that makes it [samba 4
 ncalrpc implementation] worthwhile having?

 as opposed, say, to having just ncacn_unix_socket?


> |  the purpose of the root-only-accessible ncalrpc transport is to provide
> |  communication optimisations *inside services running as root*.
> Why? Windows uses them for regular users as well, otherwise there
> wouldn't be much point in authentication
> info passing...
> 
> What would the purpose of such a root-only-accessible ncalrpc-like
> transport you propose be ?
 
 exactly as you have it except that, like ncacn_np, it has
 the ability to convey - or pre-inherit - security context
 information - over from the calling program.

 that key difference makes it a) worthwhile protecting as
 root-only-accessible b) useful for optimisation purposes between
 services.

 the reason _why_ you can add security context inheritance between
 caller and called is _because_ it's root-only-accessible.

 e.g. in the samba tng implementation of netlogond and samrd, netlogond
 needs to contact the samr daemon to obtain account information, in
 order to make the NTLM challenge-response calculations to feed
 authorisation and session information out to a client.

 if you were to use a samba 4 ncalrpc implementation, then
 somehow you need to provide an authentication mechanism or
 authenticate somehow over the ncalrpc connection between
 the netlogond and samrd: or somehow provide an external
 communication path that conveys security context between the
 netlogon server and the samr daemon.

 if you use the samba tng ncalrpc implementation, then you dig up the
 (vuid and pid) index associated with the netlogond, initiate a
 connection to the samrd using that (vuid+pid) to indicate to the samrd
 that it should use the same [root] security context that netlogond is
 presently running as, and netlogond will successfully convey its
 present security context over to samrd with an absolute minimum of
 effort.

 have you considered this issue?




> |  in other words, you don't want the headache of communicating
> |  between services over globally-accessible interfaces and
> |  having to prove authenticity once more, whether those interfaces be
> |  ncadg_ip_udp, ncacn_ip_tcp or ncacn_np or Other.
> |
> |  and you _also_ need to add a "ncacn_ux" to the list of available
> |  transports just like there are ncacn_np etc listed above.
> Already did that. 

 GREAT!

> Samba 4 currently supports ncacn_ip_tcp, ncacn_np,
> ncacn_unix_stream 

 *GREAT*!

> and ncalrpc. For example, epmapper is available on:
> ncacn_np:[\\pipe\\epmapper]", "ncacn_ip_tcp:[135]",
> "ncalrpc:[EPMAPPER]", "ncacn_unix_stream:[/tmp/epmapper]

 that's really good.

> |  it is vital that you do not confuse the roles of the two interfaces:
> |  they are mutually incompatible for the uses to which they are put.
> Which interfaces are you referring to here - ncacn_unix_stream and
> ncalrpc ?

 yes.

 okay, i assumed (or asked for confirmation and assumed to be
 the case until otherwise told) that your implementation of
 ncalrpc had the ability to, how-shall-we-say...  "inherit",
 like ncacn_np does, security context.

 i understand now that you do not have the ability to inherit
 [pass] security contexts.

 therefore, the statements i made about it being possible to
 use samba 4's ncalrpc transport for optimisation purposes
 with respect to inter-service communication is wrong.


> What is their difference, other then that they are two different transports?

 primarily, the key difference that is _worthwhile_ is of
 inheriting security context.

 ncacn_unix_socket cannot convey security context, just like
 ncacn_ip_tcp and ncadg_ip_udp cannot.

 there is no purpose, rhyme or reason for protecting an implementation
 of ncalrpc as root-only-accessible if it doesn't have anything to
 protect!

 and if it doesn't inherit security context, then you might as well not
 bother implementing it or using it, because it is effectively covered
 by ncacn_unix_socket: all you have to do is specify
 ncacn_unix_stream:[/var/ncalrpc/EPMAPPER] and, unless i am missing
 something, you've pretty much got exactly the same thing...

 ...give-or-take a few details.
 
 [i am led to believe that the samba 4 implementation of
 ncalrpc has the ability to multiplex many endpoints over the
 one socket?  have i got that correct? ]

 so to reiterate: what is it about the samba 4 ncalrpc implementation
 that makes it worthwhile having, that ncacn_unix_socket does not, that
 does not have the disadvantages of ncacn_np [i.e. having to go via a
 full-blown SMB server] ?

 l.