[Pkg-xen-devel] Bug#597403: Bug#597403: Bug#597403: xen-utils-common: need to run restorecon in /etc/init.d/xend on SE Linux systems

[Russell Coker]

On Mon, 20 Sep 2010, Bastian Blank <waldi at debian.org> wrote:
> > > No, it does not. The code to create devices in libxc was removed.
> > 
> > What is libxc?
> 
> The core xen library interface. It used to create devices on its own.
> Please check if there is still a mknod permission for Xen related parts
> in the selinux policy.

There is still mknod.  Not sure if it's needed though, I'll have to check.

> > The kernel creates the device node /dev/xen/evtchn, the creation process
> > bypasses even the kernel auditing layer because it's in the kernel.
> > http://marc.info/?t=128295019200002&r=1&w=2
> > The above URL has a link to some of the discussion of this issue by Red
> > Hat people.  They are working on a nicer solution, but we can't do that
> > for Squeeze.
> 
> My interpretation is: udev needs to change the context for already
> existing files the same way it does with the DAC permissions. udev
> _still_ gets it hands on the devices, otherwise all the permissions
> would be wrong.

Device nodes that existed prior to udev starting are correctly labeled.  It's 
the ones that appear unexpectedly that cause this problem.

> > > > But for Squeeze it would be good if this could get included.  It's
> > > > one line of shell code that results in nothing being done if
> > > > policycoreutils is not installed.  I can't imagine any way that such
> > > > a change could break anything.
> > > 
> > > You want do change a undefined number of packages?
> > 
> > I want to change every package that has a confined daemon which has a
> > startup script that loads a kernel module which creates a devtmpfs node
> > rather than just allowing udev to do it.
> 
> If selinux can't cope with devtmpfs, don't use it.

How do I not use devtmpfs?

> > I don't think that will be many packages.
> 
> As you don't seem to know that, please discuss that under
> mass-bugfilling rules. Also yoo have to discuss that with the release
> team, we are in deep freeze right now.

Having done a reasonable amount of testing and not discovered any other such 
packages and having not seen any reference to the same problem in other 
packages by the Red Hat people it seems unlikely that there will be many bug 
reports needed.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog