tor: dac_override, dac_read_search, name_bind and net_bind_service

[Mr Dash Four]

What is the purpose of dac_override and dac_read_search capabilities? 
 From what I can gather they allow unrestricted access to the file 
system (not sure how secure would that be?).

I am getting 2 avc's when trying to start tor (see logs below). SELinux 
is in enforced mode (switched it to permissive in order to get all the 
alerts listed below). I looked at the source policy 
(policy/modules/services/tor.te) and indeed these 2 capabilities are not 
there (only setgid, setuid and sys_tty_config are allowed from what I 
can see). How healthy would it be if I add these two capabilities to tor.te?

===========================
type=AVC msg=audit(1278095042.156:12): avc:  denied  { dac_override } 
for  pid=1620 comm="tor" capability=1  
scontext=unconfined_u:system_r:tor_t:s0 
tcontext=unconfined_u:system_r:tor_t:s0 tclass=capability
type=AVC msg=audit(1278095042.156:12): avc:  denied  { dac_read_search } 
for  pid=1620 comm="tor" capability=2  
scontext=unconfined_u:system_r:tor_t:s0 
tcontext=unconfined_u:system_r:tor_t:s0 tclass=capability
===========================

I am also getting two other avc's when tor is trying to bind to port 
udp/53 (dns_port_t) and tcp/53. I need this to use tor as my dns 
resolution service on the local machine tor is running. I can probably 
prevent the first avc with including "allow tor_t dns_port_t:tcp_socket 
name_bind;" in tor.te, but how do I prevent the second one?

===========================
type=AVC msg=audit(1278095145.861:14): avc:  denied  { dac_override } 
for  pid=1634 comm="tor" capability=1  
scontext=unconfined_u:system_r:tor_t:s0 
tcontext=unconfined_u:system_r:tor_t:s0 tclass=capability
type=SYSCALL msg=audit(1278095145.861:14): arch=40000003 syscall=195 
success=yes exit=0 a0=9e07088 a1=bfad5390 a2=55bff4 a3=0 items=0 
ppid=1633 pid=1634 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=tty1 ses=1 comm="tor" exe="/usr/bin/tor" 
subj=unconfined_u:system_r:tor_t:s0 key=(null)
type=AVC msg=audit(1278095145.958:15): avc:  denied  { name_bind } for  
pid=1636 comm="tor" src=53 scontext=unconfined_u:system_r:tor_t:s0 
tcontext=system_u:object_r:dns_port_t:s0 tclass=udp_socket
type=AVC msg=audit(1278095145.958:15): avc:  denied  { net_bind_service 
} for  pid=1636 comm="tor" capability=10  
scontext=unconfined_u:system_r:tor_t:s0 
tcontext=unconfined_u:system_r:tor_t:s0 tclass=capability
type=SYSCALL msg=audit(1278095145.958:15): arch=40000003 syscall=102 
success=yes exit=0 a0=2 a1=bfad5260 a2=0 a3=9e1cba8 items=0 ppid=1 
pid=1636 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=1 comm="tor" exe="/usr/bin/tor" 
subj=unconfined_u:system_r:tor_t:s0 key=(null)
===========================

I am getting the above set when I place SELinux in Permissive mode 
(setenforce 0). As it is clear from the above, I am NOT getting 
dac_read_search when SELinux is in Permissive mode. I am also not 
getting name_bind and net_bind_service avc when SELinux is in Enforced 
mode as obviously tor does not reach that far and terminates.

Help would be much appreciated!

[Mr Dash Four]

Some progress made:

dac_override and dac_read_search AVCs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These were triggered by wrong file/directory permission settings (too 
restrictive - 600/700 not allowing 'root' access to these as the uid/gid 
were not 'root'). I have corrected these by changing the group ids to 
include root (uid: root, gid: ___tor). When this was done the above 2 
AVCs were gone - forever.
In order to find out what was causing these I had to switch more 
detailed auditd logging with "auditctl -a exit,always -F dir=/apps" and 
"auditctl -a exit,always -F dir=/usr" to see what is happening - very 
handy auditd feature and solved the above issues as it logged every 
syscall made to the above 2 directories (recursively!) enabling me to 
see what went wrong.

