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_ubject_r:file_t:s0->system_ubject_r:device_t:s0
> /sbin/restorecon reset /dev/stdin context unconfined_ubject_r:file_t:s0->system_ubject_r:device_t:s0
> /sbin/restorecon reset /dev/random context unconfined_ubject_r:file_t:s0->system_ubject_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

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Current Setup:

F9 trying to build an F9 livecd so policy should be happy. I'm trying
to eliminate the illegal file context cruft to start with.

Enforcing.

the label on livecd-creator is bin_t NOT unconfined_notran_t

chroot/selinux contains:
null -> /dev/null
load -> /dev/null
mls -> 1
enforcing -> 1
policyvers -> 22
context -> regular file

libselinux always opens files with O_TRUNC

libselinux rpm_execcon has the patch to return -1 and set con =
context_new(mycon);

the new libselinux is being used inside and outside the chroot

rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires
libeselinux-devel not libselinux-static so I'm hoping we are safe.

******************************

^M Installing: kbd ##################### [126/129]
^M Installing: kernel ##################### [127/129]
^M Installing: selinux-policy ##################### [128/129]
^M Installing: selinux-policy-targeted ##################### [129/129]

All of this still went smoothly...

libsemanage.dbase_llist_query: could not query record value

No idea where this is coming from

/sbin/restorecon reset / context system_ubject_r:file_t:s0->system_ubject_r:root_t:s0
/sbin/restorecon reset /lib context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
/sbin/restorecon reset /lib/kbd context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0

We are back to calling restorecon on every single file.....

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Tue, 2008-05-13 at 12:06 -0400, Eric Paris wrote:
> Current Setup:
>
> F9 trying to build an F9 livecd so policy should be happy. I'm trying
> to eliminate the illegal file context cruft to start with.
>
> Enforcing.
>
> the label on livecd-creator is bin_t NOT unconfined_notran_t
>
> chroot/selinux contains:
> null -> /dev/null
> load -> /dev/null
> mls -> 1
> enforcing -> 1
> policyvers -> 22
> context -> regular file

Just as a reminder, I don't believe you should have context there at
all, as omitting it should just work (tm).

> libselinux always opens files with O_TRUNC

And thus you wouldn't need this hack.

> libselinux rpm_execcon has the patch to return -1 and set con =
> context_new(mycon);

Just to clarify, the patch should actually enable rpm_execcon() to
proceed with rpm_script_t even if /selinux/create does not exist.

> the new libselinux is being used inside and outside the chroot
>
> rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires
> libeselinux-devel not libselinux-static so I'm hoping we are safe.
>
> ******************************
>
> ^M Installing: kbd ##################### [126/129]
> ^M Installing: kernel ##################### [127/129]
> ^M Installing: selinux-policy ##################### [128/129]
> ^M Installing: selinux-policy-targeted ##################### [129/129]
>
> All of this still went smoothly...
>
> libsemanage.dbase_llist_query: could not query record value
>
> No idea where this is coming from

Maybe a table was empty. Might want to look under etc/selinux/targeted
within the chroot.

> /sbin/restorecon reset / context system_ubject_r:file_t:s0->system_ubject_r:root_t:s0
> /sbin/restorecon reset /lib context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
>
> We are back to calling restorecon on every single file.....

Well, you did put back in a /selinux/context against my advice, and I'm
not sure what else you changed in the above.

But more fundamentally we really need someone who understands the code
flow in rpm to explain when rpm checks for SELinux status and how it
switches from using policy outside the chroot to using policy within the
chroot for file labeling.

An strace of rpm might be interesting although no doubt very hard to
follow.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> Current Setup:
>
> F9 trying to build an F9 livecd so policy should be happy. I'm trying
> to eliminate the illegal file context cruft to start with.
>
> Enforcing.
>
> the label on livecd-creator is bin_t NOT unconfined_notran_t
>
> chroot/selinux contains:
> null -> /dev/null
> load -> /dev/null
> mls -> 1
> enforcing -> 1
> policyvers -> 22
> context -> regular file
>
> libselinux always opens files with O_TRUNC
>
> libselinux rpm_execcon has the patch to return -1 and set con =
> context_new(mycon);
>
> the new libselinux is being used inside and outside the chroot
>
> rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires
> libeselinux-devel not libselinux-static so I'm hoping we are safe.
>
> ******************************
>
> ^M Installing: kbd ##################### [126/129]
> ^M Installing: kernel ##################### [127/129]
> ^M Installing: selinux-policy ##################### [128/129]
> ^M Installing: selinux-policy-targeted ##################### [129/129]
>
> All of this still went smoothly...
>
> libsemanage.dbase_llist_query: could not query record value
>
> No idea where this is coming from
>
> /sbin/restorecon reset / context system_ubject_r:file_t:s0->system_ubject_r:root_t:s0
> /sbin/restorecon reset /lib context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
> /sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_ubject_r:file_t:s0->system_ubject_r:lib_t:s0
>
> We are back to calling restorecon on every single file.....
>
> -Eric
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I don't have a problem with calling restorecon on every single file,
since this is a limited number of files. The goal is to allow the
chroot to run without mucking around with the host security. So I don't
have to run permissive or disabled if I use mock/livecd. If mock/livecd
have to relabel when they complete that is fine.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgpyBkACgkQrlYvE4MpobNUlACbBN5WJvv0IU H6Voq3L2GgLIej
MXYAn3ja4+e8pZpHQTXbctm5fYIe9UOj
=a9ex
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Tue, 2008-05-13 at 12:53 -0400, Stephen Smalley wrote:
> On Tue, 2008-05-13 at 12:06 -0400, Eric Paris wrote:
> > Current Setup:
> >
> > F9 trying to build an F9 livecd so policy should be happy. I'm trying
> > to eliminate the illegal file context cruft to start with.
> >
> > Enforcing.
> >
> > the label on livecd-creator is bin_t NOT unconfined_notran_t
> >
> > chroot/selinux contains:
> > null -> /dev/null
> > load -> /dev/null
> > mls -> 1
> > enforcing -> 1
> > policyvers -> 22
> > context -> regular file
>
> Just as a reminder, I don't believe you should have context there at
> all, as omitting it should just work (tm).

