avc { module_request, relabelfrom }: openvpn->tun

[Mr Dash Four]

Stephen Smalley wrote:
> On Sat, 2010-08-14 at 20:12 +0200, Dominick Grift wrote:
>   
>> On 08/14/2010 07:00 PM, Mr Dash Four wrote:
>>     
>>> When I try to execute 'openvpn --mktun --dev tun0 --user nobody --group 
>>> nobody' it works OK, but when I try to start openvpn it again fails with 
>>> the following avc:
>>>
>>> ----audit.log---------------
>>> type=AVC msg=audit(1281803362.451:23): avc:  denied  { relabelfrom } 
>>> for  pid=2007 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
>>> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
>>> tclass=tun_socket
>>>       
>> This looks nasty. See if you can reproduce it with v3.8.8-14 or with the
>> rule mentioned above loaded.
>>
>> Make sure you configure/operate openvpn it properly. Because i do not
>> see why openvpn_t would need to relabel unconfined_t's tun_sockets.
>>     
>
> See:
> http://marc.info/?l=selinux&m=125149773203150&w=2
> http://marc.info/?l=selinux&m=125149774103164&w=2
>
> Attaching to an existing TUN device is modeled as a relabel operation.
> This was discussed extensively earlier on selinux list prior to these patches.
>   
After having to modify my openvpn config file/startup scripts (now 
having to use --mktun prior to starting openvpn) I have this avc:

type=AVC msg=audit(1283605137.660:19): avc:  denied  { relabelfrom } 
for  pid=1612 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=tun_socket
type=SYSCALL msg=audit(1283605137.660:19): arch=40000003 syscall=54 
success=no exit=-13 a0=5 a1=400454ca a2=bfe9e87c a3=926c804 items=0 
ppid=1 pid=1612 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
fsgid=0 tty=(none) ses=1 comm="openvpn" exe="/usr/sbin/openvpn" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

The policy in use is -47 (modified, though the openvpn component is, 
largely, intact). Please also note that the domain is no longer 
unconfined_t, but openvpn_t (one significant difference between this avc 
and the one I posted at the beginning of this thread!).

How do I fix this?

Another thing worth mentioning:- I did not have this problem when 
openvpn was trying to open and set the tun device 'automatically' (i.e. 
within the openvpn executable). However, as I now, for various reasons, 
have to open the tun device prior to openvpn start (and close it after 
openvpn shutdown), I cannot go back to the 'old' way and need to find a 
solution to fix this and avoid the above avc.