selinux question and answer
This is continuing/summarising a rather long discussion that happened on IRC ... We talked to some SELinux experts about what was required to make SELinux work with libguestfs, and it seems reasonably simple to load the policy from the guest filesystem. All that needs to be done is to mount the guest disks up and then run: sh "/usr/sbin/load_policy -i" That command also mounts up <sysroot>/selinux, so that solves the other problem they raised. I wasn't completely sure how to test this was actually working. My best effort was to try to run some commands that would label files. This is using a fresh Fedora 11 install that has SELinux enforcing on it: guestfish -a /dev/mapper/vg_trick-F11x64 --ro \ run : mount /dev/vg_f11x64/lv_root / : \ sh "/usr/sbin/load_policy -i" : \ sh "ls -lZ /etc/passwd" -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/passwd guestfish -a /dev/mapper/vg_trick-F11x64 --ro \ run : mount /dev/vg_f11x64/lv_root / : \ sh "/usr/sbin/load_policy -i" : \ sh "chcon user_u:object_r:file_t /etc/passwd" : \ sh "ls -lZ /etc/passwd" -rw-r--r--. root root user_u:object_r:file_t /etc/passwd So it seems that relabelling files (using chcon) works. Whether this means everything will work, I don't know. You will also get a warning when guestfish exits at the moment: libguestfs: error: umount: /sysroot: umount: /sysroot: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) This happens because the load_policy command is mounting /sysroot/selinux and thus preventing /sysroot from being unmounted during the automatic shutdown phase at the end. [Note: The attached patch is also required, because at the moment we are booting the kernel with selinux=0 for other reasons. This should be made configurable]. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
After a bit of an epic struggle with a RHEL 5 guest, and thanks to Eric Paris and Dan Walsh, we seem to have hit on a recipe to make SELinux work, we think: (1) The guestfsd daemon (ie. init process) must call setexeccon(3) to set the security context for exec'd children to "unconfined_t". (The daemon itself will still be running as "kernel_t"). (2) We must mount /selinux in the chroot and run /usr/sbin/load_policy inside the chroot. In libguestfs, the commands are: sh "mount -t selinuxfs none /selinux" sh "/usr/sbin/load_policy" (3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command". The reason for this is subtle, but to do with making sure the correct transitions from kernel_t (init) -> unconfined_t (shell) -> whatever rpm uses happen. (4) We also need the patch (see previous email) which removes selinux=0 parameter. Possibly we should use enforcing=0 however. And we think that'll allow us to run rpm and have it label things correctly. There is still a problem that brand new files created by the daemon directly won't have labels. In a real system this is handled by SELinux using inotify to quickly relabel files when they are created [yes, really]. To fix new files (or any file), use sh "restorecon filename". Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code). mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out. On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
After a bit of an epic struggle with a RHEL 5 guest, and thanks to Eric Paris and Dan Walsh, we seem to have hit on a recipe to make SELinux work, we think:
(1) The guestfsd daemon (ie. init process) must call setexeccon(3) to set the security context for exec'd children to "unconfined_t".
This must be done after #2 and must be done by your init daemon, not by a chroot'd shell. I'm not sure exactly how to make this work as libselinux and /selinux is going to be inside the chroot. Maybe you want to staticly link to your own libselinux? (I could probably work out the black magic to cat things directly into /selinux, I think it's easy...)
(3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command".
Correct. There is another (maybe harder?) option. If you want to still be able to run things directly from your daemon you'll need to get the daemon labeled unconfined_t. This would mean calling setexecon() and then re-execing the daemon.
The reason for this is subtle, but to do with making sure the correct transitions from kernel_t (init) -> unconfined_t (shell) -> whatever rpm uses happen.
(4) We also need the patch (see previous email) which removes selinux=0 parameter. Possibly we should use enforcing=0 however.
You will need enforcing=0. Dan just checked and none of our shipping policies would allow the kernel->unconfined transition we want you to use (normal systems all go kernel->init_t->unconfined_t, and you don't want to do all that)
And we think that'll allow us to run rpm and have it label things correctly.
There is still a problem that brand new files created by the daemon directly won't have labels. In a real system this is handled by SELinux using inotify to quickly relabel files when they are created [yes, really].
For only a couple of select key files (see /etc/restorecond*). Normally files inheriting the label of the parent directory and this is correct. As future work instead of hard coding system_u:object_r:unconfined_t:s0 in the setexeccon() call, we should check out what the guest defines as the correct defualt context for the root user. I'm sure dan could walk you through that, but it's a future enhancement, as there very few people who change this. -Eric
On Wed, Aug 12, 2009 at 10:01:39AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
After a bit of an epic struggle with a RHEL 5 guest, and thanks to (3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command".
Correct. There is another (maybe harder?) option. If you want to still be able to run things directly from your daemon you'll need to get the daemon labeled unconfined_t. This would mean calling setexecon() and then re-execing the daemon.
We were just talking about this, and in fact this may be possible for us to do relatively easily. Question: can we use setexeccon before any policy has been loaded? Does it need /selinux? (I'm guessing no, yes).
You will need enforcing=0. Dan just checked and none of our shipping policies would allow the kernel->unconfined transition we want you to use (normal systems all go kernel->init_t->unconfined_t, and you don't want to do all that)
Right, that's no problem.
As future work instead of hard coding system_u:object_r:unconfined_t:s0 in the setexeccon() call, we should check out what the guest defines as the correct defualt context for the root user. I'm sure dan could walk you through that, but it's a future enhancement, as there very few people who change this.
OK, thanks - you've been a great help in helping us to understand all this. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On Wed, 2009-08-12 at 15:07 +0100, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 10:01:39AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
After a bit of an epic struggle with a RHEL 5 guest, and thanks to (3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command".
Correct. There is another (maybe harder?) option. If you want to still be able to run things directly from your daemon you'll need to get the daemon labeled unconfined_t. This would mean calling setexecon() and then re-execing the daemon.
We were just talking about this, and in fact this may be possible for us to do relatively easily.
Question: can we use setexeccon before any policy has been loaded? Does it need /selinux? (I'm guessing no, yes).
Policy must be loaded. /selinux must be mounted somewhere. (libselinux is smart enough to find it even if it isn't mounted at /selinux)
On Wed, Aug 12, 2009 at 10:13:25AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 15:07 +0100, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 10:01:39AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
After a bit of an epic struggle with a RHEL 5 guest, and thanks to (3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command".
Correct. There is another (maybe harder?) option. If you want to still be able to run things directly from your daemon you'll need to get the daemon labeled unconfined_t. This would mean calling setexecon() and then re-execing the daemon.
We were just talking about this, and in fact this may be possible for us to do relatively easily.
Question: can we use setexeccon before any policy has been loaded? Does it need /selinux? (I'm guessing no, yes).
Policy must be loaded. /selinux must be mounted somewhere. (libselinux is smart enough to find it even if it isn't mounted at /selinux)
Matt, I think what we need to do here to make this work: (1) Mount /selinux during *appliance* boot, so it's mounted in the appliance. (2) In the /init script, we can exec the daemon with correct label. It'll have to be "unconfined_t" however, since at this point we won't be able to work out the correct label to use. Hopefully this doesn't matter in any practical situation. (3) Bind-mount /selinux into the guest chroot as we currently do for /proc, /sys etc. (4) Have an API call to load policy once the guest is mounted. The above should mean the daemon is labelled correctly, so most of the API is covered by SELinux. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On Wed, 2009-08-12 at 15:24 +0100, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 10:13:25AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 15:07 +0100, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 10:01:39AM -0400, Eric Paris wrote:
On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
After a bit of an epic struggle with a RHEL 5 guest, and thanks to (3) We must run every external command (eg. "rpm") via the shell, so in libguestfs using "sh", never "command".
Correct. There is another (maybe harder?) option. If you want to still be able to run things directly from your daemon you'll need to get the daemon labeled unconfined_t. This would mean calling setexecon() and then re-execing the daemon.
We were just talking about this, and in fact this may be possible for us to do relatively easily.
Question: can we use setexeccon before any policy has been loaded? Does it need /selinux? (I'm guessing no, yes).
Policy must be loaded. /selinux must be mounted somewhere. (libselinux is smart enough to find it even if it isn't mounted at /selinux)
Matt, I think what we need to do here to make this work:
Sorry, you need to have called load_policy before you can call setexeccon. (1) mount guest chroot (2) mount /selinux inside guest chroot (3) load_policy inside chroot (4) setexeccon() (5) *possible relaunch your init daemon* (6) users can run/do anything they want.
(1) Mount /selinux during *appliance* boot, so it's mounted in the appliance.
(2) In the /init script, we can exec the daemon with correct label.
It'll have to be "unconfined_t" however, since at this point we won't be able to work out the correct label to use. Hopefully this doesn't matter in any practical situation.
(3) Bind-mount /selinux into the guest chroot as we currently do for /proc, /sys etc.
(4) Have an API call to load policy once the guest is mounted.
The above should mean the daemon is labelled correctly, so most of the API is covered by SELinux.
Rich.
On 12/08/09 15:01, Eric Paris wrote:
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code).
mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out.
I've just been running some tests, and on the face of it we don't need to worry about process contexts.
<fs> sh "mount -t selinuxfs none /selinux" <fs> sh "/usr/sbin/load_policy" <fs> sh "id -Z" system_u:system_r:kernel_t:s0
<fs> sh "rpm -ivh /mnt/xorg_x11.rpm" Preparing... ################################################## xorg-x11-xauth ##################################################
<fs> sh "ls -Z /usr/bin/xauth" -rwxr-xr-x root root system_u:object_r:xauth_exec_t:s0 /usr/bin/xauth
So here rpm has installed xorg-x11-xauth, and /usr/bin/xauth has correctly obtained its custom label. Also: * creating a file in a random directory seems to pick up the label of the parent directory. * usermod can change a password without breaking /etc/shadow This covers everything we want to do so far. The guest in this case is RHEL 5. What are we risking if we don't try to be clever with process contexts? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
On 08/12/2009 10:30 AM, Matthew Booth wrote:
On 12/08/09 15:01, Eric Paris wrote:
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code).
mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out.
I've just been running some tests, and on the face of it we don't need to worry about process contexts.
<fs> sh "mount -t selinuxfs none /selinux" <fs> sh "/usr/sbin/load_policy" <fs> sh "id -Z" system_u:system_r:kernel_t:s0
<fs> sh "rpm -ivh /mnt/xorg_x11.rpm" Preparing... ################################################## xorg-x11-xauth ##################################################
<fs> sh "ls -Z /usr/bin/xauth" -rwxr-xr-x root root system_u:object_r:xauth_exec_t:s0 /usr/bin/xauth
So here rpm has installed xorg-x11-xauth, and /usr/bin/xauth has correctly obtained its custom label.
Also: * creating a file in a random directory seems to pick up the label of the parent directory. * usermod can change a password without breaking /etc/shadow
This covers everything we want to do so far. The guest in this case is RHEL 5. What are we risking if we don't try to be clever with process contexts?
Thanks,
Matt Probably very little, since kernel_t is an unconfined domain. (unconfined_t) is also an unconfined domain.
You will loose transitions, But usually this is not a big deal. One example would be the mount command, unconfined_t -> mount_exec_t -> unconfined_mount_t which will end up labeling /etc/mtab correctly. If you are running as kernel_t you will probably end up with /etc/mtab labeled etc_t. Versus etc_runtime_t. But there are very few examples where this is the case.
On 08/12/2009 10:30 AM, Matthew Booth wrote:
On 12/08/09 15:01, Eric Paris wrote:
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code).
mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out.
I've just been running some tests, and on the face of it we don't need to worry about process contexts.
<fs> sh "mount -t selinuxfs none /selinux" <fs> sh "/usr/sbin/load_policy" <fs> sh "id -Z" system_u:system_r:kernel_t:s0
<fs> sh "rpm -ivh /mnt/xorg_x11.rpm" Preparing... ################################################## xorg-x11-xauth ##################################################
<fs> sh "ls -Z /usr/bin/xauth" -rwxr-xr-x root root system_u:object_r:xauth_exec_t:s0 /usr/bin/xauth
So here rpm has installed xorg-x11-xauth, and /usr/bin/xauth has correctly obtained its custom label.
Also: * creating a file in a random directory seems to pick up the label of the parent directory. * usermod can change a password without breaking /etc/shadow
This covers everything we want to do so far. The guest in this case is RHEL 5. What are we risking if we don't try to be clever with process contexts?
Thanks,
Matt I think executing
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0") RHEL5 setcon("user_u:system_r:unconfined_t:s0") Would be valid, then you do not need to worry about executing a shell.
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all? https://www.redhat.com/archives/libguestfs/2009-August/msg00186.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
On 12/08/09 20:04, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all?
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it. I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got: 1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0 3. system_u:object_r:unconfined_t:s0 sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
On Thu, Aug 13, 2009 at 10:22:03AM +0100, Matthew Booth wrote:
On 12/08/09 20:04, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all?
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it.
I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got:
1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0 3. system_u:object_r:unconfined_t:s0
sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS?
I'm not even sure what "MLS" is. Anyway, isn't there a way to get this from the /etc/selinux configuration of the guest? For example on a Fedora 10 machine I see: $ cat /etc/selinux/targeted/contexts/default_type auditadm_r:auditadm_t secadm_r:secadm_t sysadm_r:sysadm_t staff_r:staff_t unconfined_r:unconfined_t user_r:user_t $ cat /etc/selinux/targeted/contexts/default_contexts system_r:crond_t:s0 system_r:system_crond_t:s0 system_r:local_login_t:s0 user_r:user_t:s0 system_r:remote_login_t:s0 user_r:user_t:s0 system_r:sshd_t:s0 user_r:user_t:s0 system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0 system_r:xdm_t:s0 user_r:user_t:s0 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On 13/08/09 10:31, Richard W.M. Jones wrote:
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it.
I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got:
1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0 3. system_u:object_r:unconfined_t:s0
sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS?
I'm not even sure what "MLS" is.
Anyway, isn't there a way to get this from the /etc/selinux configuration of the guest? For example on a Fedora 10 machine I see:
$ cat /etc/selinux/targeted/contexts/default_type auditadm_r:auditadm_t secadm_r:secadm_t sysadm_r:sysadm_t staff_r:staff_t unconfined_r:unconfined_t user_r:user_t
$ cat /etc/selinux/targeted/contexts/default_contexts system_r:crond_t:s0 system_r:system_crond_t:s0 system_r:local_login_t:s0 user_r:user_t:s0 system_r:remote_login_t:s0 user_r:user_t:s0 system_r:sshd_t:s0 user_r:user_t:s0 system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0 system_r:xdm_t:s0 user_r:user_t:s0
I just looked at the contents of these files for the minimum and mls policies on F11, and they're all (nearly) identical. I'm not sure we can use these to distinguish. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
On Thu, Aug 13, 2009 at 10:22:03AM +0100, Matthew Booth wrote:
On 12/08/09 20:04, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all?
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it.
I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got:
1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0 3. system_u:object_r:unconfined_t:s0
sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS?
Could you discover the neccessary/supported targets from the semanage, eg # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root user s0 SystemLow-SystemHigh system_r sysadm_r user_r system_u user s0 SystemLow-SystemHigh system_r user_u user s0 SystemLow-SystemHigh system_r sysadm_r user_r Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Aug 13, 2009 at 10:41:57AM +0100, Daniel P. Berrange wrote:
Could you discover the neccessary/supported targets from the semanage,
eg
# semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles
root user s0 SystemLow-SystemHigh system_r sysadm_r user_r system_u user s0 SystemLow-SystemHigh system_r user_u user s0 SystemLow-SystemHigh system_r sysadm_r user_r
This is what semanage says when run inside libguestfs: $ ./fish/guestfish -a /dev/mapper/vg_trick-F11x64 --ro \ selinux on : \ run : \ mount /dev/vg_f11x64/lv_root / : \ sh "/usr/sbin/load_policy" : \ sh "/usr/sbin/semanage user -l" Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u user s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r I guess we should wait until Dan Walsh / Eric Paris are awake and can comment on what we *should* be doing. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
On Thu, 2009-08-13 at 10:22 +0100, Matthew Booth wrote:
On 12/08/09 20:04, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all?
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it.
I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got:
1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0
3. sysadm_u:sysadm_r:sysadm_t:s0
4. system_u:object_r:unconfined_t:s0
5. system_u:object_r:sysadm_t:s0
sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS?
On 08/13/2009 09:53 AM, Eric Paris wrote:
On Thu, 2009-08-13 at 10:22 +0100, Matthew Booth wrote:
On 12/08/09 20:04, Richard W.M. Jones wrote:
On Wed, Aug 12, 2009 at 02:41:16PM -0400, Daniel J Walsh wrote:
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
Would be valid, then you do not need to worry about executing a shell.
Matt maybe we want this patch after all?
Ok. We have a use case (/etc/mtab) which would be broken without this. I'd go ahead and add it.
I'm inclined to try setcon to an ordered list of targets, stopping when one works. So far, I think we've got:
1. unconfined_u:unconfined_r:unconfined_t:s0 2. user_u:system_r:unconfined_t:s0
3. sysadm_u:sysadm_r:sysadm_t:s0
4. system_u:object_r:unconfined_t:s0
5. system_u:object_r:sysadm_t:s0
sysadm_t was mentioned on our call yesterday as being the root login domain for an MLS policy. What's a good set for MLS?
Change all of the s0 with chroot semanage login -l | awk '/root/ { print $3 }'
On Wed, 2009-08-12 at 14:41 -0400, Daniel J Walsh wrote:
On 08/12/2009 10:30 AM, Matthew Booth wrote:
On 12/08/09 15:01, Eric Paris wrote:
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code).
mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out.
I've just been running some tests, and on the face of it we don't need to worry about process contexts.
<fs> sh "mount -t selinuxfs none /selinux" <fs> sh "/usr/sbin/load_policy" <fs> sh "id -Z" system_u:system_r:kernel_t:s0
<fs> sh "rpm -ivh /mnt/xorg_x11.rpm" Preparing... ################################################## xorg-x11-xauth ##################################################
<fs> sh "ls -Z /usr/bin/xauth" -rwxr-xr-x root root system_u:object_r:xauth_exec_t:s0 /usr/bin/xauth
So here rpm has installed xorg-x11-xauth, and /usr/bin/xauth has correctly obtained its custom label.
Also: * creating a file in a random directory seems to pick up the label of the parent directory. * usermod can change a password without breaking /etc/shadow
This covers everything we want to do so far. The guest in this case is RHEL 5. What are we risking if we don't try to be clever with process contexts?
Thanks,
Matt I think executing
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
wouldn't "system_u:object_r:unconfined_t:s0" work just as well and it would work RHEL4-rawhide? No need to know anything about the guest? object_r having that black magic noone seems to talk about.... -Eric
On 08/12/2009 03:42 PM, Eric Paris wrote:
On Wed, 2009-08-12 at 14:41 -0400, Daniel J Walsh wrote:
On 08/12/2009 10:30 AM, Matthew Booth wrote:
On 12/08/09 15:01, Eric Paris wrote:
setexecon() takes an selinux context and then anything you exec after the call will be run in the given domain. So we suggest calling (pseudo code).
mount /selinux call load_policy call setexeccon(unconfined_t) do everything in a shell from here on out.
I've just been running some tests, and on the face of it we don't need to worry about process contexts.
<fs> sh "mount -t selinuxfs none /selinux" <fs> sh "/usr/sbin/load_policy" <fs> sh "id -Z" system_u:system_r:kernel_t:s0
<fs> sh "rpm -ivh /mnt/xorg_x11.rpm" Preparing... ################################################## xorg-x11-xauth ##################################################
<fs> sh "ls -Z /usr/bin/xauth" -rwxr-xr-x root root system_u:object_r:xauth_exec_t:s0 /usr/bin/xauth
So here rpm has installed xorg-x11-xauth, and /usr/bin/xauth has correctly obtained its custom label.
Also: * creating a file in a random directory seems to pick up the label of the parent directory. * usermod can change a password without breaking /etc/shadow
This covers everything we want to do so far. The guest in this case is RHEL 5. What are we risking if we don't try to be clever with process contexts?
Thanks,
Matt I think executing
F11, F12, F..., RHEL6 ... setcon("unconfined_u:unconfined_r:unconfined_t:s0")
RHEL5 setcon("user_u:system_r:unconfined_t:s0")
wouldn't "system_u:object_r:unconfined_t:s0" work just as well and it would work RHEL4-rawhide? No need to know anything about the guest?
object_r having that black magic noone seems to talk about....
-Eric
You could try it out.
participants (5)
-
Daniel J Walsh -
Daniel P. Berrange -
Eric Paris -
Matthew Booth -
Richard W.M. Jones