Re: Fedora buildsys and SELinux
On Tue, 2008-05-13 at 10:36 -0400, Eric Paris wrote:
> 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.
But we have other problems without /selinux mounted inside the chroot
(and this is without the rpm_execcon patch which I'm about to put in,
does rpm statically or dynamically link?) :(
Looks like rpm and rpmi are dynamically linked. Don't know if there is
a static version somewhere for bootstrapping.
New, Interesting and different at least:
Installing: selinux-policy ##################### [128/129]
Installing: selinux-policy-targeted ##################### [129/129]
libsemanage.dbase_llist_query: could not query record value
libsepol.policydb_write: policy version 15 cannot support MLS
I assume this is because there isn't an selinux/policyvers?
Yes, but all of this flows from the fact that semodule/libsemanage are
trying to actually load a new policy. Which they wouldn't if we
completely faked that SELinux was disabled within the chroot by making a
fake /proc/filesystems. But allegedly that breaks rpm? Which I don't
fully understand as it should just check whether SELinux is enabled
prior to chroot'ing and keep using that saved enabled status throughout
IMHO. Or if you invoked semodule with -n it wouldn't try to reload.
If all else fails, I suppose you could create a /selinux/policyvers
and /selinux/mls to try to appease it. And maybe still a /dev/null link
as /selinux/load to appease policy load.
libsepol.policydb_to_image: could not compute policy length
libsepol.policydb_to_image: could not create policy image
SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23,
searching for an older version.
SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No
such file or directory
/usr/sbin/load_policy: Can't load policy: No such file or directory
Yes, trying to load policy is the root problem here. So ideally we'd
just disable that altogether as above or failing that fake it as above.
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.
That might just be a bug in the host policy, not allowing something that
ought to be allowed and that only happens to get triggered here.
/sbin/restorecon reset /dev/stderr context
unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/stdin context
unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/random context
unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0
That may make sense given that udev manages device node labels for us
these days. But /dev/stderr is just a symlink to /proc/self/fd/2
anyway, right?
There were actually a whole lot less when the restorecon ran through
(still a bunch but a lot less), so I think that part is better.
After the restorecon finished and before the e2fsck I got:
Only root can do that.
Anyone have ideas what that might have been?
mount would do that if it didn't think it was running as root.
--
Stephen Smalley
National Security Agency