svirt on MLS has strange AVC.

svirt on MLS has strange AVC.

[Daniel J Walsh]

time->Mon Mar 22 17:31:49 2010
type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1 
success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1 
pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 
sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm" 
exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 key=(null)
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.

This looks like the kernel is confused?  I believe that all svirt 
processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1 
is trying to write to a unix_stream_socket running as 
svirt_t:s0-s15:c0.c1023.

# 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

Could the kernel be getting confused in to thinking libvirtd is svirt_t?

# 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 message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

On Mon, 2010-03-22 at 17:44 -0400, Daniel J Walsh wrote:
> time->Mon Mar 22 17:31:49 2010
> type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1 
> success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1 
> pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 
> sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm" 
> exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 key=(null)
> 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.
> 
> This looks like the kernel is confused?  I believe that all svirt 
> processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1 
> is trying to write to a unix_stream_socket running as 
> svirt_t:s0-s15:c0.c1023.
> 
> # 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
> 
> Could the kernel be getting confused in to thinking libvirtd is svirt_t?
> 
> # 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)

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

On 03/22/2010 07:47 PM, Eric Paris wrote:
> On Mon, 2010-03-22 at 17:44 -0400, Daniel J Walsh wrote:
>    
>> time->Mon Mar 22 17:31:49 2010
>> type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1
>> success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1
>> pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107
>> sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm"
>> exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 key=(null)
>> 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.
>>
>> This looks like the kernel is confused?  I believe that all svirt
>> processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1
>> is trying to write to a unix_stream_socket running as
>> svirt_t:s0-s15:c0.c1023.
>>
>> # 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
>>
>> Could the kernel be getting confused in to thinking libvirtd is svirt_t?
>>
>> # 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)
>
> -Eric
>
>    
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.


  # 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



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel P. Berrange]

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:
> >   
> >>time->Mon Mar 22 17:31:49 2010
> >>type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1
> >>success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1
> >>pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107
> >>sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm"
> >>exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 
> >>key=(null)
> >>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.
> >>
> >>This looks like the kernel is confused?  I believe that all svirt
> >>processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1
> >>is trying to write to a unix_stream_socket running as
> >>svirt_t:s0-s15:c0.c1023.
> >>
> >># 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
> >>
> >>Could the kernel be getting confused in to thinking libvirtd is svirt_t?
> >>
> >># 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)
> >
> >-Eric
> >
> >   
> 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


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

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:
> > >   
> > >>time->Mon Mar 22 17:31:49 2010
> > >>type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1
> > >>success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1
> > >>pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107
> > >>sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm"
> > >>exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 
> > >>key=(null)
> > >>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.
> > >>
> > >>This looks like the kernel is confused?  I believe that all svirt
> > >>processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1
> > >>is trying to write to a unix_stream_socket running as
> > >>svirt_t:s0-s15:c0.c1023.
> > >>
> > >># 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
> > >>
> > >>Could the kernel be getting confused in to thinking libvirtd is svirt_t?
> > >>
> > >># 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)
> > >
> > >-Eric
> > >
> > >   
> > 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.

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel P. Berrange]

On Wed, Mar 24, 2010 at 10:42:39PM -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:
> > > 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?

Yes, the $GUEST.monitor sockets are the runtime control interface for QEMU,
which libvirt connects to to change live changes.


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

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:
> > > >   
> > > >>time->Mon Mar 22 17:31:49 2010
> > > >>type=SYSCALL msg=audit(1269293509.223:4753): arch=c000003e syscall=1
> > > >>success=no exit=-13 a0=11 a1=1d2a9c8 a2=10 a3=fffffff2 items=0 ppid=1
> > > >>pid=28549 auid=0 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107
> > > >>sgid=107 fsgid=107 tty=(none) ses=7 comm="qemu-kvm"
> > > >>exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c1 
> > > >>key=(null)
> > > >>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.
> > > >>
> > > >>This looks like the kernel is confused?  I believe that all svirt
> > > >>processes are running as s0:c1 and yet this AVC indicates svirt_t:s0.c1
> > > >>is trying to write to a unix_stream_socket running as
> > > >>svirt_t:s0-s15:c0.c1023.
> > > >>
> > > >># 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
> > > >>
> > > >>Could the kernel be getting confused in to thinking libvirtd is svirt_t?
> > > >>
> > > >># 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)
> > > >
> > > >-Eric
> > > >
> > > >   
> > > 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.

commit 4237c75c0a35535d7f9f2bfeeb4b4df1e068a0bf
Author: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Date:   Mon Jul 24 23:32:50 2006 -0700

    [MLSXFRM]: Auto-labeling of child sockets
    
    This automatically labels the TCP, Unix stream, and dccp child sockets
    as well as openreqs to be at the same MLS level as the peer. This will
    result in the selection of appropriately labeled IPSec Security
    Associations.
    
    This also uses the sock's sid (as opposed to the isec sid) in SELinux
    enforcement of secmark in rcv_skb and postroute_last hooks.
    
    Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>


-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

On 03/25/2010 12:49 PM, 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.
>
> 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.
>
>    
Ok, my head is going to explode.

A process labeled svirt_t:s0:c1 creates a unix_stream_socket labeled in 
a sock_file labeled svirt_image_t:s0:c1 and then attempts to connect to  
it.  And on one end of it is a process labeled svirt_t:s0:c1 and the 
other is svirt_t:s0-s15:c0.c1023.  This process does not exist, looking 
at the connection, both ends are the same process.  THIS IS A BUG.  
something is wrong here.

Both ends of the socket should be svirt_t:s0:c1.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

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.
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

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?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

On Thu, 2010-03-25 at 14:00 -0400, Daniel J Walsh wrote:
> On 03/25/2010 12:49 PM, 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.
> >
> > 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.
> >
> >    
> Ok, my head is going to explode.
> 
> A process labeled svirt_t:s0:c1 creates a unix_stream_socket labeled in 
> a sock_file labeled svirt_image_t:s0:c1 and then attempts to connect to  
> it.  And on one end of it is a process labeled svirt_t:s0:c1 and the 
> other is svirt_t:s0-s15:c0.c1023.  This process does not exist, looking 
> at the connection, both ends are the same process.  THIS IS A BUG.  
> something is wrong here.
> 
> Both ends of the socket should be svirt_t:s0:c1.

IIUC, the svirt_t process created a listening socket, which would have
been labeled with the process' label.  But when a connection is received
on that listening socket, a new connection/server socket is created and
"accept"ed by the svirt_t process, and that new connection/server socket
gets the TE type of the listening socket ("svirt_t") but the MLS
level/range of the peer.

It seems to me that it really should only get the low/current level of
the peer, not the full range, e.g. mls_context_cpy_low(), so that we
don't turn a connection from a ranged subject into a fully ranged
socket?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

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?

The denial was from svirt_t, I believe, and was between the svirt_t
process and the new connection/server socket.  So you'd have to make
svirt_t able to write to sockets outside of its range, which doesn't
seem desirable.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

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:s0to 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 class types.  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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

On Thu, 2010-03-25 at 14:23 -0400, Eric Paris wrote:
> 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.....

You should get the desired permission checks between the client socket
and the listening socket (which will reflect client and server
contexts).

But the behavior for the new connection/server socket was changed for
MLS during the LSPP work to reflect the level of the client.  This makes
sense when you have a single-level client connecting to a ranged server
- the connection is then established at the requesting level and the
traffic is labeled and protected accordingly.

It doesn't make sense to me when you have a ranged client.
 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

On Thu, 2010-03-25 at 14:34 -0400, Stephen Smalley wrote:

> But the behavior for the new connection/server socket was changed for
> MLS during the LSPP work to reflect the level of the client.  This makes
> sense when you have a single-level client connecting to a ranged server
> - the connection is then established at the requesting level and the
> traffic is labeled and protected accordingly.

