outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Sun, Dec 12, 2004 at 11:39:31PM +0100, Jelmer Vernooij wrote:

> |  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!
> 
> Not necessarily - what samr calls strictly need to run as root? SAMR is
> mostly
> just a custom database.
 
 yes, i thought about this a bit more - it's a bit like running mysql as
 the mysql user.

 perhaps samr was not a good example.

 for the same reasons, neither is lsarpcd (it too has a database of
 "secrets" to protect - a la LsaQuerySecretInfo).

 overall, i think - actually - the only reason for running as root is
 _because_ of the root-only-accessible ncalrpc implementation!

 just like it is in samba 4.

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

> The issue here is really how to efficiently authenticate an incoming
> connection from smbd in the process it is outsourcing data to. 

 ... with the proviso that that's only relevant should you
 choose to implement adding security context inheriting to 
 samba 4 ncalrpc of course.

> I'm by no
> means an expert in CIFS/RPC/Samba's authentication system, but I'm
> thinking of something like:
> 
> ~ - Having a new DCERPC_AUTH_TYPE_SAMBA that just receives the username
> of the NT user and takes it for granted if the receives it from a
> process owned by the same user

 yerrss... but also you need to pass over the schannel / session key
 information.


> ~ - Doing caching in lsarpc / samr / netlogon - not sure where this
> happens and always using the local instance of an interface to verify
> credentials (which can then ask the DC if necessary) rather then always
> asking the DC.
> 
> Though no doubt others in the team with more experience in this area
> have better ideas.
> 
> |>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.
> Why would one want to use FreeDCE when you're already using Samba 4?
> What does FreeDCE that Samba4 does not? Samba 4 provides for an endpoint
> mapper, for example.
> 
> I can understand you would want to use FreeDCE in combination with Samba
> when using Samba completely without RPC subsystems and just for the
> ncacn_np transport, having FreeDCE provide for the endpoint mapper, etc.
> 
> |>|  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.
> My problem with this solution is that it is a bit ad-hoc. Where are you
> going to get the vuid+pid when the connection came in over  TCP/IP or
> UDP/IP? 

 you don't: it's completely irrelevant for anonymous-based connections.

 well i say irrelevant but, in the case of samba tng, if an
 authentication request comes over an anonymous connection, then
 a copy of the vuid_struct is stored in the tdb (using the vuid+pid as
 the lookup)

 and from there, _that's_ when it gets picked up should any tng ncalrpc
 msrpc calls be made.

 so to clarify, when anything OTHER than a ncalrpc call comes in, you DO
 NOT expect - ever - to somehow pick up an authentication context, yes?

 so you don't :)


> With remoting you would get a nicer solution, almost for free,
> eventually combined with one of the two solutions mentioned above.
> 
> This way ncalrpc(tng-ncalrpc) becomes something that smbd can use to
> 'outsource' interfaces. 

 yes.

> Other local non-root utilities can't talk to it
> directly and root utilities will have to construct the blob somehow. 

 yes, that's exactly what's done.
 
 in rpcclient when you use rpclient -S \\. where "." is
 the servername shortcut semantics i created meaning "use
 the ncalrpc transport", that is exactly what i do: i call a
 function which creates a vuid_struct and primes the tdb with
 it, such that the ncalrpc client-side code will have a hope
 of finding it.

 of course, you're running rpcclient as root so you can get away
 with it - and can also do the equivalent of setuid by running
 "rpcclient -S \\.  -U setuidusername" 
 
 if you were to try the same thing as a non-root user, it'd fail because
 you wouldn't be able to access /usr/local/var/samba/.msrpc/whatever.

 consequently, you'd have to go via smbd authentication, connecting
 either:
 
 * as an anonymous user of the SMB IPC$ connection (which would
 have the effect of creating an "anonymous" vuid+pid pair and
 stuffing an anonymous vuid_struct into the tdb), and then
 over that anonymous SMB IPC$ onto a ncalrpc connection,
 performing authentication (in the case of rpcclient's
 samrpasswd function), which would result in a SECOND
 vuid_struct being created but this time under a different vuid.

 * as an authenticated SMB user (which would have the effect of creating
 an "authenticated" vuid+pid pair and stuffing an authenticated
 vuid_struct into the tdb) which would then be carried over the


