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.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