I still don't understand why MLS is some 'other' class citizen of the
context.  If it makes sense to reflect the level it should make sense to
reflect the type, and role, and user, if they are available.  Doesn't
it?  I know that some labeling magic (CIPSO) don't deal with anything
but the level and thus the only thing we can/should do is play with the
level, but when we have the info (unix domain sockets and I think some
IPSec labeling right), why do we discard that additional info that makes
these things 'make sense'?

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

On Thu, 2010-03-25 at 14:17 -0400, Stephen Smalley wrote:

> It seems to me that it really should only get the low/current level of
> the peer, not the full range, e.g. mls_context_cpy_low(), so that we
> don't turn a connection from a ranged subject into a fully ranged
> socket?

Is that even the best, by itself?  We would still be in the same
situation except now we would have a random virtual machine

svirt_t:s3:c156

trying to read/write to a socket with the label:

svirt_t:s0:c0

since libvirtd_t is going to pretty much always be running:

libvirtd_t:s0-s15:c0-1023

If we have to go that way, do we have some sort of crazy,
copy_mls_level_subset() or other such foolishness?   *smile*

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Thursday 25 March 2010 02:45:13 pm Eric Paris wrote:
> On Thu, 2010-03-25 at 14:34 -0400, Stephen Smalley wrote:
> > But the behavior for the new connection/server socket was changed for
> > MLS during the LSPP work to reflect the level of the client.  This makes
> > sense when you have a single-level client connecting to a ranged server
> > - the connection is then established at the requesting level and the
> > traffic is labeled and protected accordingly.
> 
> I still don't understand why MLS is some 'other' class citizen of the
> context.  If it makes sense to reflect the level it should make sense to
> reflect the type, and role, and user, if they are available.  Doesn't it?

Yes, to some extent anyway.  For connectionless, uni-directional sockets, e.g. 
UDP, the socket's label is pretty easy to understand: you label it based on 
the task that created it and you're done, nobody argues this and it just plain 
makes sense.  The problem are those connection oriented bi-directional sockets 
that we all love because it brings us our beloved flash videos, yes, I'm 
talking about TCP.

Connection oriented sockets are a pain pretty much any way you look at it, 
although the client side is at least more straightforward so we'll look at 
that first.  The first thing a client does when it wants to establish a 
network connection is create a socket via the socket() syscall; at this point 
the only information we have is the task's label so we have no choice but to 
label the client's socket using the client's label.  The next step is to 
"connect" the client's socket to the server using the connect() syscall, and 
this is where the fun happens.  The connect() syscall kicks off the connection 
handshake, which if successful, results in a new socket (known often as the 
"child" socket) on the server which is connected, via the magic of networking, 
to the client's socket ... now, what do we label these two sockets?  Well, we 
already have a label assigned to the client's socket and we don't want to 
change that so we'll leave that alone, but what about the newly created child 
socket on the server?  This is the tricky bit, we have the following options 
[I may be missing one or two possibilities, but the four below are the only 
options that seem like reasonable choices to me]:

1. Label it based on the server's label
2. Label it based on the client's label
3. Label it based on some fixed combination of the client and server labels
4. Label it based on a type transition rule

Option #1 is nice and consistent with how we label all other sockets, but it 
presents an interesting problem: in SELinux we treat sockets, not processes, 
as communication endpoints (client applications read/write to client sockets 
who read/write to server sockets which are read/written to by server 
applications) and we want to be able to distinguish between connections 
labeled FOO and BAR at the application level, how do we do that if all of the 
server child sockets are labeled using only the application's label?  The 
answer: you can't, or rather I haven't heard of a sane way.  If we want to be 
able to write policy that allows us to control the network traffic entering or 
leaving an application we have to do it by varying the label of network socket 
being used for communication.

Option #2 creates the server's child socket with a label matching the client's 
traffic; this solves the policy problem we saw with option #1 but it 
introduces a new problem we didn't have before.  As mentioned earlier, in 
SELinux it is the sockets, not the applications that communicate across the 
network and they are the subjects/objects used in the per-packet access 
controls; if we label the server's child socket to match the client's label we 
run afoul of the client's network access controls.  The problem is all of the 
network traffic coming from the server is coming from a socket labeled the 
same as the client's own socket; from a policy point of view this shifts the 
problem we saw with option #1 from the server to the client: you can't write 
policy on the client to enforce network access controls on incoming traffic as 
all incoming traffic from the server is labeled the same - the client's own 
label.

Option #3 is what we have today; created by developers with a MLS-centric view 
at a point in time when nobody really cared about any of the network access 
controls and the overriding theme to the development efforts was, "go make 
your changes but make sure you tread lightly and no matter what make sure we 
can turn it off, because that is what we are going to do in all our 
installations."  Okay, that might be harsh criticism for both sides, but I 
think you kinda get the idea and most of you who have read this far were 
likely around then anyway.  Regardless, back to option #3, a derived label 
based on both the client and server labels; the basic idea is that you need to 
be able to vary the label on the server's child socket so that it represents 
both the client's label (so you can write effective server side policy) as 
well as the server's label (so you can write effective client side policy) 
without causing everything to come crashing down.  The solution that we 
settled upon was using the TE attributes (user, role and type) from the 
server's label and the MLS attributes (level and categories) from the client.  
I don't think you'll find anyone who claims this is a perfect solution, I know 
I won't, but it has worked for several years without any complaints (it is 
worth noting that the complaints we are seeing this week are not due to 
traditional IP networking, but rather UNIX socket "networking" which appears 
to have some implementation bugs regardless of the design choices).

Option #4 is an interesting idea, very similar to option #3 but driven more by 
policy rather then a fixed rule for combining the two labels, client and 
server, to create a new label for the server's child socket.  In option #3 we 
used a fixed rule, server's TE attributes and client's MLS attributes, to 
generate the label for the server's child socket; in option #4 we could use 
policy, via transition rules, to generate the label for the server's child 
socket.  Other than the obvious extra policy work required (the policy work 
required for option #3 is largely contained in the MLS constraints which can 
greatly simplify the policy for the traditional MLS policies) the problem is 
that we do not have a good policy construct to set the MLS attributes of a 
label based on the MLS attributes of the two other labels; the 
range_transition rule allows to set the MLS attributes of a label, but only 
based on the type information of the other labels, not their own MLS 
attributes.  While option #4 is likely the most flexible option discussed 
here, it is also the most involved and I don't currently believe the benefits 
over option #3 make it worth the effort at this point.

> I know that some labeling magic (CIPSO) don't deal with anything
> but the level and thus the only thing we can/should do is play with the
> level, but when we have the info (unix domain sockets and I think some
> IPSec labeling right), why do we discard that additional info that makes
> these things 'make sense'?

Hopefully if you understood the stuff above this is evident, but I want to 
make it this point again just so there is no confusion - CIPSO, or any other 
networking protocol that only conveys MLS attributes, it not the reason why we 
have the derived labels we have today.  Have the client's full label doesn't 
make the problem any easier; you'll note in options #1 and #2 above there is 
no talk of TE or MLS attributes, it simply doesn't matter.

If you need to blame something, blame the SELinux network access control 
architecture or the SELinux policy but also recognize that there isn't a magic 
solution to make everything sane using what we currently have - although if 
you have an idea, I'm all ears.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Thursday 25 March 2010 03:02:10 pm Eric Paris wrote:
> On Thu, 2010-03-25 at 14:17 -0400, Stephen Smalley wrote:
> > It seems to me that it really should only get the low/current level of
> > the peer, not the full range, e.g. mls_context_cpy_low(), so that we
> > don't turn a connection from a ranged subject into a fully ranged
> > socket?

This is an interesting question, and you could ask the same of INET 
connections where you have a ranged client peer label available.  I guess my 
question is considering that the UNIX socket MLS constraints seem to follow 
the rest of the MLS constraint conventions (the low half of the range is used 
as the effective sensitivity label and the high half of the range is used as 
the cleared sensitivity label) what do you loose with the current 
implementation?  I haven't thought about it enough to have an opinion yet ...

