On Thu, 2010-03-25 at 14:11 -0400, Daniel J Walsh wrote:
> On 03/25/2010 02:06 PM, Stephen Smalley wrote:
> > On Thu, 2010-03-25 at 12:49 -0400, Paul Moore wrote:
> >
> >> On Thursday 25 March 2010 10:02:48 am Stephen Smalley wrote:
> >>
> >>> On Wed, 2010-03-24 at 22:42 -0400, Eric Paris wrote:
> >>>
> >>>> On Tue, 2010-03-23 at 11:44 +0000, Daniel P. Berrange wrote:
> >>>>
> >>>>> On Tue, Mar 23, 2010 at 07:35:13AM -0400, Daniel J Walsh wrote:
> >>>>>
> >>>>>> On 03/22/2010 07:47 PM, Eric Paris wrote:
> >>>>>>
> >>>>>>> On Mon, 2010-03-22 at 17:44 -0400, Daniel J Walsh wrote:
> >>>>>>>
> >>>>>>>> type=AVC msg=audit(1269293509.223:4753): avc: denied { write }
> >>>>>>>> for pid=28549 comm="qemu-kvm" path="socket:[4417531]" dev=sockfs
> >>>>>>>> ino=4417531 scontext=system_u:system_r:svirt_t:s0:c1
> >>>>>>>> tcontext=system_u:system_r:svirt_t:s0-s15:c0.c1023
> >>>>>>>> tclass=unix_stream_socket
> >>>>>>>>
> >>>>>>>> I have Static Virtualization working on an MLS box except for this
> >>>>>>>> strange AVC.
> >>>>>>>>
> >> ...
> >>
> >>
> >>>>>>>> # ps -eZ | grep virt
> >>>>>>>> system_u:system_r:virtd_t:s0-s15:c0.c1023 27344 ? 05:34:47 libvirtd
> >>>>>>>> system_u:system_r:svirt_t:s0:c1 28549 ? 00:00:01 qemu-kvm
> >>>>>>>>
> >> ...
> >>
> >>
> >>>>>>>> # ls -lZ /proc/28549/fd/ | grep 4417531
> >>>>>>>> lrwx------. qemu qemu system_u:system_r:svirt_t:s0:c1 17 ->
> >>>>>>>> socket:[4417531]
> >>>>>>>>
> >>>>>>>> lsof | grep 4417531
> >>>>>>>>
> >>>>>>>> qemu-kvm 28549 qemu 17u unix 0xffff88003e1f7900
> >>>>>>>> 0t0 4417531 /var/lib/libvirt/qemu/xguest.monitor
> >>>>>>>>
> >>>>>>>> # lsof /var/lib/libvirt/qemu/xguest.monitor
> >>>>>>>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE
> >>>>>>>> NAME qemu-kvm 28549 qemu 3u unix 0xffff88003a853000 0t0
> >>>>>>>> 4417518 /var/lib/libvirt/qemu/xguest.monitor
> >>>>>>>> qemu-kvm 28549 qemu 17u unix 0xffff88003e1f7900 0t0 4417531
> >>>>>>>> /var/lib/libvirt/qemu/xguest.monitor
> >>>>>>>>
> >>>>>>>> So it looks like we have a process that is running as both labels?
> >>>>>>>>
> >>>>>>> This is a check between the type of the process and that of the
> >>>>>>> socket itself, not between 2 processes. So, the type of the socket
> >>>>>>> is wrong. Just as a question, what does ls -lZ
> >>>>>>> /var/lib/libvirt/qemu/ show? c0-c1023 for xguest.monitor? What
> >>>>>>> created that socket? Did they get it correct? (I admit it looks
> >>>>>>> correct on my F13ish system)
> >>>>>>>
> >>>>>> The socket file is labeled svirt_var_run_t and has the correct level.
> >>>>>>
> >>>>>> I believe the socket file was created by qemu. Dan can you confirm
> >>>>>> this.
> >>>>>>
> >>>>> Yes, these sockets are created by QEMU when it starts. libvirt just
> >>>>> gives it the path at which to create the socket.
> >>>>>
> >>>>>
> >>>>>> # ls -lZa /var/lib/libvirt/qemu/
> >>>>>>
> >>>>>> drwx------. qemu qemu
> >>>>>> system_u:object_r:svirt_var_run_t:s0-s15:c0.c1023 . drwxr-xr-x. root
> >>>>>> root system_u:object_r:virt_var_lib_t:s0 .. srwxr-xr-x. qemu qemu
> >>>>>> system_u:object_r:svirt_var_run_t:s0:c1 xguest.monitor
> >>>>>>
> >>>> And then libvirt attaches to the other end?
> >>>>
> >>>> In any case, doing some digging the problem (where we first end up with
> >>>> this crazy context with the type of svirt_t but the MLS label of
> >>>> libvirt) is in selinux_socket_unix_stream_connect(). We never saw this
> >>>> in MCS because we don't have constraints on unix domain sockets in
> >>>> targetted/MCS policy. At this hour of the night my brain isn't running
> >>>> well enough nor is my networking foo strong enough to understand exactly
> >>>> which object is supposed to be labeled what where, but it has to be
> >>>> something with the call to security_sid_mls_copy().
> >>>>
> >>>> I'll certainly be looking at this again in the morning.
> >>>>
> >>> That's intentional behavior for MLS.
> >>>
> >> Stephen is correct, the general idea is that when a connected child socket is
> >> created on a socket accepting incoming connections it is labeled using the
> >> type of the listening socket and the MLS attributes of the remote peer. As an
> >> example, imagine client client_t:s0:c1 connecting to server server_t:s0-
> >> s15:c0.c1023, the client's connected socket would be labeled client_t:s0:c1
> >> (it inherits the label from the client process) while the server's connected
> >> child socket would be labeled server_t:s0:c1 (labeled as described above).
> >>
> >> Now, while the code (looking at Linus' current tree, but this hasn't changed
> >> in a while) it does handle labeling UNIX sockets correctly but there are a few
> >> things which strike me as odd, if not wrong:
> >>
> >> 1. The "peer_sid" field of the client's socket is set to the label of the
> >> server's listening socket, NOT the derived label used for the server's child
> >> socket. This means that the MLS attributes of the "peer_sid" stored in the
> >> client's socket do not match the MLS attributes of the server's child socket.
> >> This isn't consistent with how we handle INET sockets, but then again with
> >> UNIX sockets we know the labels of both the remote socket and the remote peer;
> >> with INET sockets we only get one label. In some ways this gets back to the
> >> socket as an endpoint argument and I'm not sure we want to dig that up.
> >>
> > That should likely be changed.
> >
> >
> >> 2. We don't currently update the server's child socket inode label to reflect
> >> the derived label used in the socket. A potential difference between INET and
> >> UNIX socket handling if security_sock_graft() is not called at some point in
> >> the connect process (need to track this down, but it didn't jump out at me in
> >> unix_stream_connect()).
> >>
> > unix_accept() calls sock_graft, so I think that is already covered.
> >
> >
> >> 3. Somewhat unrelated I think, but selinux_socket_unix_may_send() doesn't use
> >> the socket/sock labels, it relies on the inode labels. As has been mentioned
> >> several times in the past, we need to unify the inode/sock labels better.
> >>
> >> There may be more issues, but these are the ones that caught my eye when
> >> scanning the UNIX socket code quickly. Item #1 is probably only an annoyance
> >> that you would see in getpeercon() but we should still probably fix. Item's
> >> #2 and #3 are potentially a bit more serious as the file descriptor access
> >> controls are going to use the inode's label so a mis-match between the socket
> >> and inode labels could cause some rather strange behavior. I can go through
> >> and cleanup this code (it is long overdue), but I want to get some consensus
> >> first on how we want UNIX sockets to behave.
> >>
> >>
>
> Eric, explained what is going on here is actually
> virtd_t:s0-s15:c0.c1023 is trying to write to svirt_t:s0:c1.
>
> So I need to add mls_net_write_within_range(virtd_t), correct?
I admit to being at least as network ignorant as the next guy, but I'm
totally not understanding why the type of the socket makes sense. We
have two ends of this unix domain socket:
svirt_t:c0:c1 and libvirtd_t:s0-s15:c0-c1023
The label on the socket, and thus the label that both ends are going to
have to check against is actually some amalgamation of the context on
both ends. In fact the socket gets the type of svirt_t and the level of
s0-s15:c0-c1023, svirt_t:c0-s15:c0-c1023. Now we need to allow both:
svirt_t:s0:c1 -> svirt_t:s0-s15:c0-c1023
libvirtd_t:s0-s15:c0-c1023 -> sivrt_t:s0-s15:c0-c1023
to use this screwy label that I don't understand at all. I guess I just
don't like the fact that somehow the MLS portion is a magic different
class citizen. It seems to me that the 'correct' checks on a unix
domain socket (where we really know this info) would be different
depending on the direction. We should need to allow
svirt_t:s0:c1 -> libvirtd_t:s0-s15:c0-c1023
libvirtd_t:s0-s15:c0-c1023 -> svirt_t:s0:c1
No more of this horrific magic derived other context. Obviously I'm
networking clueless, but someone please explain me how this type makes
sense.....
-Eric
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
