xen, selinux, FC5

[Robin Bowes]

Hi,

I'm trying to get xen working on FC5 with SELinux enabled.

# rpm -q kernel-xen0 xen selinux-policy
kernel-xen0-2.6.17-1.2187_FC5
xen-3.0.2-3.FC5
selinux-policy-2.3.7-2.fc5

I'm doing it by running stuff and seeing what AVC msgs I get and
creating a custom module to allow them.

e.g, I run this command:

audit2allow -M local -l -i /var/log/audit/audit.log

Then merge any new entries from local.te into xen.te and rebuild the module:

export SEAPP=xen
checkmodule -M -m -o ${SEAPP}.mod ${SEAPP}.te
semodule_package -o ${SEAPP}.pp -m ${SEAPP}.mod
semodule -i ${SEAPP}.pp

This seems to be working fine - I have FC5 installed as a host, with a
guest install of FC5 running as a guest. The "snapshot" capability also
works (xm save ...).

This is the module I'm using:

module local 1.0;

require {
        class chr_file { read write };
        class dir { add_name create search setattr write };
        class fd use;
        class file { append create read write };
        class unix_stream_socket { read write };
        type home_root_t;
        type ifconfig_t;
        type local_login_t;
        type netutils_t;
        type proc_xen_t;
        type tmp_t;
        type tty_device_t;
        type user_home_dir_t;
        type user_home_t;
        type var_log_t;
        type var_run_t;
        type xend_t;
        type xend_var_log_t;
        role system_r;
};

allow ifconfig_t var_log_t:file append;
allow netutils_t proc_xen_t:file { read write };
allow netutils_t xend_t:unix_stream_socket { read write };
allow netutils_t xend_var_log_t:file { append write };
allow xend_t home_root_t:dir { search write };
allow xend_t local_login_t:fd use;
allow xend_t tmp_t:dir search;
allow xend_t tty_device_t:chr_file { read write };
allow xend_t user_home_dir_t:dir { search write };
allow xend_t user_home_t:dir { add_name search write };
allow xend_t user_home_t:file { create write };
allow xend_t var_run_t:dir { create setattr };

My question is: is this the right approach to getting xen (or any app)
working under selinux? Or is there an easier way? Am I opening up any
major security holes doing this?

On other problem I've noticed is that the xendomains init script didn't
start the domains at boot, or from the command-line. I've copied the new
one from https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120075
but I was seeing this error:

# service xendomains start
Starting auto Xen domains:Error: Disk isn't accessible

This is the context of that file:

-rwxr-xr-x  root root system_u:object_r:initrc_exec_t  xendomains

I copied xendomains to xendomains.new so it has this context:

-rwxr-xr-x  root root root:object_r:etc_t              xendomains.new

And the script now works.

Again, is this the (or a) correct fix? Any security problems with this?

Thanks,

R.

[Robin Bowes]

Robin Bowes wrote:
> On other problem I've noticed is that the xendomains init script didn't
> start the domains at boot, or from the command-line. I've copied the new
> one from https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120075
> but I was seeing this error:
>
> # service xendomains start
> Starting auto Xen domains:Error: Disk isn't accessible
>
> This is the context of that file:
>
> -rwxr-xr-x  root root system_u:object_r:initrc_exec_t  xendomains
>
> I copied xendomains to xendomains.new so it has this context:
>
> -rwxr-xr-x  root root root:object_r:etc_t              xendomains.new
>
> And the script now works.
>
> Again, is this the (or a) correct fix? Any security problems with this?

Hmmm. xendomains is not starting the guest instances at reboot.

I see this error in send.log:

[2006-10-13 16:34:28 xend] ERROR (XendBootloader:36) Disk isn't accessible

I also get new AVC msgs:

allow xm_t fixed_disk_device_t:blk_file read;

When I add this to the policy file, i.e.:

class blk_file read;
type fixed_disk_device_t;
type xm_t;
allow xm_t fixed_disk_device_t:blk_file read;

I get this error when loading the compiled policy:

# semodule -i $xen.pp
libsepol.check_assertion_helper: assertion on line 0 violated by allow
xm_t fixed_disk_device_t:blk_file { read };
libsepol.check_assertions: 1 assertion violations occured
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!

Any suggestions as to how to fix this?

Thanks,

R.

[Stephen Smalley]

On Fri, 2006-10-13 at 16:48 +0100, Robin Bowes wrote:
> Robin Bowes wrote:
> > On other problem I've noticed is that the xendomains init script didn't
> > start the domains at boot, or from the command-line. I've copied the new
> > one from https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120075
> > but I was seeing this error:
> >
> > # service xendomains start
> > Starting auto Xen domains:Error: Disk isn't accessible
> >
> > This is the context of that file:
> >
> > -rwxr-xr-x  root root system_u:object_r:initrc_exec_t  xendomains
> >
> > I copied xendomains to xendomains.new so it has this context:
> >
> > -rwxr-xr-x  root root root:object_r:etc_t              xendomains.new
> >
> > And the script now works.
> >
> > Again, is this the (or a) correct fix? Any security problems with this?
>
> Hmmm. xendomains is not starting the guest instances at reboot.
>
> I see this error in send.log:
>
> [2006-10-13 16:34:28 xend] ERROR (XendBootloader:36) Disk isn't accessible
>
> I also get new AVC msgs:
>
> allow xm_t fixed_disk_device_t:blk_file read;
>
> When I add this to the policy file, i.e.:
>
> class blk_file read;
> type fixed_disk_device_t;
> type xm_t;
> allow xm_t fixed_disk_device_t:blk_file read;
>
> I get this error when loading the compiled policy:
>
> # semodule -i $xen.pp
> libsepol.check_assertion_helper: assertion on line 0 violated by allow
> xm_t fixed_disk_device_t:blk_file { read };
> libsepol.check_assertions: 1 assertion violations occured
> libsemanage.semanage_expand_sandbox: Expand module failed
> semodule:  Failed!
>
> Any suggestions as to how to fix this?

The assertion is to prevent accidental granting of read access to a raw
disk device.  Is that truly required here?  To allow it, you need to use
the interface for it, e.g.
    storage_raw_read_fixed_disk(xm_t)
That interface is defined in kernel/storage.if.
In addition to allowing the permission, it adds a type attribute to the
type that excludes from the assertion.

[Robin Bowes]

Stephen Smalley wrote:
> The assertion is to prevent accidental granting of read access to a
> raw disk device.  Is that truly required here?

Probably - the root disk of the guest O/S instance is an lvm partition,
e.g. /dev/vg01/lv_guest
> To allow it, you need to use the interface for it, e.g. 
> storage_raw_read_fixed_disk(xm_t) That interface is defined in
> kernel/storage.if. In addition to allowing the permission, it adds a
> type attribute to the type that excludes from the assertion.

So, what would that look like in the policy file?

Thanks,

R.

[Stephen Smalley]

On Fri, 2006-10-13 at 17:12 +0100, Robin Bowes wrote:
> Stephen Smalley wrote:
> > The assertion is to prevent accidental granting of read access to a
> > raw disk device.  Is that truly required here?
>
> Probably - the root disk of the guest O/S instance is an lvm partition,
> e.g. /dev/vg01/lv_guest
> > To allow it, you need to use the interface for it, e.g. 
> > storage_raw_read_fixed_disk(xm_t) That interface is defined in
> > kernel/storage.if. In addition to allowing the permission, it adds a
> > type attribute to the type that excludes from the assertion.
>
> So, what would that look like in the policy file?

If you build using the devel makefile (e.g. make
-f /usr/share/selinux/devel/Makefile or copy it over to where you are
working on your module), then you can use the interface as I described,
i.e. just put
    storage_raw_read_fixed_disk(xm_t)
in your .te file.

That Makefile will pull in the headers and expand it properly.
Should handle the checkmodule and semodule_package side of things,
leaving you with just running semodule -i to install it once built.

[Robin Bowes]