> Is that even the best, by itself?  We would still be in the same
> situation except now we would have a random virtual machine
> 
> svirt_t:s3:c156
> 
> trying to read/write to a socket with the label:
> 
> svirt_t:s0:c0
> 
> since libvirtd_t is going to pretty much always be running:
> 
> libvirtd_t:s0-s15:c0-1023

I thought QEMU/KVM was creating the socket and libvirtd was trying to connect 
to it?  If this is the case wouldn't it be a random virtual machine ...

	svirt_t:s3:c156

... and a not-so-random libvirtd ...

	libvirtd_t:s0-s15:c0-c1023

... trying to talk over a UNIX socket which is labeled svirt_t:s0 (on the 
QEMU/KVM side) and libvirtd_t:s0-s15:c0-c1023 (on the libvirtd side)?  I 
agree, that could be a little wierd on the QEMU/KVM side, but if we use the 
full MLS range for the child socket we end up with svirt:s0-s15:c0-c1023 on 
the QEMU/KVM side and libvirtd_t:s0-s15:c0-c1023 on the libvirtd side; you'll 
probably still need some MLS overrides on the QEMU/KVM side but you could at 
least do something using the range.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel P. Berrange]

On Thu, Mar 25, 2010 at 06:06:13PM -0400, Paul Moore wrote:
> On Thursday 25 March 2010 03:02:10 pm Eric Paris wrote:
> > On Thu, 2010-03-25 at 14:17 -0400, Stephen Smalley wrote:
> > > It seems to me that it really should only get the low/current level of
> > > the peer, not the full range, e.g. mls_context_cpy_low(), so that we
> > > don't turn a connection from a ranged subject into a fully ranged
> > > socket?
> 
> This is an interesting question, and you could ask the same of INET 
> connections where you have a ranged client peer label available.  I guess my 
> question is considering that the UNIX socket MLS constraints seem to follow 
> the rest of the MLS constraint conventions (the low half of the range is used 
> as the effective sensitivity label and the high half of the range is used as 
> the cleared sensitivity label) what do you loose with the current 
> implementation?  I haven't thought about it enough to have an opinion yet ...
> 
> > Is that even the best, by itself?  We would still be in the same
> > situation except now we would have a random virtual machine
> > 
> > svirt_t:s3:c156
> > 
> > trying to read/write to a socket with the label:
> > 
> > svirt_t:s0:c0
> > 
> > since libvirtd_t is going to pretty much always be running:
> > 
> > libvirtd_t:s0-s15:c0-1023
> 
> I thought QEMU/KVM was creating the socket and libvirtd was trying to connect 
> to it?  If this is the case wouldn't it be a random virtual machine ...

That is correct, this is the monitor socket created by QEMU, which
libvirtd then connects to

> 
> 	svirt_t:s3:c156
> 
> ... and a not-so-random libvirtd ...
> 
> 	libvirtd_t:s0-s15:c0-c1023
> 
> ... trying to talk over a UNIX socket which is labeled svirt_t:s0 (on the 
> QEMU/KVM side) and libvirtd_t:s0-s15:c0-c1023 (on the libvirtd side)?  I 
> agree, that could be a little wierd on the QEMU/KVM side, but if we use the 
> full MLS range for the child socket we end up with svirt:s0-s15:c0-c1023 on 
> the QEMU/KVM side and libvirtd_t:s0-s15:c0-c1023 on the libvirtd side; you'll 
> probably still need some MLS overrides on the QEMU/KVM side but you could at 
> least do something using the range.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Friday 26 March 2010 09:42:03 am Eric Paris wrote:
> Thanks Paul for laying things out in a dumbed down enough way for me to
> grasp a couple things  :)   I now understand about 2% of what we are
> trying to accomplish with network checks.  Next time I see you in person
> you better be careful because I could use about 25 more of these lessons
> to understand the fun/difficult/other parts of networking code.

 :)

> On Thu, 2010-03-25 at 17:36 -0400, Paul Moore wrote:
> > Well, we
> > already have a label assigned to the client's socket and we don't want to
> > change that so we'll leave that alone
> 
> Why is this a given?  Seems to me there is a fundamental difference
> between a socket before connect() and a socket after connect().  Much
> the same as the (I think agreed upon) fundamental difference between a
> socket before accept() and the 'child' socket we get after accept().

The key different between the client side socket, created with socket() and 
connected via connect(), and the server side child socket, created with 
accept() is that we don't know the label of the other end when the client 
socket is created whereas we know the label of the other end when the server 
side child socket is created.

We could _relabel_ the client side socket on connect but that could be ugly 
and would likely be frowned upon by the security die-hards.  We would probably 
also want to limit it to stream sockets as you can't really disconnect them, 
although you can disconnect connected datagram sockets.

> My original wish for how things would be labeled does lead to a very,
> ummm, interesting, result.  What I wanted to see and thought was the
> most logical was the following:
> 
> client process: client_t:s0:c1
> server process: server_t:s0-s15:c0-c1023
> 
> both are going to have to create a socket with the socket() call right?
> so we are going to end up with:
> 
> client_sock: client_t:s0:c1
> server_sock: server_t:s0-s15:c0-c1023
> 
> Now we have calls to connect() and accept() respectively, correct?  My
> original thought on how these socks should be labeled was that we should
> now get
> 
> client_sock: server_t:s0-s15:c0-c1023
> server_sock: client_t:s0:c1

A point of clarification: I think you mean "server_child_socket" above, not 
the original listening server socket.

> Which clearly makes the most sense to everyone in how read/write rules
> from the application to the socket should be written and allowed.

Well, in one direction anyway; I think you are assuming a one way data flow 
here.  Think about what happens when the client socket receives data from the 
server socket?  What about when the server socket receives data from the 
client socket?

> Each side would need rules like:
> 
> allow client_t:s0:c1 server_t:s0-s15:c0-c1023:socket { read write }
> allow server_t:s0-s15:c0-c1023 client_t:s0:c1:socket { read write }
> 
> Seems great, but you point out the logical next step which is the rules
> between the sockets themselves which would be reversed (opps, bad news
> for my world of making sense)  These checks are against what?  packet
> and peer?

Okay, you got the point about bi-directional traffic.

Quick and dirty pseudo-policy example (some of the classes/perms may not be 
100%) for app "foo" talking to app "bar" over the network (ignores 
ingress/egress and secmark controls):

 # let foo_t act as a basic network client for sockets it creates
 allow foo_t self:socket { create connect read write }

 # let bar_t act as a basic network server for sockets it creates
 allow bar_t self:socket { create listen accept read write }

 # let bar_t receive network traffic from foo_t
 allow bar_t foo_t:peer { recv }

> I guess the solution to this odd reversal of meanings is the old
> question you mentioned before and didn't want to bring up of: is the
> socket the endpoint or is the application the end point?  As I was
> around, but ignorant/ignored those discussions, why did we end up this
> way?

Well, this is the way it was when I got here so I can't say for certain but I 
believe it comes down to the fact that sockets, like any other file 
descriptor, can get passed around from application to application and you want 
to be sure that have the right access controls in place to prevent traffic 
going somewhere it shouldn't if a socket is passed to an app with a different 
label.  By enforcing access controls when data is queued to a socket as well 
as later when it is read from the socket we can ensure data doesn't go 
somewhere it shouldn't.

I think it also makes the implementation on Linux a little easier too :)

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Friday 26 March 2010 10:00:02 am Eric Paris wrote:
> On Thu, 2010-03-25 at 18:06 -0400, Paul Moore wrote:
> > I thought QEMU/KVM was creating the socket and libvirtd was trying to
> > connect to it?  If this is the case wouldn't it be a random virtual
> > machine ...
> > 
> > 	svirt_t:s3:c156
> > 
> > ... and a not-so-random libvirtd ...
> > 
> > 	libvirtd_t:s0-s15:c0-c1023
> > 
> > ... trying to talk over a UNIX socket which is labeled svirt_t:s0 (on the
> > QEMU/KVM side) and libvirtd_t:s0-s15:c0-c1023 (on the libvirtd side)?  I
> > agree, that could be a little wierd on the QEMU/KVM side, but if we use
> > the full MLS range for the child socket we end up with
> > svirt:s0-s15:c0-c1023 on the QEMU/KVM side and
> > libvirtd_t:s0-s15:c0-c1023 on the libvirtd side; you'll probably still
> > need some MLS overrides on the QEMU/KVM side but you could at least do
> > something using the range.
> 
> Yes, that is exactly what is happening.  I find the label
> svirt:s0-s15:c0-c1023 abhorrent, but that's neither here nor there.  MLS
> as an 'other' class citizen in the label makes me .... unhappy.

