tridge at linuxcare.com
Thu Dec 16 13:58:10 GMT 1999
> plus, what's the big deal? if you have to split it at all into one
> daemon, what's the issue with splitting it into several?
separate daemons exposes the internal complexities of msrpc to
users. Those internal complexities should be hidden from users
> andrew, the one thing that really surprises me is that all the reasons
> that apply (security, for-per-req) as to why smbd is architected the way
> it is also apply to msrpc, and you think that they do not apply to msrpc
> i am genuinely mystified.
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.
> 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 0.0.0.0 not 127.0.0.1
- 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)
- you can DOS it by sending partial packets
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
> - 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.
> - 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.
> 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.
> 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 :)
More information about the samba-technical