> In
> order to connect to such interfaces they'll have to talk to smbd which
> forwards their data to the specific interface implementation.
> 
> 
> |   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.

> I don't consider that much of a problem at all - what is the issue with
> implementing 3 interfaces in one daemon? 

 it's just a design decision that i would consider to be closing down a
 few strategic options (hinted at below)

> We're not trying to build an
> exact copy of windows - we're building network services compatible with
> Windows on a POSIX-compatible operating system.

 yes - and i believe that you will find that the more you
 deviate from "compatible with windows" in the NT domains area, the more
 confusing and the more work you will end up doing.

 on the file-sharing side, that clearly, clearly, clearly does not
 apply.

 but, as you know, the file sharing is only a small fraction (albeit the
 one that so so many people believe to be the _only_ fraction!) of the
 total work and scope involved.


> Wine and ReactOS are more or less clones of Windows while Samba tries to
> be compatible at network level - Samba's design doesn't need to be a
> clone of Windows' design nor can it be - we have to make sure we can
> work with and map to POSIX. 

 ah :)  and how much is actually POSIX?
 
 i think you'll find if you think about it carefully it's pretty much 
 file access (and indirectly, unix authentication).

 think about it from this perspective, which makes it abundantly clear
 how small the reliance on POSIX actually is.

 if someone were to add in proper support for the linux NTFS filesystem
 driver into samba, and you only published NTFS partitions via the
 smb.conf file, where is POSIX critically involved in that?

 do you _need_ to authenticate as a unix user?  do you _need_ to call
 seteuid?

 at all?

 what about printing: if you're redirecting to CUPS network or even
 local CUPS printers - do you _need_ to call seteuid then?

 in fact, do _any_ of the NT-compatible services that you're
 implementing rely critically and exclusively on seteuid() or
 any other POSIX-specific functions that, if you think about it
 carefully, you can't find in Win32?

 (leaving aside the issue of accessing native unix filesystem
  access).

 the answer, i think you will find, is no!

 
 see, now you're getting to the issues that made working with
 andrew and jeremy so difficult for me - the exact argument
 you just gave was used to terminate any possibility for
 compromise, thereby shutting down any possibilty for samba's
 codebase to be conveniently leveraged in any other projects
 (i.e. without any forking or other maintenance headaches).

 i am _so_ pleased about the flexibility of the samba 4 vfs
 systems that have been put in place, because it opens up some
 of the possibilities that were formerly closed.


> Sure, there are various parts that are
> similar to Windows because we're talking the same protocol but it's not
> a copy, just another implementation of the network protocol.
 
 yes it is - but wouldn't it be cool to be able to compile
 samba on ReactOS - natively - and also to use it to expand
 the functionality of Wine?

 e.g. for people to put the winreg code in Wine where it belongs -
 behind a ncacn_np:\\winreg interface as a proper server?

 wouldn't it be cool also to support NTFS partitions properly in samba,
 via the linux ntfs driver project?


> |   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.
> I think that's a really neat trick - though it does not require what you
> are proposing.

 no it doesn't, but it's the flip side of the coin that, if implemented,
 would make smbd 3.0 completely independent of its internal [in-house]
 authentication system, opening up the possibility of smbd 3.0 to use
 _any_ NT-compatible authentication system (samba tng, samba 4, XAD,
 whatever).

 i _think_ you might not even need to make any code modifications to
 samba 3 in order to "get it to work" - simply to set "security=domain"
 and then specify "password server = localhost" might get away with it.


> |>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?
> Yes, if you mean s/rich/tridge/ and s/udp/RPC transport/ :-)

 ah, there was a question from rich salz asking if samba 4 had got the
 udp forwarding trick right :)

 l.