On Mon, 2008-05-12 at 10:53 -0400, Stephen Smalley wrote:
> > On second thought is that even possible? As I recall
> > selinux-policy-targeted rpm is installed about 128/129 packages when I
> > do my livecd create. That means that we didn't even have an 'inside
> > chroot' policy to check against for the vast majority of this operation.
> > I'd assume that building the appropriete mock buildroot would have the
> > same problem. Wonder how people would feel about really hacking up the
> > buildroot creator to force install selinux stuff first and then run the
> > full install transaction set....
>
> For a normal install, anaconda has to set down an initial file contexts
> file and load a policy to get things started IIRC - otherwise rpm
> wouldn't be able to label the files it sets down prior to installing
> selinux-policy*.

It uses the policy from outside the chroot until things are put into the
chroot. This "works" for the anaconda case as we don't really fully[1]
support installing a different environment than what your install images
are built with

Jeremy

[1] We've actually done a lot of work to make this more supported, but
SELinux is actually now the big blocker that I know of due to this
reasoning. At least for things which count as similar, for certain
values of that.

> > > Or disable context validation altogether in userspace in that instance.
> >
> > Anyone have suggestions on how to go about this?
>
> Absence of any /selinux/context at all should automatically do that.
>
> > > Or create some kind of "identity" node in the selinuxfs filesystem that
> > > is transaction-based like the existing selinuxfs nodes and always
> > > returns whatever was written to it, then bind mount that on top
> > > of /selinux/context.
> >
> > I did get that out of using a plain file and using O_TRUNC in libselinux
> > eventually.
>
> Yes, but I don't see how requiring the use of a hacked-up libselinux is
> any better or more workable.
>

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

On Mon, 2008-05-12 at 11:26 -0400, Bill Nottingham wrote:
> Eric Paris (eparis@redhat.com) said:
> > same problem. Wonder how people would feel about really hacking up the
> > buildroot creator to force install selinux stuff first and then run the
> > full install transaction set....
>
> Due to dependencies, you can never load the policy 'first'.

Just to make this a little bit more explicit for others following along,
we can't due this because loading the policy requires that the policy be
installed on disk as well as things like load_policy being on disk.
That depends on having libc, etc in the chroot as well. So ignoring
questions of taste, you'd still have the chicken and egg problem.

But as far as taste as concerned, hacking up every single thing that
ever creates a chroot feels wrong, wrong, wrong, wrong, wrong.
Especially because it's not little hacks, it's a big hack involving
creating a new micro-transaction with only a subset of the packages. It
also becomes "interesting" when you start to think about update
operations within a chroot.

Jeremy

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

On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@redhat.com> wrote:
> On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote:
> > On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
>
> > > So I added O_TRUNC to both of the callers to /selinux/context in
> > > libselinux and that took care of the lsetfilecon() crap but I still get
> > > tons and tons of "scriptlet failed, exit status 255"
> > >
> > > Anyone have ideas/suggestions how to debug those more?
> >
> > Ah, it is likely failing on the rpm_execcon(3) ->
> > security_compute_create(3) call i.e. writing to /selinux/create.
> > Which computes the context in which to run the scriptlet or helper from
> > the policy. If that returns the same as rpm's own context, then we fall
> > back to rpm_script_t. So this affects things like ldconfig.
> >
> > I increasingly suspect we're better off not mounting selinuxfs within
> > the chroot at all and addressing any issues that arise via policy.
>
> If we don't mount selinuxfs, then anything that attempts to figure out
> if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled
> to determine whether or not to set the xattrs) will fail. Also, I don't
> remember for certain without looking, but even restorecon checks like
> that from what I remember. So we have to at least have some of /selinux
> present or we have to do deeper tricks with labeling outside of chroots
> which ... pain :-/

That shouldn't actually be true - the fundamental test for whether or
not SELinux is enabled is the presence or absence of selinuxfs in
/proc/filesystems (i.e. is it registered in the kernel), not whether
or not selinuxfs is actually mounted anywhere. The libselinux logic
should fall back to that /proc/filesystems test.

And looking at the libselinux code, it does appear to handle ENOENT on
/selinux/context by skipping the normal context validation, so not
having it present at all in /selinux within the chroot should help
_unless_ rpm calls matchpathcon() will outside of the chroot (that's
what I'm unclear on - when rpm is operating within the chroot and when
it is operating outside the chroot).

The only problem I see with not having selinuxfs mounted at all within
the chroot or even providing fake /selinux nodes is that rpm_execcon()
will then see SELinux as disabled and thus not try to run the
scriptlet in a different domain; it should just fall back to a normal
execve() in that situation. Which could be addressed in policy
largely by collapsing rpm_script_t and rpm_t into a single domain.
I'm not sure how much we are using the distinction at present - I
think they are both effectively unconfined so it would only differ
possibly in outbound type transitions.

