Samba under Coherant and Macintosh

[Luke Kenneth Casson Leighton]

On Fri, 17 Dec 1999, Andrew Tridgell wrote:

> I've moved this discussion to samba-techinical (we were making the
> mistake again of having technical discussions on the private team
> list)
> 
> for those who don't know Luke and I are in a long debate on a proposed
> architecture change to Samba where things get far more split up into
> separate daemons etc. Its a friendly but "robust" discussion :)

this is why i've been a bit sharp in my emails recently: it's wearing me
out!  sorry folks.
 
> 
> > > I think you misunderstand me. I propose that the rpc daemon run as
> > > root all the time. I don't see any reason for it running as any other
> > > user. The only possible exception is the spoolss stuff, which needs to
> > > be able to run as a user in order to run lp* commands. 
> > 
> > i don't mis-understand you, i don't want to do it.
> >  
> > > we gain nothing but complexity by running the msrpcd as non-root.
> > 
> > we gain nothing but insecurity and the need to run unnecessary security
> > checks by running as root.  like i think i mentioned earlier, i don't
> > expect smbd to run as root-only, and exactly the same reasons apply to not
> > have msrpc services run as root-only.
> 
> nope. The same reasons do _not_ apply.
> 
> smbd runs as non-root because it needs to do file access. File access
> should be controlled by the OS, not by daemons as otherwise you end up
> replicating the OS access control code in the daemon (and end up with
> horrible race conditions).

i solved this by having smbd do the access control once
(stored in vuser_struct). this information is passed _down_ the unix
socket to the msrpc daemon, and become_user() called with the
uid/gid/ngroups/gid_t* username, BOOL guest, requested_name etc.
 
> As I've mentioned several times, the msrpcd does not need to do user
> file access. With the exception of spoolssd it only ever accesses
> internal data structures. Internal data structures are NOT protected
> by your euid/uid. So jumping through the hoops of running as non-root
> just gives you a false sense of security - it gains you no real
> security.
> 
> > example.  svcctld i've just added a "start / stop service": it uses smbrun
> > and the security context of the svcctld daemon.  you want anonymous users
> > to be able to start and stop root daemons?
> 
> smbd should _never_ be starting/stopping daemons via rpc calls. I know
> you have had plans in the past to do this and even ideas of making
> everything in /etc/rc.d/init.d/ available as rpc services - I think
> the whole idea is totally gross (as I said at the time). It is
> features for features sake. Have you actually ever had a Unix admin
> say to you "gee, I wish I could start/stop sendmail on unix via my NT
> workstations domain management GUI" ?

[if there are any such people, speak now or forever hold your peace].

i certainly want to be able to start / stop msrpc services at the very
least, because i will get smbd to fire up the necessary services on
start-up, depending on the configuration of the box.

> even if such a feature were ever added (and it would be over my dead
> body!) then it would only make sense to start/stop those daemons as
> root!

yes, which means checking the security context of the user which means
ensuring that smbrun is only called with the root uid/gid.

> if you have ideas of allowing users to start/stop their own daemons
> via msrpc then that is just totally crazy!

why?  there's nothing to stop us providing such functionality.

> > > the agents require two way comms to do their job. The packet-storage
> > > idea requires one-way comms. That is the basic difference.
> > > 
> > > it also means that nmblookup (which runs unprivileged as a user)
> > > cannot in any way break nmbd when receiving those broken to-137-only
> > > replies, whereas with an agent it could impact on nmbd.
> > 
> > in what way?  what makes you think so?  agent-clients connect with a
> > nmb-transaction-id.  we strip that out and replace it with our own
> > (incrementing, unique) trn-id, recording the old nmb-trn-id.  when packets
> > are received with our replaced-trn-id, we use that to match it with the
> > agent-client, replace the old trn-id in the response and send it back up
> > the pipe to the client.
> 
> heck Luke, just read through the above:
> 
> 1) "agent-clients connect with a nmb-transaction-id"
> 
> so we now have nmblookup connecting via a special protocol to
> nmb-agent.

let's have a look at the source code.

god, it's so simple it's unbelievable.  the "special protocol" is... there
isn't one.  there actually isn't one.

struct packet_struct itself contains the target ip address.  on receipt of
the packet, i decode the packet (p = receive_packet()), then modify p->fd
to the destination file descriptor (port 137), modify the port number to
port 137, modify theip to the dest ip, then call send_packet(p).

it's 60 lines of code, andrew.

> That opens up the possibility of something going wrong. It
> is a protocol and interaction between unprivileged and privileged code
> were none was before and none is needed. nmb-agent will need paranoid
> code to check for invalid requests, overflows, go-slow-attacks etc
> where right now we have _nothing_. 

think.  that's all either unnecessary or already handled by
receive_packet().

if we need those kinds of things then they should be built in to nmbd
already, and i use exactly the same function that nmbd uses
(receive_packet() and send_packet() so it's a non-issue as it's the same
issue, if that makes any sense.

> with a storage area that is written only by nmbd and only read by
> everyone else we absolutely guarantee that nmbd is never adversely
> affected by any of these other programs. _absolutely
> guaranteed_. Understand?? 
> 
> As soon as you have two way comms you don't have that guarantee. Don't
> give up absolute guarantees when you don't have to - they are rare
> enough already.

this assumes that there is something special / different about nmb-agent
that does not apply to nmbd.  this not being the case, you have the same
guarantees about nmb-agent as you do currently about nmbd, therefore
again, i understand, but it's it's a non-issue because it's the same issue
for both nmb-agent and nmbd.

you're looking for reasons not to support nmb-agent, and those same
reasons apply to nmbd [invalid requests, overflows, go-slow-attacks],
therefore they don't apply.
  
> > ah.  i got a reason.  let's say some administrators or some managers don't
> > trust a third party service.  if it's dlopene'd or part of smbd, they're
> > highly unlikely to let it disrupt "critical services".  if it's a separate
> > program, they might consider it.
> 
> then they are foolish and need educating. The two are equivalent
> security wise

security = sum(users) from 0 to infinity.  as users tends towards idiots,
security tends to zero.

> (think about how symbols are bound when you do a dlopen
> and compare that with what happens with a separate protocol and a
> daemon - they are equivalent!).

hum, don't know enough about .sos.
 
> for those who don't know,

me!  me! :)

> when you dlopen() a .so the parent does NOT

> the only extra thing you can do with a dameon is run it as a different
> uid. I can't see any reason why you would do that (particularly as it
> is more likely to lower your security than raise it - think about what
> you have to allow binding-wise to do it!).

andrew, you just don't get it.

do you really, really want an anomymous user to run an msprc service as
root?  the answer, is a most definite, absolute no way.

i just can't bring myself to not put in become_user() calls.  i really
can't.

why is it that you think that msrpc services don't need to do file access?
what about access to private/smbpasswd from samrd?  do you want anonymous
users to be able to read the SAM database, just like NT allows?

why do you want to impose taking out become_user() calls because you don't
like the idea of administrators deciding whether to put services =
lsarpcd, samrd, svcctld etc in an smb.conf option or not?

i'm into expanding the possibilities, and at the moment it looks like
you're into closing them all because they sound, to you, really crazy.

luke