From: paul krumviede <pwk@acm.org>
To: "Westerman, Mark" <Mark.Westerman@csoconline.com>,
"'Stephen Smalley'" <sds@tislabs.com>,
Timothy Wood <timothy@hallcomp.com>
Cc: SELinux <SELinux@tycho.nsa.gov>
Subject: Re: Rules for SELinux in a vmware session
Date: Fri, 25 Jan 2002 10:44:45 -0800 [thread overview]
Message-ID: <10470000.1011984285@zfc> (raw)
In-Reply-To: <72222DC86846D411ABD300A0C9EB08A1015242B5@csoc-mail-box.csoconline.com>
[-- 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)
prev parent reply other threads:[~2002-01-25 18:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <72222DC86846D411ABD300A0C9EB08A1015242B5@csoc-mail-box.csoconli ne.com>
2002-01-25 18:16 ` Rules for SELinux in a vmware session Westerman, Mark
2002-01-25 18:44 ` paul krumviede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10470000.1011984285@zfc \
--to=pwk@acm.org \
--cc=Mark.Westerman@csoconline.com \
--cc=SELinux@tycho.nsa.gov \
--cc=sds@tislabs.com \
--cc=timothy@hallcomp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.