Stephen Smalley wrote:
> On Fri, 2006-10-13 at 17:12 +0100, Robin Bowes wrote:
> > Stephen Smalley wrote:
> > > The assertion is to prevent accidental granting of read access to a
> > > raw disk device.  Is that truly required here?
> >
> > Probably - the root disk of the guest O/S instance is an lvm partition,
> > e.g. /dev/vg01/lv_guest
> > > To allow it, you need to use the interface for it, e.g. 
> > > storage_raw_read_fixed_disk(xm_t) That interface is defined in
> > > kernel/storage.if. In addition to allowing the permission, it adds a
> > > type attribute to the type that excludes from the assertion.
> >
> > So, what would that look like in the policy file?
>
> If you build using the devel makefile (e.g. make
> -f /usr/share/selinux/devel/Makefile or copy it over to where you are
> working on your module), then you can use the interface as I described,
> i.e. just put
>    storage_raw_read_fixed_disk(xm_t)
> in your .te file.
>
> That Makefile will pull in the headers and expand it properly.
> Should handle the checkmodule and semodule_package side of things,
> leaving you with just running semodule -i to install it once built.

I'm actually doing this:

Use audit2allow to identify AVC denied msgs:

audit2allow -M local -l -i /var/log/audit/audit.log

Copy the contents of the local.te file produced by the command to xen.te

Compile and install the policy like this:

export SEAPP=xen
checkmodule -M -m -o ${SEAPP}.mod ${SEAPP}.te
semodule_package -o ${SEAPP}.pp -m ${SEAPP}.mod
semodule -i ${SEAPP}.pp

Will "storage_raw_read_fixed_disk(xm_t)" fit into the class/type/role
format used in the .te files? Or do I need to do something different?

Thanks for your help with this.

R.

[Stephen Smalley]

On Fri, 2006-10-13 at 17:25 +0100, Robin Bowes wrote:
> Stephen Smalley wrote:
> > On Fri, 2006-10-13 at 17:12 +0100, Robin Bowes wrote:
> > > Stephen Smalley wrote:
> > > > The assertion is to prevent accidental granting of read access to a
> > > > raw disk device.  Is that truly required here?
> > >
> > > Probably - the root disk of the guest O/S instance is an lvm partition,
> > > e.g. /dev/vg01/lv_guest
> > > > To allow it, you need to use the interface for it, e.g. 
> > > > storage_raw_read_fixed_disk(xm_t) That interface is defined in
> > > > kernel/storage.if. In addition to allowing the permission, it adds a
> > > > type attribute to the type that excludes from the assertion.
> > >
> > > So, what would that look like in the policy file?
> >
> > If you build using the devel makefile (e.g. make
> > -f /usr/share/selinux/devel/Makefile or copy it over to where you are
> > working on your module), then you can use the interface as I described,
> > i.e. just put
> >    storage_raw_read_fixed_disk(xm_t)
> > in your .te file.
> >
> > That Makefile will pull in the headers and expand it properly.
> > Should handle the checkmodule and semodule_package side of things,
> > leaving you with just running semodule -i to install it once built.
>
> I'm actually doing this:
>
> Use audit2allow to identify AVC denied msgs:
>
> audit2allow -M local -l -i /var/log/audit/audit.log
>
> Copy the contents of the local.te file produced by the command to xen.te
>
> Compile and install the policy like this:
>
> export SEAPP=xen
> checkmodule -M -m -o ${SEAPP}.mod ${SEAPP}.te
> semodule_package -o ${SEAPP}.pp -m ${SEAPP}.mod
> semodule -i ${SEAPP}.pp
>
> Will "storage_raw_read_fixed_disk(xm_t)" fit into the class/type/role
> format used in the .te files? Or do I need to do something different?

You need to do something different if you want to use refpolicy
interfaces (which are presently m4 macros, but will eventually be first
class constructs in the language that will be handled at link time);
storage_raw_read_fixed_disk() is such an interface.  The easiest thing
to do is to use the devel Makefile.  Instead of manually running
checkmodule and semodule_package, you just do:
    mkdir xen
    cp xen.te xen/
    cd xen
    make -f /usr/share/selinux/devel/Makefile

The Makefile will then handle pulling in the refpolicy interface
headers, applying m4, running checkmodule on the result, and running
semodule_package, leaving you with a xen.pp file that you can install.

[Robin Bowes]

Stephen Smalley wrote:
> You need to do something different if you want to use refpolicy
> interfaces (which are presently m4 macros, but will eventually be first
> class constructs in the language that will be handled at link time);
> storage_raw_read_fixed_disk() is such an interface.  The easiest thing
> to do is to use the devel Makefile.  Instead of manually running
> checkmodule and semodule_package, you just do:
>    mkdir xen
>    cp xen.te xen/
>    cd xen
>    make -f /usr/share/selinux/devel/Makefile
>
> The Makefile will then handle pulling in the refpolicy interface
> headers, applying m4, running checkmodule on the result, and running
> semodule_package, leaving you with a xen.pp file that you can install.

