Re: Containing vmware player 2.0.0 with SELINUX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Louis Lam wrote:
Hi All,

I managed to get the vmware host services e.g. vmnet-bridge, vmnet-dhcpd etc... to be running in
vmware_host_t domain. I did it by modifying the net-services.sh as described in an earlier post.

Next I tried to get vmplayer (i'm using vmware player 2.0.0 but it is similar for vmware ws 6) to
run in vmware_t domain. First i tried to chcon /usr/bin/vmplayer to
system_u:object_r:vmware_exec_t. But it turns out that /usr/bin/vmplayer is a script that would in
turn execute /usr/lib/vmware/bin/vmplayer. I have chcon /usr/lib/vmware/bin/vmplayer to
system_u:object_r:vmware_exec_t but still it runs in unconfined_t when i launched it. I seems like
the domain transition didn't take place. Please help.

1. What should be the context for the /usr/bin/vmplayer script? Does it affect the transition of
the actual executable /usr/lib/vmware/bin/vmplayer?

2. For those who could get vmware workstation 6 to run how did you get it to run in vmware_t
domain?
There is currently no transition from unconfined_t to vmware_t. So the only way to get the transition to happen is through the initrc script. You could label the vmplayer script initrc_exec_t and the transitions should happen properly.
THanks,
Louis

--- Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:

Ken YANG wrote:
Daniel J Walsh wrote:
Louis Lam wrote:
Hi all,

At this point i'm still trying to use SELINUX to "contain" vmware
player, making it run in
targeted mode.

I'm still rather new to this but through the help of Ken, i've been
able to manipulate modules and
get it to "affect" the vmware player but at this point my vmware
player is still "broken".
Would anyone be able to share their configurations (.te,.fc,.if) file
if you've managed to get it
to work with vmware player or vmware-workstation 6 ? CUrrently i'm
working with Fedora 7 but
intend to port it back to RHEL 5.

I've downloaded the latest reference policy from oss and examined the
vmware relevant files. From
examining the vmware.fc  and
"/etc/selinux/targeted/modules/active/file_context", seems like the
vmware.fc file could have been written for an older/different version
of vmware where the vmnet
devices are at /dev/vmnet.* instead of /dev/vmnet* found in vmplayer
2/workstation 6. Which
version was it written for?

There is vmware policy that we are starting to use in Rawhide (fc8)
I went on to modify the vmware.fc file and managed to compile and load
the vmware.pp module. But
currently this affected the vmware services at startup, e.g.
vmnet-dhcpd. For vmware, when
something fails to start, it would ask me to rum vmware-config.pl
again when i restart it. Doing
this would recreate the /dev/vmnet* files over again but it will not
have the right context,
defaulting to "device_t" instead of "vmware_device_t" that i have
modified. The line in my
vmware.fc looks like this:

/dev/vmnet0  -- gen_context(system_u:object_r:vmware_device_t,s0)
/dev/vmnet1  -- gen_context(system_u:object_r:vmware_device_t,s0)
/dev/vmnet8  -- gen_context(system_u:object_r:vmware_device_t,s0)

I was thinking that if the script has created a new /dev/vmnet file it
would automatically use the
vmware_device_t context but it didn't. Did i miss out anything?
The problem here is the script is running as initrc_t which has no rules
when creating devices in directories labeled device_t (/dev)  So it uses
the default and labels the devices the same as the directory.  Usually
when we have this situation, we just run restorecon /dev/XYZ after the
creation,
for example

mknod /dev/XYZ
chmod 666 /dev/XYZ
restorecon /dev/XYZ
as tom said, it seemed that it's "$vmdb_answer_LIBDIR"/net-services.sh
who create such devices:

http://marc.info/?l=fedora-selinux-list&m=118407622004161&w=2


i notice "/dev" is tmpfs:

-(:14:45:$)-> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
/dev /dev tmpfs rw 0 0
......

i want to add rules in policy:

type_transition "vmware type" tmpfs_t : chr_file vmware_device_t;

additionally i don't know what type of the net-services.sh, now it is:

... root root user_u:object_r:lib_t   /usr/lib/vmware/net-services.sh


is this method appropriate?




What is the two "--" on the line mean? are they significant?
The -- indicates that this matches only files.

-d directories
-s sock_file
-l link file
-c char_file
...

Second character matches the first character of the ls -l line

ls -l /dev/ttyS0
crw-rw---- 1 root uucp 4, 64 2007-07-11 19:07 /dev/ttyS0

If you have no option specified it would match any file type.

/dev/vmnet0  -- gen_context(system_u:object_r:vmware_device_t,s0)
/dev/vmnet1  -- gen_context(system_u:object_r:vmware_device_t,s0)
/dev/vmnet8  -- gen_context(system_u:object_r:vmware_device_t,s0)


Would match only "Regular files" with this labels.  So you would be
better off with -c (or -b if they are block devices).
Sorry about the long post, any help or advice? Thanks.

Louis
Send instant messages to your online friends
http://uk.messenger.yahoo.com
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

One approach to this would be to label the /etc/init.d/vmware script vmware_initrc_exec_t and then setup the proper transitions.

This is something we are considering for RBAC. For example we want to allow the webadm_t to be able to only restart/execute the httpd script. Currently we have to allow him to execute any initrc script, although we can prevent him from starting other confined domains. A cleaner solution might be to label the script differently and setup another domain for the script to transition to.



Send instant messages to your online friends http://uk.messenger.yahoo.com

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux