1:32 p.m.
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/
8:40 a.m.
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
9:01 a.m.
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
9:07 a.m.
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
9:13 a.m.
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)
9:24 a.m.
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
9:36 a.m.
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.
9:30 a.m.
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
1:30 p.m.
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.
1:41 p.m.
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.
2:04 p.m.
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
4:22 a.m.
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
4:31 a.m.
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
4:50 a.m.
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
4:41 a.m.
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 :|
5:06 a.m.
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
8:53 a.m.
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?
1:25 p.m.
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 }'
2:42 p.m.
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
3:37 p.m.
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.
5614
days inactive
5616
days old
19 comments
5 participants
participants (5)
-
Daniel J Walsh -
Daniel P. Berrange -
Eric Paris -
Matthew Booth -
Richard W.M. Jones