-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Paris wrote:
> On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
>> On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis@xxxxxxxxxx> wrote:
>
>>> 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".
>
> I have one that has a 1\n inside the chroot, but I guess that wasn't
> enough? Yes, I think its a fine idea to create such a store vs. host
> check, but in either case they both 'should' have returned MLS=on....
>
>>> 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.
>
> I'll get to no /selinux in a second
>
>>> 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 doubt we do any mounting inside the chroot do we? Missing transition
> from livecd-creator program ->mount_t when it does its bind mounts
> inside the chroot would cause this...
>
>>> 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
>>>
>>>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
unconfined_notrans_exec_t was an attempt to remove unconfined
transitions from apps like livecd creator, but have failed miserably.
So I would just change the context to bin_t and use unconfined_t for
running the livecd tools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkgpk0QACgkQrlYvE4MpobPk4ACguXKMnC7uUM9jaqont/bxthSI
ZlYAnRvebyTJ54f9RdSEkjHUZ/I/cwPE
=LiD+
-----END PGP SIGNATURE-----
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