Ok, I followed those instructions using the following .te file:

module local 1.0;

require {
        class blk_file read;
        class chr_file { read write };
        class dir { add_name create search setattr write };
        class fd use;
        class file { append create read write };
        class unix_stream_socket { read write };
        type fixed_disk_device_t;
        type home_root_t;
        type ifconfig_t;
        type local_login_t;
        type netutils_t;
        type proc_xen_t;
        type tmp_t;
        type tty_device_t;
        type user_home_dir_t;
        type user_home_t;
        type var_log_t;
        type var_run_t;
        type xend_t;
        type xend_var_log_t;
        type xm_t;
        role system_r;
};

allow ifconfig_t var_log_t:file append;
allow netutils_t proc_xen_t:file { read write };
allow netutils_t xend_t:unix_stream_socket { read write };
allow netutils_t xend_var_log_t:file { append write };
allow xend_t home_root_t:dir { search write };
allow xend_t local_login_t:fd use;
allow xend_t tmp_t:dir search;
allow xend_t tty_device_t:chr_file { read write };
allow xend_t user_home_dir_t:dir { search write };
allow xend_t user_home_t:dir { add_name search write };
allow xend_t user_home_t:file { create write };
allow xend_t var_run_t:dir { create setattr };
allow xm_t fixed_disk_device_t:blk_file read;

When I tried to install the module, I got this error:

# semodule -i xen.pp
libsepol.check_assertion_helper: assertion on line 0 violated by allow
xm_t fixed_disk_device_t:blk_file { read };
libsepol.check_assertions: 1 assertion violations occured
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!

What am I doing wrong?

Thanks,

R.

[Stephen Smalley]

On Fri, 2006-10-13 at 19:51 +0100, Robin Bowes wrote:
> Stephen Smalley wrote:
> > You need to do something different if you want to use refpolicy
> > interfaces (which are presently m4 macros, but will eventually be first
> > class constructs in the language that will be handled at link time);
> > storage_raw_read_fixed_disk() is such an interface.  The easiest thing
> > to do is to use the devel Makefile.  Instead of manually running
> > checkmodule and semodule_package, you just do:
> >    mkdir xen
> >    cp xen.te xen/
> >    cd xen
> >    make -f /usr/share/selinux/devel/Makefile
> >
> > The Makefile will then handle pulling in the refpolicy interface
> > headers, applying m4, running checkmodule on the result, and running
> > semodule_package, leaving you with a xen.pp file that you can install.
>
> Ok, I followed those instructions using the following .te file:
>
> module local 1.0;
>
> require {
>         class blk_file read;
>         class chr_file { read write };
>         class dir { add_name create search setattr write };
>         class fd use;
>         class file { append create read write };
>         class unix_stream_socket { read write };
>         type fixed_disk_device_t;
>         type home_root_t;
>         type ifconfig_t;
>         type local_login_t;
>         type netutils_t;
>         type proc_xen_t;
>         type tmp_t;
>         type tty_device_t;
>         type user_home_dir_t;
>         type user_home_t;
>         type var_log_t;
>         type var_run_t;
>         type xend_t;
>         type xend_var_log_t;
>         type xm_t;
>         role system_r;
> };
>
> allow ifconfig_t var_log_t:file append;
> allow netutils_t proc_xen_t:file { read write };
> allow netutils_t xend_t:unix_stream_socket { read write };
> allow netutils_t xend_var_log_t:file { append write };
> allow xend_t home_root_t:dir { search write };
> allow xend_t local_login_t:fd use;
> allow xend_t tmp_t:dir search;
> allow xend_t tty_device_t:chr_file { read write };
> allow xend_t user_home_dir_t:dir { search write };
> allow xend_t user_home_t:dir { add_name search write };
> allow xend_t user_home_t:file { create write };
> allow xend_t var_run_t:dir { create setattr };
> allow xm_t fixed_disk_device_t:blk_file read;
>
> When I tried to install the module, I got this error:
>
> # semodule -i xen.pp
> libsepol.check_assertion_helper: assertion on line 0 violated by allow
> xm_t fixed_disk_device_t:blk_file { read };
> libsepol.check_assertions: 1 assertion violations occured
> libsemanage.semanage_expand_sandbox: Expand module failed
> semodule:  Failed!
>
> What am I doing wrong?
> From the above, you are still directly allowing read access to a fixed

disk device rather than using the storage_raw_read_fixed_disk()
interface.  IOW, replace your 'allow xm_t fixed_disk_device_t:blk_file
read;' statement with:
    storage_raw_read_fixed_disk(xm_t)

That was the point of switching to using the devel Makefile, so that you
could use the above interface.  Which already expands to the necessary
declarations and rules to allow the access without violating the
assertion/neverallow rule.

There isn't anything magic here; it is just that
storage_raw_read_fixed_disk() as defined
in /usr/share/selinux/devel/include/kernel/storage.if already expands to
the right set of rules, and by using it, you insulate yourself from the
policy details that might change over time or between systems.  Same
thing applies to all of your rules; if there is already an interface for
that purpose, you are better off using it.

[Robin Bowes]

Stephen Smalley wrote:
> On Fri, 2006-10-13 at 19:51 +0100, Robin Bowes wrote:
> > allow xm_t fixed_disk_device_t:blk_file read;
> > From the above, you are still directly allowing read access to a fixed
>
> disk device rather than using the storage_raw_read_fixed_disk()
> interface.  IOW, replace your 'allow xm_t fixed_disk_device_t:blk_file
> read;' statement with:
>    storage_raw_read_fixed_disk(xm_t)

Ah, right. That was what I was missing.

I removed that line and ran the make and got these errors:

]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted xen module
/usr/bin/checkmodule:  loading policy configuration from tmp/xen.tmp
xen.te:40:ERROR 'permission read is not defined for class dir' at token
';' on line 59080:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 40
xen.te:40:ERROR 'permission getattr is not defined for class dir' at
token ';' on line 59080:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 40
xen.te:40:ERROR 'permission lock is not defined for class dir' at token
';' on line 59080:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 40
xen.te:40:ERROR 'permission ioctl is not defined for class dir' at token
';' on line 59080:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 40
xen.te:40:ERROR 'unknown class lnk_file used in rule' at token ';' on
line 59082:
        allow xm_t device_t:lnk_file { getattr read };
#line 40
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/xen.mod] Error 1

So, I removed all the lines I put in relating to the raw read. My xen.te
now looks like this:

module local 1.0;

require {
        class chr_file { read write };
        class dir { add_name create search setattr write };
        class fd use;
        class file { append create read write };
        class unix_stream_socket { read write };
        type home_root_t;
        type ifconfig_t;
        type local_login_t;
        type netutils_t;
        type proc_xen_t;
        type tmp_t;
        type tty_device_t;
        type user_home_dir_t;
        type user_home_t;
        type var_log_t;
        type var_run_t;
        type xend_t;
        type xend_var_log_t;
        role system_r;
};

allow ifconfig_t var_log_t:file append;
allow netutils_t proc_xen_t:file { read write };
allow netutils_t xend_t:unix_stream_socket { read write };
allow netutils_t xend_var_log_t:file { append write };
allow xend_t home_root_t:dir { search write };
allow xend_t local_login_t:fd use;
allow xend_t tmp_t:dir search;
allow xend_t tty_device_t:chr_file { read write };
allow xend_t user_home_dir_t:dir { search write };
allow xend_t user_home_t:dir { add_name search write };
allow xend_t user_home_t:file { create write };
allow xend_t var_run_t:dir { create setattr };
storage_raw_read_fixed_disk(xm_t)

Running the make produces this error:

# make -f /usr/share/selinux/devel/Makefile
Compiling targeted xen module
/usr/bin/checkmodule:  loading policy configuration from tmp/xen.tmp
xen.te:37:ERROR 'unknown type xm_t' at token ';' on line 59091:
#line 37
        typeattribute xm_t fixed_disk_raw_read;
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/xen.mod] Error 1

I tried putting back "type xm_t" but get these errors:

