<div dir="ltr">Hi David,<br><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 3:31 PM David Sommerseth <<a href="mailto:dbus@lists.topphemmelig.net">dbus@lists.topphemmelig.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The raw SELinux denial is:<br>
---------------------------------------------------------------------<br>
type=AVC msg=audit(1541594038.506:688):<br>
avc: denied { read write }<br>
for pid=4880 comm="dbus-daemon"<br>
path="/dev/net/tun" dev="devtmpfs" ino=2711<br>
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023<br>
tcontext=system_u:object_r:tun_tap_device_t:s0<br>
tclass=chr_file<br>
permissive=0<br>
<br>
type=SYSCALL msg=audit(1541594038.506:688): arch=x86_64<br>
syscall=recvmsg success=yes exit=EBADRQC<br>
a0=63 a1=7ffc08dc7630 a2=<a href="tel:400%2000%20000" value="+4740000000" target="_blank">40000000</a> a3=9<br>
items=0 ppid=1 pid=4880<br>
auid=4294967295<br>
uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81<br>
tty=(none) ses=4294967295<br>
comm=dbus-daemon exe=/usr/bin/dbus-daemon<br>
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)<br>
---------------------------------------------------------------------<br> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So this is a _denial_ where SELinux denied the dbus-daemon to do read/write<br>
operations on /dev/net/tun. The source (dbus-daemon) runs under the<br>
system_dbusd_t context (scontext) and it tries to target a chr_file (tclass)<br>
labelled with the tun_ap_device_t context (tcontext). So, this is the default<br>
SELinux targeted policy on RHEL/Fedora.<br></blockquote><div><br></div><div>This is not exactly right (and SELinux is misleading here). The failure is not necessarily due to dbus-daemon doing a read/write on /dev/net/tun, it is due to dbus-daemon doing SOMETHING which requires read/write access to /dev/net/tun (more about what later).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The dbus-daemon tried to do a recvmsg() syscall which returned EBADRQC, which<br>
I believe means "Invalid Request Code". This is anyhow something the kernel<br>
returned, so I presume it is correct behaviour.<br></blockquote><div><br></div><div>This part is highly misleading. I don't know what tool you used to get "exit=EBADRQC", but what the kernel should be sending out is "exit=56". This means that the syscall succeeded, and that it returned 56. That sounds about right, as recvmsg() returns the number of bytes received.<br></div><div> </div><div>The crucial part of this is that it was recvmsg() that triggered the above AVC failure.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as I've understood, the dbus-daemon needs to do the recvmsg()/sendmsg()<br>
dance on the FD to be able to pass the FD from the service to the caller.<br></blockquote><div><br></div><div>Correct, dbus-daemon calls recvmsg() / sendmsg() to receive and forward messages between its clients. The FD in question is then passed along as auxillary data. Apart from doing this forwarding, dbus-daemon does not touch the FD, it is the receiving of the FD itself that fails.<br></div><div><br></div><div>What actually happens is that in order to receive an FD, dbus-daemon needs to have the same SELinux permissions necessary to open the FD in the first place. The FD you are passing is opened RW, and opening something RW requires your SELinux context to be permitted to actually read and write to it, even if it never does. That is the failure you are seeing. That said, the effect of the failure is not to fail the recvmsg() call, the payload is returned just as normal. However, the array of FDs passed as auxillary data is truncated at the first FD that is not permitted to be transmitted, in effect it is silently dropped (from the point of view of dbus-daemon, obviously there is still the log message).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So to my questions:<br>
<br>
- When this error occurs (dbus-daemon being denied the recvmsg() call), the<br>
netcfg service hits the GBusNameLostCallback function and the service is<br>
being shutdown. Why does this happen? Is this expected?<br></blockquote><div><br></div><div>Even though the recvmsg() call succeeds, the resulting DBus message contains fewer FDs than exepected, which is a protocol violation. The client is therefore disconnected. So yes, this is expected.</div><div><br></div><div>To summarise, you need your SELinux policy to give the dbus-daemon the right access to any FDs you pass through it. If I remember correctly, I think I have seen some patches to do this for other services in the upstream policy.</div><div><br></div><div>Hope that helps,</div><div><br></div><div>Tom</div></div></div></div>