This is a discussion on Re: outsourcing DCE/RPC to alternate programs - - Samba ; -----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 ...
-----BEGIN PGP SIGNED MESSAGE-----
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
| 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
|>| 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
|>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)
| that key difference makes it a) worthwhile protecting as
| root-only-accessible b) useful for optimisation purposes between
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
| 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
| 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----