You also shouldn't need "null" in /selinux; that's a node within
selinuxfs for use by the kernel when closing unauthorized files upon
execve and replacing them with references to the null device. It
doesn't get used by SELinux userspace.

There is no "enforcing" file; it is "enforce" and I don't think you need
it within the chroot for anything. It isn't the indicator of whether
SELinux is enabled.

So that leaves you with just "load" (so that policy reload appears to
succeed), "mls" (so that semanage knows whether to include MLS fields),
and "policyvers" (again for policy reload purposes). And neither "load"
nor "policyvers" should be necessary if we could just disable policy
reload altogether (which is possible but not sure how to make it happen
transparently under only these conditions), and "mls" wouldn't be
necessary if we introduced proper support into libsemanage for querying
the MLS status of the policy and change semanage/seobject.py to use that
instead.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Tuesday 13 May 2008, Daniel J Walsh wrote:
>
> I don't have a problem with calling restorecon on every single file,
> since this is a limited number of files. The goal is to allow the
> chroot to run without mucking around with the host security. So I don't
> have to run permissive or disabled if I use mock/livecd. If mock/livecd
> have to relabel when they complete that is fine.


I would really like to enable selinux on the actual builders. Right now it
has to be disabled. If not alot of things build ok but certain packages will
switch to enforcing inside the chroot when the host is in permissive mode.
and it causes all sorts of fun and failed builds. for the builders i think
that calling restorecon will slow down builds too much. A new chroot is
created for each and every build.

This is a seperate issue from having machines for doing composes.

Dennis
--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Tue, 13 May 2008 12:29:30 -0500
Dennis Gilmore <dennis@ausil.us> wrote:

> On Tuesday 13 May 2008, Daniel J Walsh wrote:
> >
> > I don't have a problem with calling restorecon on every single file,
> > since this is a limited number of files. The goal is to allow the
> > chroot to run without mucking around with the host security. So I
> > don't have to run permissive or disabled if I use mock/livecd. If
> > mock/livecd have to relabel when they complete that is fine.
>
>
> I would really like to enable selinux on the actual builders. Right
> now it has to be disabled. If not alot of things build ok but
> certain packages will switch to enforcing inside the chroot when the
> host is in permissive mode. and it causes all sorts of fun and failed
> builds.

Which packages do this?

I run my own mock builders with selinux enforcing on F8 and haven't
come across anything like that, though obviously the Fedora builders
are exposed to a much wider variety of packages than my small
collection.

Paul.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

> > ^M Installing: kbd ##################### [126/129]
> > ^M Installing: kernel ##################### [127/129]
> > ^M Installing: selinux-policy ##################### [128/129]
> > ^M Installing: selinux-policy-targeted ##################### [129/129]
> >
> > All of this still went smoothly...
> >
> > libsemanage.dbase_llist_query: could not query record value
> >
> > No idea where this is coming from
>
> Maybe a table was empty. Might want to look under etc/selinux/targeted
> within the chroot.

Without any helpful input I've still been banging my head against this
wall, cleaned up a bunch of stuff in how the livecd-tools make images,
wrote some policy (going to need to redo it) and it seems like I'm
building images at least now. Remember all of this is building F10
images on F10, I'm not trying to handle the 'illegal' context stuff at
all, let just make that clear.

Anyway, I'm still getting a couple of ?error? messages

Installing: kbd ##################### [126/129]
Installing: selinux-policy ##################### [127/129]
Installing: selinux-policy-targeted ##################### [128/129]
libsemanage.dbase_llist_query: could not query record value
/usr/sbin/semanage: Invalid prefix user
/usr/sbin/semanage: Invalid prefix user

