Luke Kenneth Casson Leighton lkcl at
Thu Dec 16 18:35:30 GMT 1999

> the two are quite different because smbd is long lived and msrpc
> requests are short-lived. They last for a few ms each. Also, msrpc
> requests are just requests that return meta-information, not data. As
> soon as we have msrpc requests that open real user files then we would
> have to reconsider.

not quite.

remember, msrpc function calls are not just "give me information".  the
full set of APIs include almost as many "Set" calls as there are "Get".


the list goes on, and the total number of msrpc calls runs to a few
hundred, and the total number of info levels to a few thousand.

yes, i want some decent coverage of those services.

this isn't just a "file sharing" project any more, this is more like an
operating system.

> >   are you going to recommend that smbd no longer fork a separate process
> > because it's now, after having been running like that since its inception,
> > suddenly higely more complex?
> arrgh, the reasons that apply to smbd do not apply to msrpc. I'm
> getting sick of going over those reasons, if you still don't
> understand then talk to me on the phone tomorrow (my apologies for
> being unavailable today).
> > have you examined nmb-agent and smb-agent?  these run as a single process,
> > and they maintain a dynamic array of sockets.  lib/vagent.c is 242 lines
> > of code, and utils/nmb-agent is 295 lines of code.
> thats 295 lines of _unnecessary_ code. It is also 295 lines of
> insecure, buggy code. I have found 4 security holes in about 2 minutes
> of looking at nmb-agent.  I don't even want to think about what
> horrors might lurk in smb-agent.
> examples in nmb-agent:
> - it binds to not

1) it binds to because nmb-agent sends UDP 137 packets on behalf
of the nmb-agent-clients.

2) this is a first implementation.  second implementation will bind to
individual "interfaces", just like nmbd does, maintaining a socket array
of interface-137 ports.

> - it doesn't check for return code of mkdir() when creating the pipe,
>   then does a chmod to 0777 so you can gain read access to the
>   /etc/shadow file by doing:
>    ln -s /etc/shadow /tmp/.nmb before it starts
> - there is a race in the use of remove()/chmod() in create_pipe_socket() which
>   allows read access by anyone to any file on the system (eg /etc/shadow)

can you or someone else fix some of these for me as i don't have the kinds
of experience to deal with this stuff.  plus, it's a critical area that
i'm using in all of the unix socket code, so i kind of need it!!!!

> - you can DOS it by sending partial packets

..therefore you can DOS nmbd by sending it partial packets, so we should
fix receive_packet() and send_packet() to be more robust.

> etc etc etc. I've only read a tiny portion of it so far.
> Please Luke, trust me a little - this whole idea is BAD. Making it
> properly secure will be REALLY hard and it is a totally unnecessary
> bit of code. It has no redeeming features. 

> > farming out the entire SMB / MSRPC data to a separate msrpc daemon will
> > require the creation of some sort of API that can handle the following
> > commands:
> > 
> > - initiate MSRPC service
> > 
> > - send PDU
> > 
> > - recveive PDU
> > 
> > - terminate MSRPC service.
> nope, the first and last of those won't be smbds job. smbd should hand
> over all rpc requests without even looking inside them.

you still need to pass the pipe name over, which is what i mean by
"initiate MSRPC service".

you still need to indicate that an SMBclose has occurred.
> > - fd = open("/tmp/.msrpc/lsarpcd")
> as an exercise, why don't you try to make create_pipe_socket(), which
> is at the heart of that, truly secure while being accessible from smbd
> when smbd is running as a non-root user. Yes, its possible, but you
> have way underestimated how hard it is.

i don't have the experience to do that.  i'm into msrpc, not unix or nt or
race conditions.

> > andrew, i'd really appreciate it if you could trust my judgement on some
> > of these implementation issues.
> I would if what I'd seen made sense.


i'm relying on you and other people to make sure i don't try anything
stupid :)

> > if i choose to do something, it's usually going to fulfil the current
> > requirements _and_ fulfil some other requirements that i haven't even
> > _thought_ of, yet.
> and make us insecure as all hell and add a pile of completely
> unnecessary baggage to boot. no thanks :)

aaaw, spoil-sport :)

More information about the samba-technical mailing list