Fedora buildsys and SELinux
sds at tycho.nsa.gov
Tue May 13 14:46:42 UTC 2008
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
> 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.
National Security Agency
More information about the fedora-selinux-list