Rules for SELinux in a vmware session

Rules for SELinux in a vmware session

[Westerman, Mark]

I created the following rule for running selinux in a vmware session.

I currently have a prototype vmware domain for the host OS.


File: policy/domains/program/modutil.te

allow depmod_t etc_runtime_t:lnk_file r_file_perms;

File: policy/domains/system/initrc.te
# Read conf.modules.
# Added lnk_file for vmware session
allow initrc_t modules_conf_t:{ file lnk_file } r_file_perms;

File: policy/domains/system/kmod.te
# Read conf.modules.
# Additions for vmware session
allow kmod_t modules_conf_t:{ file lnk_file } r_file_perms;
allow kmod_t etc_runtime_t:lnk_file { read };

File: setfiles/file_contexts
# Added for vmware session
/etc/modules.conf(|.*)          system_u:object_r:modules_conf_t


--
You have received this message because you are subscribed to the selinux 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: Rules for SELinux in a vmware session

[paul krumviede]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]



--On Friday, January 25, 2002 12:16:59 PM -0600 "Westerman, Mark" 
<Mark.Westerman@csoconline.com> wrote:

>
>
> I created the following rule for running selinux in a vmware session.
>
> I currently have a prototype vmware domain for the host OS.

i created something a bit more complex. i also attempted to make
the policy file relatively self-contained (for example, the attached
file adds the vmware_guestd_t type to the system_r role, rather than
having to add it in the rbac file; this may be a matter of taste).
the file is also extensively (excessively?) annotated.

it isn't yet with the newest release (the 2.4.17 kernel one) or on a
redhat 7.2 system; it was done with some of the earlier releases, up
to and including the 2.4.16 kernel one, with VMware 2.04 and 3.0.


> File: setfiles/file_contexts
># Added for vmware session
> /etc/modules.conf(|.*)          system_u:object_r:modules_conf_t

i also added

/etc/vmware-tools/vmware-guestd system_u:object_r:vmware_guestd_exec_t

to setfiles/file_contexts.

-paul

[-- Attachment #2: vmware.te --]
[-- Type: application/octet-stream, Size: 3473 bytes --]

#
# created by paul krumviede (pwk@acm.org)
#
# paul's attempt to make at least some of the vmware stuff work for use
# of linux as a guest OS

#
# rules for the vmware tools daemon
#
# vmware_guestd_t is the domain of the vmware tools guest OS daemon
# vmware_guestd_exec_t is the type of its executable
#
type vmware_guestd_t, domain, privlog;
type vmware_guestd_exec_t, file_type, sysadm_file, exec_type;

type vmware_guestd_var_run_t, file_type, sysadm_file, pidfile;
file_type_auto_trans(vmware_guestd_t, var_run_t, vmware_guestd_var_run_t)

# i don't really know which capabilities is really needs other than
# sys_time (i saw avc denials without it)
allow vmware_guestd_t self:capability {sys_admin sys_time};

# do we really need to inherit and/or use descriptors from init?
allow vmware_guestd_t init_t:fd inherit_fd_perms;

#
# need to do something gross and disgusting to make the module handling
# bits (the kernel module loader, modprobe, and depmod) work: the vmware
# install creates a dualconf init script, which, among other things,
# creates modules.conf as a symlink to modules.conf.{vm,org}
# but this leaves /etc/modules.conf in the etc_runtime_t domain, and
# the module handling stuff can't read the link...
# so we'll try to fix this by letting them read from the etc_runtime_t
# domain, but it might be better to create a dual_conf domain for this...
allow modprobe_t etc_runtime_t:lnk_file r_file_perms;
allow depmod_t etc_runtime_t:lnk_file r_file_perms;
allow kmod_t etc_runtime_t:lnk_file r_file_perms;

# from looking at syslog messages, it seems that insmod also wants
# to read (?) modules.conf, but there doesn't seem to be a rule
# allowing that normally... we'll add the ability to at least
# read the symlink pointing to the appropriate version.
allow insmod_t etc_runtime_t:lnk_file r_file_perms;
allow insmod_t modules_conf_t:lnk_file r_file_perms;

# have a similar problem with dualconf creating /etc/X11/X as a (runtime)
# symlink; allow the X server to read the link...
allow user_xserver_t etc_runtime_t:lnk_file r_file_perms;
allow sysadm_xserver_t etc_runtime_t:lnk_file r_file_perms;
allow user_t etc_runtime_t:lnk_file r_file_perms;

allow depmod_t modules_conf_t:lnk_file r_file_perms;

# note that if one relabels things by running "make relabel"
# then the contexts of /etc/modules.conf and /etc/X11/X
# gets reset from etc_runtime_t (which is how they are set
# when dualconf runs at boot), so we need to be able to
# deal with all that runs before dualconf on a subsequent
# boot
allow initrc_t modules_conf_t:lnk_file r_file_perms;
allow fsadm_t modules_conf_t:lnk_file r_file_perms;
allow initrc_t etc_t:lnk_file link_file_perms;

# let dualconf remove and create the symlinks
# really should create a separate domain for dualconf
allow initrc_t modules_conf_t:lnk_file link_file_perms;

# let users read the symlinks created by dualconf
allow user_t etc_runtime_t:lnk_file r_file_perms;
allow sysadm_t etc_runtime_t:lnk_file r_file_perms;

# let vmware_toolbox connect to the X server
# again, should have a separate domain for this
can_unix_connect(privlog, user_xserver_t)

#
# try to make this a self-contained file, rather than scattering
# things around other files (namely rbac and initrc.te)
#
role system_r types {
	vmware_guestd_t
};
type_transition init_t vmware_guestd_exec_t:process vmware_guestd_t;

# run vmware-guestd in its own domain
domain_auto_trans(initrc_t, vmware_guestd_exec_t, vmware_guestd_t)