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.
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()).
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.
--
paul moore
linux @ hp
--
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.
