|Main Archive Page > Month Archives > gentoo-hardened archives|
I noticed that the changes to samba's winbind rules are in the latest base policy but it's still not quite right. I think I can finally explain how it's supposed to work based on samba's behavior, but I'm not sure how this should be translated into rules.
The winbind daemon actually opens two separate sockets (both called "pipe" for some reason, but that's another issue). By default they go into:
The first socket is intended to be the "unprivileged" communication point between winbind and a client program; this pipe only allows a limited number of operations to be done. The second socket allows full access, including uid/gid mapping management. Under standard UNIX permissions, the first pipe is world-visible while the second pipe is only accessible by root.
The updated refpolicy template grants access to one or the other of these sockets, depending on distro: the RedHat path adds a rule for the privileged socket, the other path adds a rule for the unprivileged socket.
For RedHat this works -- they've moved the unprivileged socket out of
/tmp into /var/run, so both sockets have the same security context. For
other distros, I think access to *both* types need to be granted. I suppose ideally you'd have two separate templates -- a priv. and an unpriv. one, but I have no idea which programs need which.
I've run with the attached patch to samba.if for a few days now and it seems to have gotten rid of all the winbind-related AVC's I was getting under the new policy (which itself got rid of the AVC's I was getting under the old policy :) )