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.