Anyway, I'd be interested in having Eric try the install with no
selinuxfs mounted or fake selinux nodes within the chroot and see what
happens, both in permissive mode and enforcing mode.

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

On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley
<stephen.smalley@gmail.com> wrote:
>
> On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@redhat.com> wrote:
> > On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote:
> > > On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
> >
> > > > So I added O_TRUNC to both of the callers to /selinux/context in
> > > > libselinux and that took care of the lsetfilecon() crap but I still get
> > > > tons and tons of "scriptlet failed, exit status 255"
> > > >
> > > > Anyone have ideas/suggestions how to debug those more?
> > >
> > > Ah, it is likely failing on the rpm_execcon(3) ->
> > > security_compute_create(3) call i.e. writing to /selinux/create.
> > > Which computes the context in which to run the scriptlet or helper from
> > > the policy. If that returns the same as rpm's own context, then we fall
> > > back to rpm_script_t. So this affects things like ldconfig.
> > >
> > > I increasingly suspect we're better off not mounting selinuxfs within
> > > the chroot at all and addressing any issues that arise via policy.
> >
> > If we don't mount selinuxfs, then anything that attempts to figure out
> > if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled
> > to determine whether or not to set the xattrs) will fail. Also, I don't
> > remember for certain without looking, but even restorecon checks like
> > that from what I remember. So we have to at least have some of /selinux
> > present or we have to do deeper tricks with labeling outside of chroots
> > which ... pain :-/
>
> That shouldn't actually be true - the fundamental test for whether or
> not SELinux is enabled is the presence or absence of selinuxfs in
> /proc/filesystems (i.e. is it registered in the kernel), not whether
> or not selinuxfs is actually mounted anywhere. The libselinux logic
> should fall back to that /proc/filesystems test.
>
> And looking at the libselinux code, it does appear to handle ENOENT on
> /selinux/context by skipping the normal context validation, so not
> having it present at all in /selinux within the chroot should help
> _unless_ rpm calls matchpathcon() will outside of the chroot (that's
> what I'm unclear on - when rpm is operating within the chroot and when
> it is operating outside the chroot).
>
> The only problem I see with not having selinuxfs mounted at all within
> the chroot or even providing fake /selinux nodes is that rpm_execcon()
> will then see SELinux as disabled and thus not try to run the
> scriptlet in a different domain;

Ah, sorry - I misspoke above. Since is_selinux_enabled() ultimately
comes down to presence/absence of selinuxfs in /proc/filesystems,
rpm_execcon() will see SELinux as enabled but the
security_compute_create() call will fail and this will cause it to
abort rather than execve(). That's the problem Eric presently has.
So possibly changing rpm_execcon() to fall back to setting the default
domain to rpm_script_t and proceeding if security_compute_create()
fails would allow him to proceed. That would still leave us in
rpm_script_t rather than ldconfig_t, so we'd have a labeling problem,
but that's likely fixable via a selective restorecon after the fact.

> it should just fall back to a normal
> execve() in that situation. Which could be addressed in policy
> largely by collapsing rpm_script_t and rpm_t into a single domain.
> I'm not sure how much we are using the distinction at present - I
> think they are both effectively unconfined so it would only differ
> possibly in outbound type transitions.
>
> Anyway, I'd be interested in having Eric try the install with no
> selinuxfs mounted or fake selinux nodes within the chroot and see what
> happens, both in permissive mode and enforcing mode.
>

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

On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
> On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@redhat.com> wrote:

> The only problem I see with not having selinuxfs mounted at all within
> the chroot or even providing fake /selinux nodes is that rpm_execcon()
> will then see SELinux as disabled and thus not try to run the
> scriptlet in a different domain;

How does it do this check? Guess I should pull some rpm sources. My
lord I don't wanna....

> Anyway, I'd be interested in having Eric try the install with no
> selinuxfs mounted or fake selinux nodes within the chroot and see what
> happens, both in permissive mode and enforcing mode.

I've got my fake selinux mount inside the chroot much like I previously
described. /selinux/create is still getting long strings in it that
don't make much sense. I guess something is using it directly and not
through the libselinux interface?!?!


enforcing=1 /selinux inside the chroot is the little thing that I made
up to fake it.

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
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_ubject_r:file_t:s0->system_ubject_r:root_t:s0
/sbin/restorecon reset /bin context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
/sbin/restorecon reset /bin/rvi context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
/sbin/restorecon reset /bin/touch context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
/sbin/restorecon reset /bin/mountpoint context unconfined_ubject_r:file_t:s0->system_ubject_r:mount_exec_t:s0
/sbin/restorecon reset /bin/arch context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0

