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.