Fedora buildsys and SELinux

[Stephen Smalley]

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