http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
vhost_device_t added for libvirt/qemu
/dev/usbmon device added
Added default label for /sys so libvirt could relabel to it.
lots of new interfaces.
On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
>
> vhost_device_t added for libvirt/qemu
>
> /dev/usbmon device added
>
> Added default label for /sys so libvirt could relabel to it.
I don't understand this. There should be no files labeled sysfs_t,
except for the entries created by the kernel on the fs itself, which get
the right label already.
> lots of new interfaces.
Otherwise merged.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
> On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
>>
>> vhost_device_t added for libvirt/qemu
>>
>> /dev/usbmon device added
>>
>> Added default label for /sys so libvirt could relabel to it.
>
> I don't understand this. There should be no files labeled sysfs_t,
> except for the entries created by the kernel on the fs itself, which get
> the right label already.
>
>> lots of new interfaces.
>
> Otherwise merged.
>
libvirt currently does the equivalent of
chcon svirt_t:MCS1 DEVICE
Run QEMU
restorecon DEVICE
If /sys is <<none>> then it does not have a label to change the context
back to. And leaves the context with a label svirt_t:MCS1. If it later
picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
On Mon, 2010-06-07 at 09:23 -0400, Daniel J Walsh wrote:
> On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
> > On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
> >>
> >> Added default label for /sys so libvirt could relabel to it.
> >
> > I don't understand this. There should be no files labeled sysfs_t,
> > except for the entries created by the kernel on the fs itself, which get
> > the right label already.
> >
> libvirt currently does the equivalent of
>
> chcon svirt_t:MCS1 DEVICE
> Run QEMU
> restorecon DEVICE
>
> If /sys is <<none>> then it does not have a label to change the context
> back to. And leaves the context with a label svirt_t:MCS1. If it later
> picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
I still don't understand. There are no device nodes in sysfs.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 06/07/2010 09:39 AM, Christopher J. PeBenito wrote:
> On Mon, 2010-06-07 at 09:23 -0400, Daniel J Walsh wrote:
>> On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
>>> On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
>>>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
>>>>
>>>> Added default label for /sys so libvirt could relabel to it.
>>>
>>> I don't understand this. There should be no files labeled sysfs_t,
>>> except for the entries created by the kernel on the fs itself, which get
>>> the right label already.
>>>
>> libvirt currently does the equivalent of
>>
>> chcon svirt_t:MCS1 DEVICE
>> Run QEMU
>> restorecon DEVICE
>>
>> If /sys is<<none>> then it does not have a label to change the context
>> back to. And leaves the context with a label svirt_t:MCS1. If it later
>> picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
>
> I still don't understand. There are no device nodes in sysfs.
>
sysfs supports labeling now. Certain objects need to have a
svirt_image_t:MCS label associated with them under /sys (Usb devices?)
When libvirt needs to changes these labels back to the default it asks
matchpathcon and it returns sysfs_t.
On Mon, 2010-06-07 at 11:52 -0400, Daniel J Walsh wrote:
> On 06/07/2010 09:39 AM, Christopher J. PeBenito wrote:
> > On Mon, 2010-06-07 at 09:23 -0400, Daniel J Walsh wrote:
> >> On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
> >>> On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
> >>>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
> >>>>
> >>>> Added default label for /sys so libvirt could relabel to it.
> >>>
> >>> I don't understand this. There should be no files labeled sysfs_t,
> >>> except for the entries created by the kernel on the fs itself, which get
> >>> the right label already.
> >>>
> >> libvirt currently does the equivalent of
> >>
> >> chcon svirt_t:MCS1 DEVICE
> >> Run QEMU
> >> restorecon DEVICE
> >>
> >> If /sys is<<none>> then it does not have a label to change the context
> >> back to. And leaves the context with a label svirt_t:MCS1. If it later
> >> picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
> >
> > I still don't understand. There are no device nodes in sysfs.
> >
> sysfs supports labeling now. Certain objects need to have a
> svirt_image_t:MCS label associated with them under /sys (Usb devices?)
> When libvirt needs to changes these labels back to the default it asks
> matchpathcon and it returns sysfs_t.
This is to support access to PCI device resources via sysfs.
See Documentation/sysfs-pci.txt.
--
Stephen Smalley
National Security Agency
On Mon, 2010-06-07 at 11:52 -0400, Daniel J Walsh wrote:
> On 06/07/2010 09:39 AM, Christopher J. PeBenito wrote:
> > On Mon, 2010-06-07 at 09:23 -0400, Daniel J Walsh wrote:
> >> On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
> >>> On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
> >>>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
> >>>>
> >>>> Added default label for /sys so libvirt could relabel to it.
> >>>
> >>> I don't understand this. There should be no files labeled sysfs_t,
> >>> except for the entries created by the kernel on the fs itself, which get
> >>> the right label already.
> >>>
> >> libvirt currently does the equivalent of
> >>
> >> chcon svirt_t:MCS1 DEVICE
> >> Run QEMU
> >> restorecon DEVICE
> >>
> >> If /sys is<<none>> then it does not have a label to change the context
> >> back to. And leaves the context with a label svirt_t:MCS1. If it later
> >> picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
> >
> > I still don't understand. There are no device nodes in sysfs.
> >
> sysfs supports labeling now. Certain objects need to have a
> svirt_image_t:MCS label associated with them under /sys (Usb devices?)
> When libvirt needs to changes these labels back to the default it asks
> matchpathcon and it returns sysfs_t.
Why doesn't it save the previous label and then restore it? That is much
more sane, in case the previous label was not sysfs_t. I don't know if
thats likely to happen, but it seems safer too.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Mon, 2010-06-07 at 14:00 -0400, Christopher J. PeBenito wrote:
> On Mon, 2010-06-07 at 11:52 -0400, Daniel J Walsh wrote:
> > On 06/07/2010 09:39 AM, Christopher J. PeBenito wrote:
> > > On Mon, 2010-06-07 at 09:23 -0400, Daniel J Walsh wrote:
> > >> On 06/07/2010 09:20 AM, Christopher J. PeBenito wrote:
> > >>> On Wed, 2010-06-02 at 16:19 -0400, Daniel J Walsh wrote:
> > >>>> http://people.fedoraproject.org/~dwalsh/SELinux/F14/kernel_devices.patch
> > >>>>
> > >>>> Added default label for /sys so libvirt could relabel to it.
> > >>>
> > >>> I don't understand this. There should be no files labeled sysfs_t,
> > >>> except for the entries created by the kernel on the fs itself, which get
> > >>> the right label already.
> > >>>
> > >> libvirt currently does the equivalent of
> > >>
> > >> chcon svirt_t:MCS1 DEVICE
> > >> Run QEMU
> > >> restorecon DEVICE
> > >>
> > >> If /sys is<<none>> then it does not have a label to change the context
> > >> back to. And leaves the context with a label svirt_t:MCS1. If it later
> > >> picks an svirt_t:MCS1 for a different image, this /sys device is vulnerable.
> > >
> > > I still don't understand. There are no device nodes in sysfs.
> > >
> > sysfs supports labeling now. Certain objects need to have a
> > svirt_image_t:MCS label associated with them under /sys (Usb devices?)
> > When libvirt needs to changes these labels back to the default it asks
> > matchpathcon and it returns sysfs_t.
>
> Why doesn't it save the previous label and then restore it? That is much
> more sane, in case the previous label was not sysfs_t. I don't know if
> thats likely to happen, but it seems safer too.
I suggested that as well, and they said the problem is tracking the
state across libvirtd restarts, although they hope to migrate to that
approach long term.
--
Stephen Smalley
National Security Agency