Me too.  I work hard to deal in "labels" whenever possible, sadly (or 
unhappily) this isn't always possible.

> So today we have:
> 
> QEMU/KVM process: svirt_t:s3:c156
> QEMU/KVM socket:  svirt_t:s0-s15:c0-c1023

Well, if it is working correctly, I think we established that there were some 
bugs ... but honestly at this point I've forgotten, I need to re-read what we 
wrote ...

> sds suggested we only copy the low part of the MLS context to the server
> label, which gives us:
> 
> QEMU/KVM process: svirt_t:s3:c156
> QEMU/KVM socket:  svirt_t:s0:c0
> 
> which I don't think is any better as we still have to needlessly use MLS
> overrides which pretty much destroys the whole usefulness of vm
> isolation here.

Well, either way you are going to need to use some MLS override attributes, 
but one of the nice things about SELinux is you can restrict those overrides 
to specific object classes and permissions, e.g. you can create MLS overrides 
which only target specific UNIX domain socket operations.  It really isn't as 
bleak as it sounds; vm isolation is not lost.

> This is why I suggested an mls_copy_subset function so things could
> 'work' if you have ranged objects on either the client or server side.
> It only 'works' today if the ranged object is on the server side.....

Look at the MLS constraints, yes I know they are scary, but they are quite 
flexible and I believe they will allow you to do what you want.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

[resending as tycho.nsa.gov bounced it the first time.  Paul already
responded so this is just for the archives]

Thanks Paul for laying things out in a dumbed down enough way for me to
grasp a couple things  :)   I now understand about 2% of what we are
trying to accomplish with network checks.  Next time I see you in person
you better be careful because I could use about 25 more of these lessons
to understand the fun/difficult/other parts of networking code. 

On Thu, 2010-03-25 at 17:36 -0400, Paul Moore wrote:
> Well, we 
> already have a label assigned to the client's socket and we don't want to 
> change that so we'll leave that alone

Why is this a given?  Seems to me there is a fundamental difference
between a socket before connect() and a socket after connect().  Much
the same as the (I think agreed upon) fundamental difference between a
socket before accept() and the 'child' socket we get after accept().

My original wish for how things would be labeled does lead to a very,
ummm, interesting, result.  What I wanted to see and thought was the
most logical was the following:

client process: client_t:s0:c1
server process: server_t:s0-s15:c0-c1023

both are going to have to create a socket with the socket() call right?
so we are going to end up with:

client_sock: client_t:s0:c1
server_sock: server_t:s0-s15:c0-c1023

Now we have calls to connect() and accept() respectively, correct?  My
original thought on how these socks should be labeled was that we should
now get

client_sock: server_t:s0-s15:c0-c1023
server_sock: client_t:s0:c1

Which clearly makes the most sense to everyone in how read/write rules
from the application to the socket should be written and allowed.  Each
side would need rules like:

allow client_t:s0:c1 server_t:s0-s15:c0-c1023:socket { read write }
allow server_t:s0-s15:c0-c1023 client_t:s0:c1:socket { read write }

Seems great, but you point out the logical next step which is the rules
between the sockets themselves which would be reversed (opps, bad news
for my world of making sense)  These checks are against what?  packet
and peer?

client writing to server would need rule with source server_t and target
client_t.  server writing to client would need rules with source
client_t and target server_t.  I can only see Dan's/policy writer's
complaints then.

I guess the solution to this odd reversal of meanings is the old
question you mentioned before and didn't want to bring up of: is the
socket the endpoint or is the application the end point?  As I was
around, but ignorant/ignored those discussions, why did we end up this
way?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

[resending as tycho.nsa.gov bounced it the first time.  Paul already
responded so this is just for the archives]

On Thu, 2010-03-25 at 18:06 -0400, Paul Moore wrote:
> I thought QEMU/KVM was creating the socket and libvirtd was trying to connect 
> to it?  If this is the case wouldn't it be a random virtual machine ...
> 
> 	svirt_t:s3:c156
> 
> ... and a not-so-random libvirtd ...
> 
> 	libvirtd_t:s0-s15:c0-c1023
> 
> ... trying to talk over a UNIX socket which is labeled svirt_t:s0 (on the 
> QEMU/KVM side) and libvirtd_t:s0-s15:c0-c1023 (on the libvirtd side)?  I 
> agree, that could be a little wierd on the QEMU/KVM side, but if we use the 
> full MLS range for the child socket we end up with svirt:s0-s15:c0-c1023 on 
> the QEMU/KVM side and libvirtd_t:s0-s15:c0-c1023 on the libvirtd side; you'll 
> probably still need some MLS overrides on the QEMU/KVM side but you could at 
> least do something using the range.

Yes, that is exactly what is happening.  I find the label
svirt:s0-s15:c0-c1023 abhorrent, but that's neither here nor there.  MLS
as an 'other' class citizen in the label makes me .... unhappy.  So
today we have:

QEMU/KVM process: svirt_t:s3:c156
QEMU/KVM socket:  svirt_t:s0-s15:c0-c1023

sds suggested we only copy the low part of the MLS context to the server
label, which gives us:

QEMU/KVM process: svirt_t:s3:c156
QEMU/KVM socket:  svirt_t:s0:c0

which I don't think is any better as we still have to needlessly use MLS
overrides which pretty much destroys the whole usefulness of vm
isolation here.

This is why I suggested an mls_copy_subset function so things could
'work' if you have ranged objects on either the client or server side.
It only 'works' today if the ranged object is on the server side.....

-Eric



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

Radical idea incoming: it's going to take some work and require some
changes but I hope it might allow the networking controls to 'make
sense'.  We have 2 conflicting goals/requirements when it comes to
network controls.  1) Dan wants to reasonably write rules (which he
understands) which say that process A can talk to Process B.  2) The
kernel sees the socket as the end point not the process.  In the current
world we really only meet requirement #2 and #1 is
difficult/complex/inconsistent/fun/not fun/add term here.

We currently have 3 (well 4) completely separate labels involved in
networking.

task_struct label (label of the process)
struct socket label (via SOCKET_INODE())
struct sock label
struct skbuff secmark label (the 4th I'm sorta ignoring but I think
would work just fine).

I have heard mentioned how there might be a wish to unify and make the
struct socket and struct sock labels always the same.  I'm wondering if
it isn't a good idea the way it is.  We could intentionally use the
struct socket and the struct sock labels for different things.  We use
the struct socket label when making checks between the process and the
socket.  We use the struct sock label when making checks between 2
sockets and between skb's and sockets.