# make -f /usr/share/selinux/devel/Makefile
Compiling targeted xen module
/usr/bin/checkmodule:  loading policy configuration from tmp/xen.tmp
xen.te:38:ERROR 'permission read is not defined for class dir' at token
';' on line 59078:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 38
xen.te:38:ERROR 'permission getattr is not defined for class dir' at
token ';' on line 59078:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 38
xen.te:38:ERROR 'permission lock is not defined for class dir' at token
';' on line 59078:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 38
xen.te:38:ERROR 'permission ioctl is not defined for class dir' at token
';' on line 59078:
        allow xm_t device_t:dir { read getattr lock search ioctl };
#line 38
xen.te:38:ERROR 'unknown class lnk_file used in rule' at token ';' on
line 59080:
        allow xm_t device_t:lnk_file { getattr read };
#line 38
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/xen.mod] Error 1

I found I had to add all the missing classes and permissions.

This version of xen.te builds and installs cleanly:

module local 1.0;

require {
        class blk_file { read getattr lock ioctl };
        class chr_file { read write };
        class dir { add_name create search setattr write read getattr
lock ioctl };
        class fd use;
        class file { append create read write };
        class lnk_file { getattr read };
        class unix_stream_socket { read write };
        type home_root_t;
        type ifconfig_t;
        type local_login_t;
        type netutils_t;
        type proc_xen_t;
        type tmp_t;
        type tty_device_t;
        type user_home_dir_t;
        type user_home_t;
        type var_log_t;
        type var_run_t;
        type xend_t;
        type xend_var_log_t;
        type xm_t;
        role system_r;
};

allow ifconfig_t var_log_t:file append;
allow netutils_t proc_xen_t:file { read write };
allow netutils_t xend_t:unix_stream_socket { read write };
allow netutils_t xend_var_log_t:file { append write };
allow xend_t home_root_t:dir { search write };
allow xend_t local_login_t:fd use;
allow xend_t tmp_t:dir search;
allow xend_t tty_device_t:chr_file { read write };
allow xend_t user_home_dir_t:dir { search write };
allow xend_t user_home_t:dir { add_name search write };
allow xend_t user_home_t:file { create write };
allow xend_t var_run_t:dir { create setattr };
storage_raw_read_fixed_disk(xm_t)
> That was the point of switching to using the devel Makefile, so that you
> could use the above interface.  Which already expands to the necessary
> declarations and rules to allow the access without violating the
> assertion/neverallow rule.
>
> There isn't anything magic here; it is just that
> storage_raw_read_fixed_disk() as defined
> in /usr/share/selinux/devel/include/kernel/storage.if already expands to
> the right set of rules, and by using it, you insulate yourself from the
> policy details that might change over time or between systems.  Same
> thing applies to all of your rules; if there is already an interface for
> that purpose, you are better off using it.

So, how do I find out more about this? How would I know that interfaces
like storage_raw_read_fixed_disk(xm_t) exist, and what they mean?

Thanks for all your help,

R.

[Stephen Smalley]

On Fri, 2006-10-13 at 20:31 +0100, Robin Bowes wrote:
> Stephen Smalley wrote:
> > On Fri, 2006-10-13 at 19:51 +0100, Robin Bowes wrote:
> > > allow xm_t fixed_disk_device_t:blk_file read;
> > > From the above, you are still directly allowing read access to a fixed
> >
> > disk device rather than using the storage_raw_read_fixed_disk()
> > interface.  IOW, replace your 'allow xm_t fixed_disk_device_t:blk_file
> > read;' statement with:
> >    storage_raw_read_fixed_disk(xm_t)
>
> Ah, right. That was what I was missing.
>
> I removed that line and ran the make and got these errors:

<snip>
> I found I had to add all the missing classes and permissions.

Or, alternatively, replace:
    module local 1.0;
with the standard module prologue:
    policy_module(local, 1.0)

This brings in the class/permission requires automatically.
> This version of xen.te builds and installs cleanly:

<snip>
> So, how do I find out more about this? How would I know that interfaces
> like storage_raw_read_fixed_disk(xm_t) exist, and what they mean?

Interface documentation is
under /usr/share/doc/selinux-policy-x.y.z/html/index.html.

/usr/share/selinux/devel/policyhelp is a trivial one-line script to
launch a browser on it.