and restorecon goes on like this, and on, and on, and on, and on

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?

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_notr ans_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_notr ans_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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis@redhat.com> wrote:
> On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
> > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@redhat.com> wrote:
>
>
> > The only problem I see with not having selinuxfs mounted at all within
> > the chroot or even providing fake /selinux nodes is that rpm_execcon()
> > will then see SELinux as disabled and thus not try to run the
> > scriptlet in a different domain;
>
> How does it do this check? Guess I should pull some rpm sources. My
> lord I don't wanna....

You don't have to look at rpm for that - rpm_execcon() is a helper
function provided by libselinux for use by rpm. I sent you a patch
separately for it that should get it past a missing /selinux/create
node, so you should be able to completely remove /selinux/context and
/selinux/create and still proceed (at least in permissive mode).

> > Anyway, I'd be interested in having Eric try the install with no
> > selinuxfs mounted or fake selinux nodes within the chroot and see what
> > happens, both in permissive mode and enforcing mode.
>
> I've got my fake selinux mount inside the chroot much like I previously
> described. /selinux/create is still getting long strings in it that
> don't make much sense. I guess something is using it directly and not
> through the libselinux interface?!?!

No, it is just that /selinux/create is a transactional interface that
takes multiple input arguments and returns a single output argument,
so using a regular file for it won't work at all. Just remove it and
use the patch I supplied for rpm_execcon.

>
> enforcing=1 /selinux inside the chroot is the little thing that I made
> up to fake it.

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.

>
> 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".

> 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_ubject_r:file_t:s0->system_ubject_r:root_t:s0
> /sbin/restorecon reset /bin context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> /sbin/restorecon reset /bin/rvi context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> /sbin/restorecon reset /bin/touch context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> /sbin/restorecon reset /bin/mountpoint context unconfined_ubject_r:file_t:s0->system_ubject_r:mount_exec_t:s0
> /sbin/restorecon reset /bin/arch context unconfined_ubject_r:file_t:s0->system_ubject_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.

>
> 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 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_notr ans_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_notr ans_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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
> On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis@redhat.com> 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
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_ubject_r:file_t:s0->system_ubject_r:root_t:s0
> > /sbin/restorecon reset /bin context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> > /sbin/restorecon reset /bin/rvi context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> > /sbin/restorecon reset /bin/touch context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
> > /sbin/restorecon reset /bin/mountpoint context unconfined_ubject_r:file_t:s0->system_ubject_r:mount_exec_t:s0
> > /sbin/restorecon reset /bin/arch context unconfined_ubject_r:file_t:s0->system_ubject_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_notr ans_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_notr ans_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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

-----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@redhat.com> 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
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_ubject_r:file_t:s0->system_ubject_r:root_t:s0
>>> /sbin/restorecon reset /bin context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
>>> /sbin/restorecon reset /bin/rvi context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
>>> /sbin/restorecon reset /bin/touch context unconfined_ubject_r:file_t:s0->system_ubject_r:bin_t:s0
>>> /sbin/restorecon reset /bin/mountpoint context unconfined_ubject_r:file_t:s0->system_ubject_r:mount_exec_t:s0
>>> /sbin/restorecon reset /bin/arch context unconfined_ubject_r:file_t:s0->system_ubject_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_notr ans_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_notr ans_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@redhat.com
> 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

iEYEARECAAYFAkgpk0QACgkQrlYvE4MpobPk4ACguXKMnC7uUM 9jaqont/bxthSI
ZlYAnRvebyTJ54f9RdSEkjHUZ/I/cwPE
=LiD+
-----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 09:03 -0400, 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@redhat.com> 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
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....

The newline is the problem for you; libselinux is_selinux_mls_enabled()
looks for an exact match against "1" since that is what the kernel has
always returned.

--
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 Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
> On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis@redhat.com> wrote:
> > On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
> > > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj@redhat.com> wrote:
> >
> >
> > > The only problem I see with not having selinuxfs mounted at all within
> > > the chroot or even providing fake /selinux nodes is that rpm_execcon()
> > > will then see SELinux as disabled and thus not try to run the
> > > scriptlet in a different domain;
> >
> > How does it do this check? Guess I should pull some rpm sources. My
> > lord I don't wanna....
>
> You don't have to look at rpm for that - rpm_execcon() is a helper
> function provided by libselinux for use by rpm. I sent you a patch
> separately for it that should get it past a missing /selinux/create
> node, so you should be able to completely remove /selinux/context and
> /selinux/create and still proceed (at least in permissive mode).

Will do.....

> 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?)

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?

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
libsemanage.semanage_reload_policy: load_policy returned error code 2.
libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.23. (No such file or directory).
semodule: Failed!
/usr/sbin/semanage: Invalid prefix user
/usr/sbin/semanage: Invalid prefix user

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 /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

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?

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