outsourcing DCE/RPC to alternate programs - runtime config option

[Jelmer Vernooij]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Luke Kenneth Casson Leighton wrote:
| On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote:
|>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?
It currently is root-only though that might change in the future, though
we haven't discussed that much yet.

|  as opposed, say, to having just ncacn_unix_socket?
There isn't much difference between ncalrpc and ncacn_unix_socket /at
the moment/, except for the fact that ncacn_unix_socket takes the path
to a unix socket and ncalrpc takes just an identifier (LRPC432423:432432
for example).

|>|  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.
So that's basically handing over a security context info along with
every new connection to pipes you're forwarding to? Why not negotiate
once again, just like you would've done with external (non-local)
connections?

|  that key difference makes it a) worthwhile protecting as
|  root-only-accessible b) useful for optimisation purposes between
|  services.
This however, forces you to run all services as root and it forces
external projects that hook into Samba to understand this 'proprietary'
security context info blob. Also, I don't think the overhead of the auth
negotation is too much (one could negotiate a very simple low-cost
mechanism). If optimisation is very important (and you don't care
running as root), you could always compile your interface implementation
as a plugin and load that into smbd.

|  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?
I think it makes things more complex then they have to be, at least for
the moment being.

|  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.
No, we don't do that and we can not do that implicitly (can't ask a Unix
OS what SID belongs to a certain pipe).

|  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...
That's correct (for now at least).

|  ...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? ]
it can support multiple interfaces at one endpoint. And it can forward
endpoints to other endpoints.

|  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] ?
At the moment, none.

|>> ...but a ncacn_ux or ncacn_shmem _would_ fit the scenario you envisage.
| ah  :)   no it wouldn't - not entirely.

| ncacn_ux cannot do that: it starts off as an unauthenticated transport,
| and you have to _perform_ authentication over it.

| that takes CPU cycles, in the case of NT authentication it takes dozens
| of round-trip communications waking up four or five separate services.

| ... you just can't afford to let that happen all the time,
| just because you're contacting another service - you could
| potentially end up with disastrous recursive authentication
| behaviour (and before i added sec-ctx inheritance to tng's
| ncalrpc,  i _did_ once get a massive number of samrd, netlogond
| and lsad processes until the box fell over  :)

| hence the optimisation in samba tng's ncalrpc implementation: once you
| have a security context, pass it around, in the knowledge that you are
| passing it between services that are running _as_ root, over a
| transport that is root-only-accessible.
As said above - I don't think the optimisation is worth it - at least
not yet.

Cheers,

jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBvJLtPa9Uoh7vUnYRAr+kAKCS2q28NQlZYHTnshmBBGPClnMt6gCcD4+I
Fa3r1nmrzLBWmeHS0iIHm3I=
=Sa4n
-----END PGP SIGNATURE-----