-----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/de...ng_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+kAKCS2q28NQlZYHTnshmBBG PClnMt6gCcD4+I
Fa3r1nmrzLBWmeHS0iIHm3I=
=Sa4n
-----END PGP SIGNATURE-----