1 |
I noticed that the changes to samba's winbind rules are in the latest |
2 |
base policy but it's still not quite right. I think I can finally |
3 |
explain how it's supposed to work based on samba's behavior, but I'm not |
4 |
sure how this should be translated into rules. |
5 |
|
6 |
The winbind daemon actually opens two separate sockets (both called |
7 |
"pipe" for some reason, but that's another issue). By default they go into: |
8 |
|
9 |
/tmp/.winbindd/pipe |
10 |
$LOCKDIR/winbindd_privileged/pipe |
11 |
|
12 |
The first socket is intended to be the "unprivileged" communication |
13 |
point between winbind and a client program; this pipe only allows a |
14 |
limited number of operations to be done. The second socket allows full |
15 |
access, including uid/gid mapping management. Under standard UNIX |
16 |
permissions, the first pipe is world-visible while the second pipe is |
17 |
only accessible by root. |
18 |
|
19 |
The updated refpolicy template grants access to one or the other of |
20 |
these sockets, depending on distro: the RedHat path adds a rule for the |
21 |
privileged socket, the other path adds a rule for the unprivileged socket. |
22 |
|
23 |
For RedHat this works -- they've moved the unprivileged socket out of |
24 |
/tmp into /var/run, so both sockets have the same security context. For |
25 |
other distros, I think access to *both* types need to be granted. I |
26 |
suppose ideally you'd have two separate templates -- a priv. and an |
27 |
unpriv. one, but I have no idea which programs need which. |
28 |
|
29 |
I've run with the attached patch to samba.if for a few days now and it |
30 |
seems to have gotten rid of all the winbind-related AVC's I was getting |
31 |
under the new policy (which itself got rid of the AVC's I was getting |
32 |
under the old policy :) ) |
33 |
|
34 |
--Mike |