Also available at:
http://oss.tresys.com/docs/refpolicy/api/

An IDE is under development.  Available from:
http://oss.tresys.com/projects/slide

[David Caplan]

> On Fri, 2006-10-13 at 17:25 +0100, Robin Bowes wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2006-10-13 at 17:12 +0100, Robin Bowes wrote:
> > > > Stephen Smalley wrote:
> > > > > The assertion is to prevent accidental granting of read
>
> access to
> > > > > a raw disk device.  Is that truly required here?
> > > >
> > > > Probably - the root disk of the guest O/S instance is an lvm 
> > > > partition, e.g. /dev/vg01/lv_guest
> > > > > To allow it, you need to use the interface for it, e.g. 
> > > > > storage_raw_read_fixed_disk(xm_t) That interface is defined in 
> > > > > kernel/storage.if. In addition to allowing the
>
> permission, it adds
> > > > > a type attribute to the type that excludes from the assertion.

It seems like you'd want to consider a specific xen label for your guest
partitions. You probably don't want to give xm_t access to all of the
disks/partitions. Generally when you violate assertions you're probably
allowing access you don't want (or should at least think hard about). Of
course that will be a little more involved and it's probably better to
get things working first with the storage_raw_read_fixed_disk()
interface.

I've had no luck with getting xen even to boot correctly (using the same
versions you listed on FC5). It always hangs when it checks the hardware
on boot and if I skip that step with an interactive boot my system gets
corrupted. I'm using a vanilla Dell hardware base (works fine with the
standard FC5 kernel install). Did you have any problems getting the
initial system set up? I have tried installing and booting in permissive
mode with the same results.

David
--
__________________________________

David Caplan    
[e-mail]
Tresys Technology, LLC

[Robin Bowes]

David Caplan wrote:
> > On Fri, 2006-10-13 at 17:25 +0100, Robin Bowes wrote:
> > > Stephen Smalley wrote:
> > > > On Fri, 2006-10-13 at 17:12 +0100, Robin Bowes wrote:
> > > > > Stephen Smalley wrote:
> > > > > > The assertion is to prevent accidental granting of read
> >
> > access to
> > > > > > a raw disk device.  Is that truly required here?
> > > > >
> > > > > Probably - the root disk of the guest O/S instance is an lvm 
> > > > > partition, e.g. /dev/vg01/lv_guest
> > > > > > To allow it, you need to use the interface for it, e.g. 
> > > > > > storage_raw_read_fixed_disk(xm_t) That interface is defined in 
> > > > > > kernel/storage.if. In addition to allowing the
> >
> > permission, it adds
> > > > > > a type attribute to the type that excludes from the assertion.
>
> It seems like you'd want to consider a specific xen label for your guest
> partitions. You probably don't want to give xm_t access to all of the
> disks/partitions. Generally when you violate assertions you're probably
> allowing access you don't want (or should at least think hard about). Of
> course that will be a little more involved and it's probably better to
> get things working first with the storage_raw_read_fixed_disk()
> interface.

I have a lot to learn about SELinux. I've been managing to make things
work by creating local policies, but I've always had in my mind the
thought that there must be other/better ways to do it.
> I've had no luck with getting xen even to boot correctly (using the same
> versions you listed on FC5). It always hangs when it checks the hardware
> on boot and if I skip that step with an interactive boot my system gets
> corrupted. I'm using a vanilla Dell hardware base (works fine with the
> standard FC5 kernel install). Did you have any problems getting the
> initial system set up? I have tried installing and booting in permissive
> mode with the same results.

I had no problems at all apart from the SELinux stuff.

Here's what I did:

- FC5 kickstart install.
 - yum update
 - installed kernel-xen0 + rebooted
 - created lv for guest domain
 - installed guest domain using this command line:

xenguest-install.py --name=guest --file=/dev/vg01/lv_guest_vm --ram=512
--location=http://mirrors.kernel.org/fedora/core/5/i386/os/
--extra-args="ip=192.168.23.228 netmask=255.255.255.248
gateway=192.168.23.225 dns=192.168.2.203,192.168.2.204
ks=http://example.com/kickstart/ks_guest.cfg"

- copied xendomains script from Redhat somewhere (see my first post in
this thread).

R.