outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Sun, Dec 12, 2004 at 07:50:22PM +0100, Jelmer Vernooij wrote:
> -----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.
 
  ack.

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

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

 yes.  saves an awful lot of time.


> Why not negotiate
> once again, just like you would've done with external (non-local)
> connections?

 because in the case of NT authentication, that's really expensive!!

 plus, if you're using a security-context-inheriting implementation of
 ncalrpc as an inter-server communication mechanism between the
 components _of_ the NT authentication mechanism (which is what i do in
 samba tng for netlogond, lsarpcd and samrd), then you are stuck.


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

 yes, it does.
 
 if you're implementing things like samrd, netlogond and lsarpcd,
 which is the context in which samba tng's context-inheriting ncalrpc 
 transport was designed to optimise, then that's not a bad thing.

 ... i.e. you'd be insane to run samrd as anything other than root!

 
 i did consider writing ncalrpc "proxies" which would create
 pipes accessible by specific users (by on-demand creating
 a directory with the caller's uid rwx------ and creating a
 socket in that) but ... to be honest ...
 
 there wasn't a pressing need for it, the existing tng ncalrpc Did The
 Job It Was Designed To Do.

 so i didn't bother.
 
 no pressing need, to need to press for a solution.
 

> and it forces
> external projects that hook into Samba to understand this 'proprietary'
> security context info blob. 

 *thinks*...

 yes it does.... no it doesn't.
 
 at least two projects have already taken this approach - samba tng, and XAD.

 the "proprietary security context info blob" is exactly that: a blob.

 you receive it, you associate it with the connection, you pass it over,
 in fact you _don't_ see it except at second or third hand.

 there's no actual need for the external projects to _do_ anything with
 it except if they wish to impersonate the user associated with the
 "blob".

 and even then, if they want to do _that_, they will call an
 appropriate function to handle the impersonation.

 i don't see any problem here.
 
 in the case of adding ncacn_np support to FreeDCE, i just
 implemented the transport and it handled the communication
 of the "blob" transparently.



 

> Also, I don't think the overhead of the auth
> negotation is too much 

 ..+*???? really???? what happens when you are running as a member of an
 nt domain, and your authentication server is on the other side of a
 LAN?

 you _really_ want each service to contact the PDC?  *gibber*!


> (one could negotiate a very simple low-cost
> mechanism). 

 such as having a root-only-accessible credentials cacheing mechanism,
 to deal with the scenario outlined above?

 ... mmmm... there's a place where that information can be stored - in a
 structure associated with the connection, and in FreeDCE there's
 already some places which can do that, along with a fully supporting
 API that caters for exactly this purpose!!


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

 ah, no - definitely not.

 that's _exactly_ what _can't_ be done.

 FreeDCE is a completely different runtime environment from
 samba (it's more complete and better understood, for a start -
 note i didn't say more secure / less able to deal with buffer
 overrun attacks!)

 it'd be a god-awful job to have to ask people to understand and code
 for both the samba 4 _and_ the FreeDCE runtime environments.

 it's just too much to ask.


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

 that's what andrew said, in 2000.

> at least for the moment being.
 
  by not having a security-inheriting ncalrpc mechanism, you can't
  realistically use DCE/RPC at all to implement the inter-server
  communication mechanism between netlogond, samrd and lsarpcd.

  in other words, you are forced to design and use your own
  APIs: you can't use the APIs that are already designed for
  the job [the netlogon API, the samr API and the lsa API!!!!]

  well you can, but you have to bypass the DCE/RPC bits.

  in other words, by making the decision that you have, you end up,
  for "simplicity", putting all netlogond samrd and lsarpcd into one
  single monolithic program.

  called smbd.


  by following the example laid down by NT, and emulating what i
  believed the underlying infrastructure to be, i was able to simplify
  the design and implementation of the NT services.

  ... for example, the trick about implementing a msrpc_netlogon_auth()
  function that accepted "\\." as a shortcut to use ncalrpc rather than
  ncacn_np meant that the same code that did "security = domain" could
  also be used for "security = user".

  _and_ the same code could be used for inter-domain trust account
  authentication.



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

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

 ah ha.
 
 that's what rich was referring to about the udp forwarding trick, yes?

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

 okay.

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

 in the context of an authentication service being a minimal number of
 roundtrips: you're right - it definitely isn't worth it.

 in the context of running a server as a member of an NT domain,
 the overhead of having to do an SMB IPC$ connection followed
 by a DCE/RPC ncacn_pipe connection using SMBtrans2, followed
 by a NETLOGON connection over that - just to authenticate
 in one service when you just authenticated another service
 a few millseconds ago???

 ... naaaah :)
 
 bearing this in mind, perhaps people will appreciate exactly
 _why_ i started adding into the samba tng msrpc libraries the
 ability, just as NT does, to "cache" and reuse both SMB IPC$
 connections, MSRPC connections and ncalrpc connections.

 that's why NT maintains SMB IPC$ connections (see output of NET USE
 after logging in to an nt domain).

 if you want to prove to yourself that it has an effect, on the PDC run
 service control manager, examine the connections being held to the PDC,
 kill them off and then try doing something on the domain member
 workstation (e.g. accessing a second domain workstation's files as a domain
 user).

 the operation is delayed until the SMB IPC$, and the NETLOGON
 connection _over_ the SMB IPC$ connection, is reestablished.

 try reconnecting to the second domain workstation _without_ killing the
 first workstation's connection to the PDC and the connection is made
 much quicker.

 l.