name_bind AVC:
~~~~~~~~~~~~
I also know how to correct the name_bind AVC, though the issue I have is 
that this should be a permanent setting in the targeted policy (tor.te) 
as the new version of tor (2.x) has its own dns resolving capabilities 
and needs access/binding to udp/53. The policy makers of the 'targeted' 
policy should be made aware of this.

net_bind_service AVC:
~~~~~~~~~~~~~~~~
Here is my last query: net_bind_service capability (allowing binding to 
ports < 1024) is also needed by tor's dns resolution service, though I 
need to know is there a way to specify only port 53 as that is what is 
needed by tor (tor does NOT need to bind to any other privileged port(s) 
other than udp/53)?

I can get away without the above 2 AVCs provided I specify DNS 
resolution to be done on unprivileged ports (say udp/5053 for example), 
though don't know how is this going to be done in practice as I have no 
idea how to force Linux in accepting its DNS resolution to look for 
ports other than 53 (as far as I know 'resolv.conf' allows only hosts to 
be specified, no ports - 53 is the assumed DNS resolution port adn that, 
as far as I know, cannot be changed).

[David P. Quigley]

On Mon, 2010-07-19 at 20:29 +0100, Mr Dash Four wrote:
>  Some progress made:
>  
>  dac_override and dac_read_search AVCs:
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  These were triggered by wrong file/directory permission settings (too 
>  restrictive - 600/700 not allowing 'root' access to these as the uid/gid 
>  were not 'root'). I have corrected these by changing the group ids to 
>  include root (uid: root, gid: ___tor). When this was done the above 2 
>  AVCs were gone - forever.
>  In order to find out what was causing these I had to switch more 
>  detailed auditd logging with "auditctl -a exit,always -F dir=/apps" and 
>  "auditctl -a exit,always -F dir=/usr" to see what is happening - very 
>  handy auditd feature and solved the above issues as it logged every 
>  syscall made to the above 2 directories (recursively!) enabling me to 
>  see what went wrong.
>  
>  name_bind AVC:
>  ~~~~~~~~~~~~
>  I also know how to correct the name_bind AVC, though the issue I have is 
>  that this should be a permanent setting in the targeted policy (tor.te) 
>  as the new version of tor (2.x) has its own dns resolving capabilities 
>  and needs access/binding to udp/53. The policy makers of the 'targeted' 
>  policy should be made aware of this.
>  
>  net_bind_service AVC:
>  ~~~~~~~~~~~~~~~~
>  Here is my last query: net_bind_service capability (allowing binding to 
>  ports < 1024) is also needed by tor's dns resolution service, though I 
>  need to know is there a way to specify only port 53 as that is what is 
>  needed by tor (tor does NOT need to bind to any other privileged port(s) 
>  other than udp/53)? 
If you just want tor to bind to the dns port use these interfaces

corenet_tcp_bind_dns_port(tor_t)
corenet_udp_bind_dns_port(tor_t)

Considering these interfaces contain the net_bind_service cap it seems
like you will have to include it. However that isn't a concern since the
statement here only will allow tor to bind to ports labeled dns_port_t.
In this case tcp/udp 53. If you don't want tcp just include the second
of the two interfaces only.

>  
>  I can get away without the above 2 AVCs provided I specify DNS 
>  resolution to be done on unprivileged ports (say udp/5053 for example), 
>  though don't know how is this going to be done in practice as I have no 
>  idea how to force Linux in accepting its DNS resolution to look for 
>  ports other than 53 (as far as I know 'resolv.conf' allows only hosts to 
>  be specified, no ports - 53 is the assumed DNS resolution port adn that, 
>  as far as I know, cannot be changed).
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Mr Dash Four]

>  If you just want tor to bind to the dns port use these interfaces
>
>  corenet_tcp_bind_dns_port(tor_t)
>  corenet_udp_bind_dns_port(tor_t)
>
>  Considering these interfaces contain the net_bind_service cap it seems
>  like you will have to include it. However that isn't a concern since the
>  statement here only will allow tor to bind to ports labeled dns_port_t.
>  In this case tcp/udp 53. If you don't want tcp just include the second
>  of the two interfaces only.
>     
It worked - it is exactly what I was after, thank you! I've just 
included the udp bind since tcp/53 is not used by tor.

After I patched tor.te and re-compiled the targeted policy tor started 
without any problems.