Installing: kernel ##################### [129/129]
Only root can do that.
e2fsck 1.40.9 (27-Apr-2008)
Pass 1: Checking inodes, blocks, and sizes

but I'm about to try to boot one of these things and see what happens.
Anyone have hints on what to look for with the above error messages? As
usual I don't know what a 'table' is in this context

-Eric

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Wed, 2008-05-14 at 16:38 -0400, Eric Paris wrote:
> > > ^M Installing: kbd ##################### [126/129]
> > > ^M Installing: kernel ##################### [127/129]
> > > ^M Installing: selinux-policy ##################### [128/129]
> > > ^M Installing: selinux-policy-targeted ##################### [129/129]
> > >
> > > All of this still went smoothly...
> > >
> > > libsemanage.dbase_llist_query: could not query record value
> > >
> > > No idea where this is coming from
> >
> > Maybe a table was empty. Might want to look under etc/selinux/targeted
> > within the chroot.
>
> Without any helpful input I've still been banging my head against this
> wall, cleaned up a bunch of stuff in how the livecd-tools make images,
> wrote some policy (going to need to redo it) and it seems like I'm
> building images at least now. Remember all of this is building F10
> images on F10, I'm not trying to handle the 'illegal' context stuff at
> all, let just make that clear.
>
> Anyway, I'm still getting a couple of ?error? messages
>
> Installing: kbd ##################### [126/129]
> Installing: selinux-policy ##################### [127/129]
> Installing: selinux-policy-targeted ##################### [128/129]
> libsemanage.dbase_llist_query: could not query record value
> /usr/sbin/semanage: Invalid prefix user
> /usr/sbin/semanage: Invalid prefix user
>
> Installing: kernel ##################### [129/129]
> Only root can do that.
> e2fsck 1.40.9 (27-Apr-2008)
> Pass 1: Checking inodes, blocks, and sizes
>
> but I'm about to try to boot one of these things and see what happens.
> Anyone have hints on what to look for with the above error messages? As
> usual I don't know what a 'table' is in this context

The invalid prefix user is another artifact of semanage/seobject.py
trying to check something against the host's policy rather than checking
against the target policy just due to lack of adequate libsemanage
interfaces. Calls to is_selinux_mls_enabled() and
security_check_context() need to be turned into libsemanage calls.

The could not query record value one is too generic. Might help to get
a snapshot of the /etc/selinux/targeted tree that it built and see
what's there. Or possibly patching libsemanage to give more useful
output, but it's a bit hard due to abstraction layers there.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Thu, 2008-05-15 at 14:36 -0400, Stephen Smalley wrote:
> On Wed, 2008-05-14 at 16:38 -0400, Eric Paris wrote:
> > > > ^M Installing: kbd ##################### [126/129]
> > > > ^M Installing: kernel ##################### [127/129]
> > > > ^M Installing: selinux-policy ##################### [128/129]
> > > > ^M Installing: selinux-policy-targeted ##################### [129/129]
> > > >
> > > > All of this still went smoothly...
> > > >
> > > > libsemanage.dbase_llist_query: could not query record value
> > > >
> > > > No idea where this is coming from
> > >
> > > Maybe a table was empty. Might want to look under etc/selinux/targeted
> > > within the chroot.
> >
> > Without any helpful input I've still been banging my head against this
> > wall, cleaned up a bunch of stuff in how the livecd-tools make images,
> > wrote some policy (going to need to redo it) and it seems like I'm
> > building images at least now. Remember all of this is building F10
> > images on F10, I'm not trying to handle the 'illegal' context stuff at
> > all, let just make that clear.
> >
> > Anyway, I'm still getting a couple of ?error? messages
> >
> > Installing: kbd ##################### [126/129]
> > Installing: selinux-policy ##################### [127/129]
> > Installing: selinux-policy-targeted ##################### [128/129]
> > libsemanage.dbase_llist_query: could not query record value
> > /usr/sbin/semanage: Invalid prefix user
> > /usr/sbin/semanage: Invalid prefix user
> >
> > Installing: kernel ##################### [129/129]
> > Only root can do that.
> > e2fsck 1.40.9 (27-Apr-2008)
> > Pass 1: Checking inodes, blocks, and sizes
> >
> > but I'm about to try to boot one of these things and see what happens.
> > Anyone have hints on what to look for with the above error messages? As
> > usual I don't know what a 'table' is in this context
>
> The invalid prefix user is another artifact of semanage/seobject.py
> trying to check something against the host's policy rather than checking
> against the target policy just due to lack of adequate libsemanage
> interfaces. Calls to is_selinux_mls_enabled() and
> security_check_context() need to be turned into libsemanage calls.
>
> The could not query record value one is too generic. Might help to get
> a snapshot of the /etc/selinux/targeted tree that it built and see
> what's there. Or possibly patching libsemanage to give more useful
> output, but it's a bit hard due to abstraction layers there.

BTW, are you doing all of this with the patch for rpm_execcon that I
sent you? If so, I should likely commit that upstream.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list