The struct socket labels would be 'created' or 'relabeled' based on the
available peer_sid information.  The struct sock labels would always
(I'm ignoring the possible inconsistencies of sockcreatecon()) be that
of the parent process.  Basically we end up with something like this:

Client Process:	Client Socket:	Client Sock:		Server Sock:	Server Socket:	Server Process:
C1		C1		C1			S2		S2		S2
[Client calls connect]					[Server call accept]
[The client struct socket is relabeled]			[new child socket below, I ignore original socket]
C1		S2		C1			S2		C1		S2

Now we have multiple types of checks wich I know off the top of my head
we want to deal with, namely:  {read/write:socket} {recv:peer}
{recv:packet} There are other like the node and netif checks I don't
know about.  Maybe I want a flag day and throw all those out.  Noone
uses them right?

In any case the process->socket checks like
read/write/connect/bind/listen/accept blah blah blah would all take
place between the process and the label on struct socket.  The inter
socket checks like recv and those in class packet would all be done
using the struct sock label.

All the directionality of the rule makes sense, all the rules make
intuitive sense.  Can this process write to this socket?  Can this type
of sockets rec packets from that type of socket?  Can this process read
from that type of socket and stuff like that?

I think it solves the problems Paul mentioned of being unable to
describe relationships between client/server communication and it solves
my problems of having rules mean the opposite of what they seem.

The biggest issue is that it involves the relabeling of struct socket of
the client side which we do not do today.  What do others think?

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> Paul you are suggesting that I write a MLS rule that says
> 
> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain sockets.
> 
> Which would allow
> 
> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.

Well, based on the domains that were reported earlier in the thread ...

># 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

... I think you just need to write policy that allows "virtd_t:ANYLEVEL" and 
"svirtd_t:ANYLEVEL" to communicate; you shouldn't need to allow 
"svirt_t:ANYLEVEL" to communicate with "svirt_t" since only qemu-kvm is 
running as "svirt_t" and you are trying to get qemu-kvm and libvirtd to talk.

It is also worth pointing out that you don't need to use MLS constraints that 
completely disregard the MLS label, you can do some MLS label bounding, e.g. 
mlsnetwriteranged and mlsnetwritetoclr.  Also, feel free to suggest patches to 
the unix_socket MLS constraints, I'm not convinced they need to use the 
existing network socket constraints.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> > Paul you are suggesting that I write a MLS rule that says
> > 
> > svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain sockets.
> > 
> > Which would allow
> > 
> > svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
> 
> Well, based on the domains that were reported earlier in the thread ...
> 
> ># 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
> 
> ... I think you just need to write policy that allows "virtd_t:ANYLEVEL" and 
> "svirtd_t:ANYLEVEL" to communicate; you shouldn't need to allow 
> "svirt_t:ANYLEVEL" to communicate with "svirt_t" since only qemu-kvm is 
> running as "svirt_t" and you are trying to get qemu-kvm and libvirtd to talk.

The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023
(type of svirt_t and level of the peer, libvirtd_t)   So svirt_t needs
to talk to svirt_t.  That's the whole issue.....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 10:32:13 am Eric Paris wrote:
> On Mon, 2010-03-29 at 16:00 -0400, Paul Moore wrote:
> > On Monday 29 March 2010 02:29:24 pm Eric Paris wrote:
> > > Client Process:	Client Socket:	Client Sock:		Server Sock:	
Server
> > > Socket:	Server Process: C1		C1		C1			S2		S2
> > 
> > S2
> > 
> > > [Client calls connect]					[Server call accept]
> > > [The client struct socket is relabeled]			[new child socket 
below, I
> > 
> > ignore
> > 
> > > original socket] C1		S2		C1			S2		C1		
S2
> > > 
> > > Now we have multiple types of checks wich I know off the top of my head
> > > we want to deal with, namely:  {read/write:socket} {recv:peer}
> > > {recv:packet}
> > 
> > Ungh, put me down as "not a fan".  The relabeling looks like a bit of a
> > hack and makes me nervous about race conditions, policy issues and all
> > sorts of things.  I haven't thought about it completely yet, but what
> > happens if a client wants to set a socket option after it has connected
> > to a remote host? Wouldn't that mean that you would need the following
> > allow rule?
> > 
> >  allow C1 S2:socket { setopt }
> 
> Well that's sorta what we do today with ONLY the MLS component ONLY on
> the server side of the connection.  This makes me sad.

Not really ... at least I hope we don't allow one domain to set the socket 
options of another.

> > I appreciate that you're trying to make a complex thing less so, but
> > sometimes you have to tell Dan "no".
> 
> Believe me, Dan is more surprised when I decide to argue FOR his
> harebrained schemes than when I tell him "no."   *smile*

 ;)

> > I would need to think about this a bit more, but we could have both a
> > "local_label" and a "peer_label" (I'm just picking easy, descriptive
> > names right now) on both a socket and a sock, much like the "sid" and
> > "peer_sid" labels we have now.  All traffic leaving a sock would be
> > wire-labeled based on the "local_label" and all traffic being queued to
> > a sock would be checked against the "local_label" as well.  Applications
> > trying to read and write data to and from a sock queue would be checked
> > against the "peer_label" and the rest of the socket operations,
> > create/connect/listen/setsockopt/getsockopt/etc., would use the
> > "local_label".
> 
> It's the same basic idea I was thinking of, only it looks a bit less
> like using an implementation detail and more like making sense  :)
> 
> getting rid of security_sid_mls_copy() while maintaining (or growing)
> our ability to control traffic would be a great step forward....
> 
> /me tries to find some time to play....

I know we're big fans of code first, design later around here but I think 
there are a few issues that need to be discussed a bit first (and I don't 
consider this an exhaustive list):

1. How do we label the socket's corresponding inode?

2. We would want to ensure the socket's directional labels are handled 
correctly with the SA labels, i.e. label the also directional SAs correctly 
and make sure we don't create useless SAs due to label mis-match (pretty sure 
we have this problem today, at least we did at some point).

3. Policy implications; beware that by making this change policy is going to 
get a lot more involved for TCP based network applications.

4. Is Stephen/NSA on board, in other words, what do the real security geeks 
(no offense intended) have to say about this approach?

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

On 03/30/2010 02:20 PM, Eric Paris wrote:
> On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
>    
>> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
>>      
>>> Paul you are suggesting that I write a MLS rule that says
>>>
>>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain sockets.
>>>
>>> Which would allow
>>>
>>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
>>>        
>> Well, based on the domains that were reported earlier in the thread ...
>>
>>      
>>> # 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
>>>        
>> ... I think you just need to write policy that allows "virtd_t:ANYLEVEL" and
>> "svirtd_t:ANYLEVEL" to communicate; you shouldn't need to allow
>> "svirt_t:ANYLEVEL" to communicate with "svirt_t" since only qemu-kvm is
>> running as "svirt_t" and you are trying to get qemu-kvm and libvirtd to talk.
>>      
> The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023
> (type of svirt_t and level of the peer, libvirtd_t)   So svirt_t needs
> to talk to svirt_t.  That's the whole issue.....
>
> -Eric
>
>    
Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is easy

allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the problem
Since I end up allowing all svirt_t to talk to all svirt_t, No MLS 
controls at all.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
> On 03/30/2010 02:20 PM, Eric Paris wrote:
> > On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
> >> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> >>> Paul you are suggesting that I write a MLS rule that says
> >>> 
> >>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain sockets.
> >>> 
> >>> Which would allow
> >>> 
> >>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
> >> 
> >> Well, based on the domains that were reported earlier in the thread ...
> >> 
> >>> # 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
> >> 
> >> ... I think you just need to write policy that allows "virtd_t:ANYLEVEL"
> >> and "svirtd_t:ANYLEVEL" to communicate; you shouldn't need to allow
> >> "svirt_t:ANYLEVEL" to communicate with "svirt_t" since only qemu-kvm is
> >> running as "svirt_t" and you are trying to get qemu-kvm and libvirtd to
> >> talk.
> > 
> > The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023
> > (type of svirt_t and level of the peer, libvirtd_t)   So svirt_t needs
> > to talk to svirt_t.  That's the whole issue.....
> > 
> > -Eric
> 
> Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is easy
> 
> allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
> problem Since I end up allowing all svirt_t to talk to all svirt_t, No MLS
> controls at all.

Maybe I'm just not thinking straight right now but if QEMU creates the server 
socket, the server's parent socket should be labeled svirt_t:s0:c1.  When 
libvirtd tries to connect its client socket should be labeled virtd_t:s0-
s15:c0.c1023 and the resulting server child socket should be labeled 
svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking along the 
lines of per-socket/message access controls, e.g. selinux_sock_rcv_skb(), 
which don't apply here, it is all socket-to-socket controls.

