On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis(a)redhat.com> wrote:
On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
> On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj(a)redhat.com> wrote:
> The only problem I see with not having selinuxfs mounted at all within
> the chroot or even providing fake /selinux nodes is that rpm_execcon()
> will then see SELinux as disabled and thus not try to run the
> scriptlet in a different domain;
How does it do this check? Guess I should pull some rpm sources. My
lord I don't wanna....
You don't have to look at rpm for that - rpm_execcon() is a helper
function provided by libselinux for use by rpm. I sent you a patch
separately for it that should get it past a missing /selinux/create
node, so you should be able to completely remove /selinux/context and
/selinux/create and still proceed (at least in permissive mode).
> Anyway, I'd be interested in having Eric try the install
with no
> selinuxfs mounted or fake selinux nodes within the chroot and see what
> happens, both in permissive mode and enforcing mode.
I've got my fake selinux mount inside the chroot much like I previously
described. /selinux/create is still getting long strings in it that
don't make much sense. I guess something is using it directly and not
through the libselinux interface?!?!
No, it is just that /selinux/create is a transactional interface that
takes multiple input arguments and returns a single output argument,
so using a regular file for it won't work at all. Just remove it and
use the patch I supplied for rpm_execcon.
enforcing=1 /selinux inside the chroot is the little thing that I made
up to fake it.
I'm not sure you need anything there; as I've said,
is_selinux_enabled() will just fall back to checking /proc/filesystems
for selinuxfs as the authoritative indicator of whether or not SELinux
is enabled.
Installing: selinux-policy ##################### [128/129]
Installing: selinux-policy-targeted ##################### [129/129]
libsemanage.dbase_llist_query: could not query record value
libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for
user guest_u
Hmm...so you are installing a policy with MLS enabled, but tried to
add a user without a MLS level. I think this is likely a
bug/limitation of semanage, where it tries to deduce whether or not to
include the MLS field based on whether the host has MLS enabled.
This has come up before on selinux list; we need a libsemanage
interface for querying whether MLS is enabled in the policy store vs.
on the host. Or you could fake a /selinux/mls node that contains "1".
libsepol.sepol_user_modify: could not load (null) into policy
libsemanage.dbase_policydb_modify: could not modify record value
libsemanage.semanage_base_merge_components: could not merge local modifications into
policy
/usr/sbin/semanage: Could not add SELinux user guest_u
libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for
user xguest_u
libsepol.sepol_user_modify: could not load (null) into policy
libsemanage.dbase_policydb_modify: could not modify record value
libsemanage.semanage_base_merge_components: could not merge local modifications into
policy
/usr/sbin/semanage: Could not add SELinux user xguest_u
ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a
reply. Possible causes include: the remote application did not send a reply, the message
bus security policy blocked the reply, the reply timeout expired, or the network
connection was broken.
/sbin/restorecon reset / context
system_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /bin context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/rvi context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/touch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/mountpoint context
unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0
/sbin/restorecon reset /bin/arch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
and restorecon goes on like this, and on, and on, and on, and on
So no files were labeled properly by rpm? I guess we need someone to
explain how rpm decides whether or not to label files then, as I
thought it just used is_selinux_enabled() and that should return true
as long as /proc/filesystems is available even if selinuxfs is not
mounted within the chroot.
other things of note, restorecond goes nuts fixing up /etc/mtab for a
while, must be some bad/no transition going on when we call mount?
Yes, that would make sense. Not sure what you mean by "goes nuts"
though or why restorecond would be running or looking within the
chroot.
I get no kernel AVC's but I do get:
[root@dhcp231-25 ~]# ausearch -m AVC -m USER_AVC
----
time->Mon May 12 17:19:48 2008
type=USER_AVC msg=audit(1210627188.083:329): user pid=1849 uid=81 auid=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg }
for msgtype=method_return dest=:1.16 spid=2044 tpid=6840
scontext=system_u:system_r:hald_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'
----
time->Mon May 12 17:20:13 2008
type=USER_AVC msg=audit(1210627213.086:330): user pid=1849 uid=81 auid=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg }
for msgtype=method_return dest=:1.16 spid=2044 tpid=6840
scontext=system_u:system_r:hald_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus :
exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'
I've never seen unconfined_notrans_t until I started playing with this
stuff. Dan, what is it?
/me goes to try to build a livecd image with permissive and then with
no /selinux inside the chroot.
-Eric