It would seem to me that the best near term option is to fix the UNIX domain 
socket as discussed previously (I'm half-done with that, got sidetracked by 
this discussion as some RCU fixes) and add setsockcreatecon() support for UNIX 
domain sockets (not sure why we don't support that now).  With that in place, 
libvirtd would do a setsockcreatecon(self:QEMU_MLS_LABEL) before it connected 
to the QEMU instance then the QEMU child socket would be labeled correctly and 
everyone should be happy.  I think it also makes sense given that libvirtd is 
running syslo-syshi and the QEMU instances are running with very specific MLS 
labels.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote:
> On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
> > On 03/30/2010 02:20 PM, Eric Paris wrote:
> > > On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
> > >> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> > >>> Paul you are suggesting that I write a MLS rule that says
> > >>> 
> > >>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain
> > >>> sockets.
> > >>> 
> > >>> Which would allow
> > >>> 
> > >>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
> > >> 
> > >> Well, based on the domains that were reported earlier in the thread
> > >> ...
> > >> 
> > >>> # 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
> > >> 
> > >> ... I think you just need to write policy that allows
> > >> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you
> > >> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with
> > >> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are
> > >> trying to get qemu-kvm and libvirtd to talk.
> > > 
> > > The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023
> > > (type of svirt_t and level of the peer, libvirtd_t)   So svirt_t needs
> > > to talk to svirt_t.  That's the whole issue.....
> > > 
> > > -Eric
> > 
> > Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is
> > easy
> > 
> > allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
> > problem Since I end up allowing all svirt_t to talk to all svirt_t, No
> > MLS controls at all.
> 
> Maybe I'm just not thinking straight right now but if QEMU creates the
> server socket, the server's parent socket should be labeled svirt_t:s0:c1.
>  When libvirtd tries to connect its client socket should be labeled
> virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be
> labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking
> along the lines of per-socket/message access controls, e.g.
> selinux_sock_rcv_skb(), which don't apply here, it is all socket-to-socket
> controls.
> 
> It would seem to me that the best near term option is to fix the UNIX
> domain socket as discussed previously (I'm half-done with that, got
> sidetracked by this discussion as some RCU fixes) and add
> setsockcreatecon() support for UNIX domain sockets (not sure why we don't
> support that now).  With that in place, libvirtd would do a
> setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU
> instance then the QEMU child socket would be labeled correctly and
> everyone should be happy.  I think it also makes sense given that libvirtd
> is running syslo-syshi and the QEMU instances are running with very
> specific MLS labels.

Nevermind again, looking at the code it does look like setsockcreatecon() 
should work for UNIX domain sockets in the current code base ... anyway, I'd 
still go with the setsockcreatecon() approach.  I'll work on getting an RFC 
class UNIX socket patch out today.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

On 03/30/2010 02:56 PM, Paul Moore wrote:
> On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote:
>    
>> On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
>>      
>>> On 03/30/2010 02:20 PM, Eric Paris wrote:
>>>        
>>>> On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
>>>>          
>>>>> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
>>>>>            
>>>>>> Paul you are suggesting that I write a MLS rule that says
>>>>>>
>>>>>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain
>>>>>> sockets.
>>>>>>
>>>>>> Which would allow
>>>>>>
>>>>>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
>>>>>>              
>>>>> Well, based on the domains that were reported earlier in the thread
>>>>> ...
>>>>>
>>>>>            
>>>>>> # 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
>>>>>>              
>>>>> ... I think you just need to write policy that allows
>>>>> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you
>>>>> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with
>>>>> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are
>>>>> trying to get qemu-kvm and libvirtd to talk.
>>>>>            
>>>> The QEMU/KVM "server child socket" gets labeled svirt_t:s0-s15:c0-c1023
>>>> (type of svirt_t and level of the peer, libvirtd_t)   So svirt_t needs
>>>> to talk to svirt_t.  That's the whole issue.....
>>>>
>>>> -Eric
>>>>          
>>> Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is
>>> easy
>>>
>>> allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
>>> problem Since I end up allowing all svirt_t to talk to all svirt_t, No
>>> MLS controls at all.
>>>        
>> Maybe I'm just not thinking straight right now but if QEMU creates the
>> server socket, the server's parent socket should be labeled svirt_t:s0:c1.
>>   When libvirtd tries to connect its client socket should be labeled
>> virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be
>> labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking
>> along the lines of per-socket/message access controls, e.g.
>> selinux_sock_rcv_skb(), which don't apply here, it is all socket-to-socket
>> controls.
>>
>> It would seem to me that the best near term option is to fix the UNIX
>> domain socket as discussed previously (I'm half-done with that, got
>> sidetracked by this discussion as some RCU fixes) and add
>> setsockcreatecon() support for UNIX domain sockets (not sure why we don't
>> support that now).  With that in place, libvirtd would do a
>> setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU
>> instance then the QEMU child socket would be labeled correctly and
>> everyone should be happy.  I think it also makes sense given that libvirtd
>> is running syslo-syshi and the QEMU instances are running with very
>> specific MLS labels.
>>      
> Nevermind again, looking at the code it does look like setsockcreatecon()
> should work for UNIX domain sockets in the current code base ... anyway, I'd
> still go with the setsockcreatecon() approach.  I'll work on getting an RFC
> class UNIX socket patch out today.
>
>    
With that change both ends of the socket would be

svirt_t:level1 and svirt_t:level1

or

virtd_t:level1 and svirt_t:level1

?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

On Mon, 2010-03-29 at 16:00 -0400, Paul Moore wrote:
> Sorry, I don't think it is very intuitive and the directionality is still a 
> bit questionable.  If you're really looking to come up with directional socket 
> labels, let's just make directional socket labels; believe it or not, we're 
> actually much closer to that then you make think ... here is a clue, look at 
> the "peer_sid" field which we store for connected sockets.
> 
> I would need to think about this a bit more, but we could have both a 
> "local_label" and a "peer_label" (I'm just picking easy, descriptive names 
> right now) on both a socket and a sock, much like the "sid" and "peer_sid" 
> labels we have now.  All traffic leaving a sock would be wire-labeled based on 
> the "local_label" and all traffic being queued to a sock would be checked 
> against the "local_label" as well.  Applications trying to read and write data 
> to and from a sock queue would be checked against the "peer_label" and the 
> rest of the socket operations, 
> create/connect/listen/setsockopt/getsockopt/etc., would use the "local_label".
> 
> I need to think about this some more, but I like the approach above much more 
> than labeling the socket/sock differently.

I don't think this is necessary, and it seems to have the same problems
I noted previously with Eric's proposal - you end up with different
meanings for the same permission check for pre-connection vs
post-connection and for connection-oriented vs. connectionless.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 03:13:29 pm Daniel J Walsh wrote:
> On 03/30/2010 02:56 PM, Paul Moore wrote:
> > On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote:
> >> On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
> >>> On 03/30/2010 02:20 PM, Eric Paris wrote:
> >>>> On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
> >>>>> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> >>>>>> Paul you are suggesting that I write a MLS rule that says
> >>>>>> 
> >>>>>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain
> >>>>>> sockets.
> >>>>>> 
> >>>>>> Which would allow
> >>>>>> 
> >>>>>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
> >>>>> 
> >>>>> Well, based on the domains that were reported earlier in the thread
> >>>>> ...
> >>>>> 
> >>>>>> # 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
> >>>>> 
> >>>>> ... I think you just need to write policy that allows
> >>>>> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you
> >>>>> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with
> >>>>> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are
> >>>>> trying to get qemu-kvm and libvirtd to talk.
> >>>> 
> >>>> The QEMU/KVM "server child socket" gets labeled
> >>>> svirt_t:s0-s15:c0-c1023 (type of svirt_t and level of the peer,
> >>>> libvirtd_t)   So svirt_t needs to talk to svirt_t.  That's the whole
> >>>> issue.....
> >>>> 
> >>>> -Eric
> >>> 
> >>> Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is
> >>> easy
> >>> 
> >>> allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
> >>> problem Since I end up allowing all svirt_t to talk to all svirt_t, No
> >>> MLS controls at all.
> >> 
> >> Maybe I'm just not thinking straight right now but if QEMU creates the
> >> server socket, the server's parent socket should be labeled
> >> svirt_t:s0:c1.
> >> 
> >>   When libvirtd tries to connect its client socket should be labeled
> >> 
> >> virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be
> >> labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking
> >> along the lines of per-socket/message access controls, e.g.
> >> selinux_sock_rcv_skb(), which don't apply here, it is all
> >> socket-to-socket controls.
> >> 
> >> It would seem to me that the best near term option is to fix the UNIX
> >> domain socket as discussed previously (I'm half-done with that, got
> >> sidetracked by this discussion as some RCU fixes) and add
> >> setsockcreatecon() support for UNIX domain sockets (not sure why we
> >> don't support that now).  With that in place, libvirtd would do a
> >> setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU
> >> instance then the QEMU child socket would be labeled correctly and
> >> everyone should be happy.  I think it also makes sense given that
> >> libvirtd is running syslo-syshi and the QEMU instances are running with
> >> very specific MLS labels.
> > 
> > Nevermind again, looking at the code it does look like setsockcreatecon()
> > should work for UNIX domain sockets in the current code base ... anyway,
> > I'd still go with the setsockcreatecon() approach.  I'll work on getting
> > an RFC class UNIX socket patch out today.
> 
> With that change both ends of the socket would be
> 
> svirt_t:level1 and svirt_t:level1
> 
> or
> 
> virtd_t:level1 and svirt_t:level1

I believe that you should see the following:

 QEMU: svirt_t:s0:c1 (parent socket) and svirt_t:s0:c1 (child socket)

 libvirtd: virtd_t:s0:c1 (client socket)

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Daniel J Walsh]

On 03/30/2010 03:22 PM, Paul Moore wrote:
> On Tuesday 30 March 2010 03:13:29 pm Daniel J Walsh wrote:
>    
>> On 03/30/2010 02:56 PM, Paul Moore wrote:
>>      
>>> On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote:
>>>        
>>>> On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
>>>>          
>>>>> On 03/30/2010 02:20 PM, Eric Paris wrote:
>>>>>            
>>>>>> On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
>>>>>>              
>>>>>>> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
>>>>>>>                
>>>>>>>> Paul you are suggesting that I write a MLS rule that says
>>>>>>>>
>>>>>>>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain
>>>>>>>> sockets.
>>>>>>>>
>>>>>>>> Which would allow
>>>>>>>>
>>>>>>>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
>>>>>>>>                  
>>>>>>> Well, based on the domains that were reported earlier in the thread
>>>>>>> ...
>>>>>>>
>>>>>>>                
>>>>>>>> # 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
>>>>>>>>                  
>>>>>>> ... I think you just need to write policy that allows
>>>>>>> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you
>>>>>>> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with
>>>>>>> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are
>>>>>>> trying to get qemu-kvm and libvirtd to talk.
>>>>>>>                
>>>>>> The QEMU/KVM "server child socket" gets labeled
>>>>>> svirt_t:s0-s15:c0-c1023 (type of svirt_t and level of the peer,
>>>>>> libvirtd_t)   So svirt_t needs to talk to svirt_t.  That's the whole
>>>>>> issue.....
>>>>>>
>>>>>> -Eric
>>>>>>              
>>>>> Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is
>>>>> easy
>>>>>
>>>>> allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
>>>>> problem Since I end up allowing all svirt_t to talk to all svirt_t, No
>>>>> MLS controls at all.
>>>>>            
>>>> Maybe I'm just not thinking straight right now but if QEMU creates the
>>>> server socket, the server's parent socket should be labeled
>>>> svirt_t:s0:c1.
>>>>
>>>>    When libvirtd tries to connect its client socket should be labeled
>>>>
>>>> virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be
>>>> labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking
>>>> along the lines of per-socket/message access controls, e.g.
>>>> selinux_sock_rcv_skb(), which don't apply here, it is all
>>>> socket-to-socket controls.
>>>>
>>>> It would seem to me that the best near term option is to fix the UNIX
>>>> domain socket as discussed previously (I'm half-done with that, got
>>>> sidetracked by this discussion as some RCU fixes) and add
>>>> setsockcreatecon() support for UNIX domain sockets (not sure why we
>>>> don't support that now).  With that in place, libvirtd would do a
>>>> setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU
>>>> instance then the QEMU child socket would be labeled correctly and
>>>> everyone should be happy.  I think it also makes sense given that
>>>> libvirtd is running syslo-syshi and the QEMU instances are running with
>>>> very specific MLS labels.
>>>>          
>>> Nevermind again, looking at the code it does look like setsockcreatecon()
>>> should work for UNIX domain sockets in the current code base ... anyway,
>>> I'd still go with the setsockcreatecon() approach.  I'll work on getting
>>> an RFC class UNIX socket patch out today.
>>>        
>> With that change both ends of the socket would be
>>
>> svirt_t:level1 and svirt_t:level1
>>
>> or
>>
>> virtd_t:level1 and svirt_t:level1
>>      
> I believe that you should see the following:
>
>   QEMU: svirt_t:s0:c1 (parent socket) and svirt_t:s0:c1 (child socket)
>
>   libvirtd: virtd_t:s0:c1 (client socket)
>
>    
libvirt would have to execute

setsockcreatecon("system_u:system_r:svirt_t:s0:c1")
Then connect to the socket?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

On Tue, 2010-03-30 at 15:31 -0400, Daniel J Walsh wrote:
> On 03/30/2010 03:22 PM, Paul Moore wrote:
> > On Tuesday 30 March 2010 03:13:29 pm Daniel J Walsh wrote:
> >    
> >> On 03/30/2010 02:56 PM, Paul Moore wrote:
> >>      
> >>> On Tuesday 30 March 2010 02:39:05 pm Paul Moore wrote:
> >>>        
> >>>> On Tuesday 30 March 2010 02:23:33 pm Daniel J Walsh wrote:
> >>>>          
> >>>>> On 03/30/2010 02:20 PM, Eric Paris wrote:
> >>>>>            
> >>>>>> On Tue, 2010-03-30 at 14:07 -0400, Paul Moore wrote:
> >>>>>>              
> >>>>>>> On Tuesday 30 March 2010 10:45:33 am Daniel J Walsh wrote:
> >>>>>>>                
> >>>>>>>> Paul you are suggesting that I write a MLS rule that says
> >>>>>>>>
> >>>>>>>> svirt_t:ANYLEVEL can talk to svirt_t:ANYLEVEL over unix domain
> >>>>>>>> sockets.
> >>>>>>>>
> >>>>>>>> Which would allow
> >>>>>>>>
> >>>>>>>> svirt_t:s0 to talk to svirt_t:s1  Which seems very broken to me.
> >>>>>>>>                  
> >>>>>>> Well, based on the domains that were reported earlier in the thread
> >>>>>>> ...
> >>>>>>>
> >>>>>>>                
> >>>>>>>> # 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
> >>>>>>>>                  
> >>>>>>> ... I think you just need to write policy that allows
> >>>>>>> "virtd_t:ANYLEVEL" and "svirtd_t:ANYLEVEL" to communicate; you
> >>>>>>> shouldn't need to allow "svirt_t:ANYLEVEL" to communicate with
> >>>>>>> "svirt_t" since only qemu-kvm is running as "svirt_t" and you are
> >>>>>>> trying to get qemu-kvm and libvirtd to talk.
> >>>>>>>                
> >>>>>> The QEMU/KVM "server child socket" gets labeled
> >>>>>> svirt_t:s0-s15:c0-c1023 (type of svirt_t and level of the peer,
> >>>>>> libvirtd_t)   So svirt_t needs to talk to svirt_t.  That's the whole
> >>>>>> issue.....
> >>>>>>
> >>>>>> -Eric
> >>>>>>              
> >>>>> Yes letting svirt_t:level1 talk to libvirt_t:RangecontinaingLevel1 is
> >>>>> easy
> >>>>>
> >>>>> allowing svirt_t:level1 talk to svirt_t:RangecontainingLevel1 is the
> >>>>> problem Since I end up allowing all svirt_t to talk to all svirt_t, No
> >>>>> MLS controls at all.
> >>>>>            
> >>>> Maybe I'm just not thinking straight right now but if QEMU creates the
> >>>> server socket, the server's parent socket should be labeled
> >>>> svirt_t:s0:c1.
> >>>>
> >>>>    When libvirtd tries to connect its client socket should be labeled
> >>>>
> >>>> virtd_t:s0- s15:c0.c1023 and the resulting server child socket should be
> >>>> labeled svirt_t:s0:c1 ... ah, okay, nevermind, I'm stupid.  I'm thinking
> >>>> along the lines of per-socket/message access controls, e.g.
> >>>> selinux_sock_rcv_skb(), which don't apply here, it is all
> >>>> socket-to-socket controls.
> >>>>
> >>>> It would seem to me that the best near term option is to fix the UNIX
> >>>> domain socket as discussed previously (I'm half-done with that, got
> >>>> sidetracked by this discussion as some RCU fixes) and add
> >>>> setsockcreatecon() support for UNIX domain sockets (not sure why we
> >>>> don't support that now).  With that in place, libvirtd would do a
> >>>> setsockcreatecon(self:QEMU_MLS_LABEL) before it connected to the QEMU
> >>>> instance then the QEMU child socket would be labeled correctly and
> >>>> everyone should be happy.  I think it also makes sense given that
> >>>> libvirtd is running syslo-syshi and the QEMU instances are running with
> >>>> very specific MLS labels.
> >>>>          
> >>> Nevermind again, looking at the code it does look like setsockcreatecon()
> >>> should work for UNIX domain sockets in the current code base ... anyway,
> >>> I'd still go with the setsockcreatecon() approach.  I'll work on getting
> >>> an RFC class UNIX socket patch out today.
> >>>        
> >> With that change both ends of the socket would be
> >>
> >> svirt_t:level1 and svirt_t:level1
> >>
> >> or
> >>
> >> virtd_t:level1 and svirt_t:level1
> >>      
> > I believe that you should see the following:
> >
> >   QEMU: svirt_t:s0:c1 (parent socket) and svirt_t:s0:c1 (child socket)
> >
> >   libvirtd: virtd_t:s0:c1 (client socket)
> >
> >    
> libvirt would have to execute
> 
> setsockcreatecon("system_u:system_r:svirt_t:s0:c1")
> Then connect to the socket?

No, libvirt would use its own context and only modify the MLS part to
match the target qemu instance.  And it would call setsockcreatecon()
before creating the client socket.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Eric Paris]

On Tue, 2010-03-30 at 15:20 -0400, Stephen Smalley wrote:
> On Mon, 2010-03-29 at 16:00 -0400, Paul Moore wrote:
> > Sorry, I don't think it is very intuitive and the directionality is still a 
> > bit questionable.  If you're really looking to come up with directional socket 
> > labels, let's just make directional socket labels; believe it or not, we're 
> > actually much closer to that then you make think ... here is a clue, look at 
> > the "peer_sid" field which we store for connected sockets.
> > 
> > I would need to think about this a bit more, but we could have both a 
> > "local_label" and a "peer_label" (I'm just picking easy, descriptive names 
> > right now) on both a socket and a sock, much like the "sid" and "peer_sid" 
> > labels we have now.  All traffic leaving a sock would be wire-labeled based on 
> > the "local_label" and all traffic being queued to a sock would be checked 
> > against the "local_label" as well.  Applications trying to read and write data 
> > to and from a sock queue would be checked against the "peer_label" and the 
> > rest of the socket operations, 
> > create/connect/listen/setsockopt/getsockopt/etc., would use the "local_label".
> > 
> > I need to think about this some more, but I like the approach above much more 
> > than labeling the socket/sock differently.
> 
> I don't think this is necessary, and it seems to have the same problems
> I noted previously with Eric's proposal - you end up with different
> meanings for the same permission check for pre-connection vs
> post-connection and for connection-oriented vs. connectionless.

/me cries and dies a little inside if we think the current situation is
a good one.

security_sid_mls_copy() is a dirty ugly hack and it's very existence
points out that SOMETHING is wrong.  If we don't need that in TE why do
we need that in MLS.  ewwwwwwwwwww.

We already have magic differences between pre-connection and
post-connection and between connection-oriented vs connectionless.  The
only difference is that today those differences don't make logical
sense, even if you can almost manage to eventually write rules which
meet meaningful security goals.  As we see with libvirt and KVM/QEMU we
have to change the application.   eww.

While I realize that coding without thought isn't going to solve the
problem, it's the best method for me to see all of the fall out of the
idea.  /me wants some time to play with this.

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Stephen Smalley]

On Tue, 2010-03-30 at 16:17 -0400, Eric Paris wrote:
> On Tue, 2010-03-30 at 15:20 -0400, Stephen Smalley wrote:
> > On Mon, 2010-03-29 at 16:00 -0400, Paul Moore wrote:
> > > Sorry, I don't think it is very intuitive and the directionality is still a 
> > > bit questionable.  If you're really looking to come up with directional socket 
> > > labels, let's just make directional socket labels; believe it or not, we're 
> > > actually much closer to that then you make think ... here is a clue, look at 
> > > the "peer_sid" field which we store for connected sockets.
> > > 
> > > I would need to think about this a bit more, but we could have both a 
> > > "local_label" and a "peer_label" (I'm just picking easy, descriptive names 
> > > right now) on both a socket and a sock, much like the "sid" and "peer_sid" 
> > > labels we have now.  All traffic leaving a sock would be wire-labeled based on 
> > > the "local_label" and all traffic being queued to a sock would be checked 
> > > against the "local_label" as well.  Applications trying to read and write data 
> > > to and from a sock queue would be checked against the "peer_label" and the 
> > > rest of the socket operations, 
> > > create/connect/listen/setsockopt/getsockopt/etc., would use the "local_label".
> > > 
> > > I need to think about this some more, but I like the approach above much more 
> > > than labeling the socket/sock differently.
> > 
> > I don't think this is necessary, and it seems to have the same problems
> > I noted previously with Eric's proposal - you end up with different
> > meanings for the same permission check for pre-connection vs
> > post-connection and for connection-oriented vs. connectionless.
> 
> /me cries and dies a little inside if we think the current situation is
> a good one.
> 
> security_sid_mls_copy() is a dirty ugly hack and it's very existence
> points out that SOMETHING is wrong.  If we don't need that in TE why do
> we need that in MLS.  ewwwwwwwwwww.

I agree with that.  But fixing that doesn't require fundamentally
changing how the network access controls are performed.  As I said
earlier, there used to be a listen_secure() API that allowed an
application to specify that it wanted the entire SID reflected on new
connection sockets, with the default being inheritance from the
listening socket. Or you can go with the type-transition style approach
of allowing the new connection socket security context to be computed
from a hybrid of the listening socket context and the client socket
context based on policy rules.  But none of that changes the permission
checks or how client sockets are labeled or introduce yet another
distinct label on the socket.

> We already have magic differences between pre-connection and
> post-connection and between connection-oriented vs connectionless.  The
> only difference is that today those differences don't make logical
> sense, even if you can almost manage to eventually write rules which
> meet meaningful security goals.  As we see with libvirt and KVM/QEMU we
> have to change the application.   eww.
> 
> While I realize that coding without thought isn't going to solve the
> problem, it's the best method for me to see all of the fall out of the
> idea.  /me wants some time to play with this.
> 
> -Eric
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: svirt on MLS has strange AVC.

[Paul Moore]

On Tuesday 30 March 2010 04:17:30 pm Eric Paris wrote:
> ... As we see with libvirt and KVM/QEMU we have to change the application.   
> eww.

To be fair, let's remember that you got into this condition because you 
changed the application, libvirtd, to run a child process with a different 
label - once you start doing wacky stuff, you need to be prepared to do more 
wacky stuff to get it to work properly :)

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.