On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > James Morris (jmorris@namei.org) said:
> > > > You cannot create files in a chroot of a context not known by the
> > > > host policy. This means that if your host is running RHEL 5, you are
> > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > later releases.
> > >
> > > Ok, that's what I suspected.
> > >
> > > One of the possible plans for this is to allow a process to run in a
> > > separate policy namespace, and probably also utilize namespace support in
> > > general.
> > >
> > > This is non-trivial and needs more analysis.
> >
> > Incidentally, this is also one of the blockers for policy-in-packages,
> > rather than a monolithic one.
>
> I assume you mean setting down unknown file labels rather than
> per-namespace or per-chroot policy support. I think they are related
> but different. The former is required if you always plan to install the
> files _before_ loading the policy. The latter is required primarily for
> getting any scriptlets to run in the right security contexts so that any
> files they create are labeled appropriately within the chroot.

BTW, for reference, a patch to support setting down unknown file labels
was posted here a couple of years ago:
http://marc.info/?l=selinux&m=114771094617968&w=2

But unfortunately we weren't able to sort the remaining issues discussed
in that thread.

> Also, I wanted to emphasize that chroot is different than unsharing the
> filesystem namespace, and per-chroot policy is not the same thing as
> per-namespace policy. I'd expect though that it would actually be a
> per-process policy mechanism, with most processes sharing the same
> policy but programs like rpm being able to unshare policy from their
> parent and then load a private policy to be applied only to their
> descendants.
>
--
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-04-22 at 16:58 +0200, Tomas Mraz wrote:
> > Bill Nottingham wrote:
> > > James Morris (jmorris@namei.org) said:
> > >>> * All the parties are here now needed to figure this out
> > >>> * Someone better than me is going to reply with specifics about what is
> > >>> not working in the buildsys
> > >>> * We all agree it's pretty important to get this figured out in a good
> > >>> way
> > >> Can you please explain specifically what the problem is?
> > >
> > > You cannot create files in a chroot of a context not known by the
> > > host policy. This means that if your host is running RHEL 5, you are
> > > unable to compose any trees/images/livecds with SELinux enabled for
> > > later releases.
> > >
> > > Bill
> > >
> > > --
> > > fedora-selinux-list mailing list
> > > fedora-selinux-list@redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > Just catching up on this email chain.
> >
> > The far more insidious problem is the act of loading policy in the
> > chroot effects the kernel of the host. So processes that are running in
> > the host become invalidated when the client loads a policy. This
> > happens even in the case where you are building a chroot environment on
> > the SAME os. Since the spec file is running semanage commands to modify
> > and add unconfined_t users, the unconfined processes of the parent and
> > potential labels become unknown to the kernel for a period of time,
> > which ends up labeling the files and processes as unlabeled_t. When
> > this happens files labeled unlabeled_t can not be accesses by confined
> > process and if a process becomes unlabeled_t it will not be allowed any
> > access on the box, which can cause the process to crash or go into in
> > infinite loop. If I build a livedvd, I end
> >
> > setenforce 0
> > livedvd ...
> > load_policy
> > setenforce 1
> > And sometimes I still need to
> > fixfiles restore
>
> Could it be solved by kernel preventing loading the policy when the
> process which tries that is in the chroot? It seems to me that it
> doesn't make any sense to allow that. Then with enabling creating files
> with a context unknown to the policy the machine could run in enforcing
> mode although the process which does the compose would of course have to
> be unconfined.

Why mount selinuxfs within the chroot at all? Policy load isn't
possible without selinuxfs.

I had thought though that they wanted/needed to load the policy with
scope limited to children of rpm so that package scriptlets will run in
the correct domain and files created by them will be labeled as expected
for the image being built rather than based on the host policy. Which
is rather complicated - it requires a per-process policy pointer and
some way to deal with files that may be visible both to scriptlets
within the chroot and to rpm and other processes outside of it.

--
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-04-22 at 11:55 -0400, Stephen Smalley wrote:
> On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > James Morris (jmorris@namei.org) said:
> > > > > You cannot create files in a chroot of a context not known by the
> > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > later releases.
> > > >
> > > > Ok, that's what I suspected.
> > > >
> > > > One of the possible plans for this is to allow a process to run in a
> > > > separate policy namespace, and probably also utilize namespace support in
> > > > general.
> > > >
> > > > This is non-trivial and needs more analysis.
> > >
> > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > rather than a monolithic one.
> >
> > I assume you mean setting down unknown file labels rather than
> > per-namespace or per-chroot policy support. I think they are related
> > but different. The former is required if you always plan to install the
> > files _before_ loading the policy. The latter is required primarily for
> > getting any scriptlets to run in the right security contexts so that any
> > files they create are labeled appropriately within the chroot.
>
> BTW, for reference, a patch to support setting down unknown file labels
> was posted here a couple of years ago:
> http://marc.info/?l=selinux&m=114771094617968&w=2

And the last version of that patch was:
http://marc.info/?l=selinux&m=114840466518263&w=2
Not that it applies cleanly anymore, of course.

> But unfortunately we weren't able to sort the remaining issues discussed
> in that thread.
>
> > Also, I wanted to emphasize that chroot is different than unsharing the
> > filesystem namespace, and per-chroot policy is not the same thing as
> > per-namespace policy. I'd expect though that it would actually be a
> > per-process policy mechanism, with most processes sharing the same
> > policy but programs like rpm being able to unshare policy from their
> > parent and then load a private policy to be applied only to their
> > descendants.
> >
--
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

Stephen Smalley wrote:
> On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
>>> Bill Nottingham wrote:
>>>> James Morris (jmorris@namei.org) said:
>>>>>> * All the parties are here now needed to figure this out
>>>>>> * Someone better than me is going to reply with specifics about what is
>>>>>> not working in the buildsys
>>>>>> * We all agree it's pretty important to get this figured out in a good
>>>>>> way
>>>>> Can you please explain specifically what the problem is?
>>>> You cannot create files in a chroot of a context not known by the
>>>> host policy. This means that if your host is running RHEL 5, you are
>>>> unable to compose any trees/images/livecds with SELinux enabled for
>>>> later releases.
>>>>
>>>> Bill
>>>>
>>>> --
>>>> fedora-selinux-list mailing list
>>>> fedora-selinux-list@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>> Just catching up on this email chain.
>>>
>>> The far more insidious problem is the act of loading policy in the
>>> chroot effects the kernel of the host. So processes that are running in
>>> the host become invalidated when the client loads a policy. This
>>> happens even in the case where you are building a chroot environment on
>>> the SAME os. Since the spec file is running semanage commands to modify
>>> and add unconfined_t users, the unconfined processes of the parent and
>>> potential labels become unknown to the kernel for a period of time,
>>> which ends up labeling the files and processes as unlabeled_t. When
>>> this happens files labeled unlabeled_t can not be accesses by confined
>>> process and if a process becomes unlabeled_t it will not be allowed any
>>> access on the box, which can cause the process to crash or go into in
>>> infinite loop. If I build a livedvd, I end
>>>
>>> setenforce 0
>>> livedvd ...
>>> load_policy
>>> setenforce 1
>>> And sometimes I still need to
>>> fixfiles restore
>> Could it be solved by kernel preventing loading the policy when the
>> process which tries that is in the chroot? It seems to me that it
>> doesn't make any sense to allow that. Then with enabling creating files
>> with a context unknown to the policy the machine could run in enforcing
>> mode although the process which does the compose would of course have to
>> be unconfined.
>
> Why mount selinuxfs within the chroot at all? Policy load isn't
> possible without selinuxfs.
>
> I had thought though that they wanted/needed to load the policy with
> scope limited to children of rpm so that package scriptlets will run in
> the correct domain and files created by them will be labeled as expected
> for the image being built rather than based on the host policy. Which
> is rather complicated - it requires a per-process policy pointer and
> some way to deal with files that may be visible both to scriptlets
> within the chroot and to rpm and other processes outside of it.
>
Well currently livecd tools to a relabel at the end. So we still have
the problem of the labels being correct when the dvd is complete.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgOOnAACgkQrlYvE4MpobNtGgCdGbX4swbPMB snC+BpL6PTNEWM
x4QAoKd+OpqR7ycGKZviGeb+ywYnQyjE
=O3UV
-----END PGP SIGNATURE-----

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

On Tue, Apr 22, 2008 at 3:20 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Stephen Smalley wrote:
> > On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
> >>> Bill Nottingham wrote:
> >>>> James Morris (jmorris@namei.org) said:
> >>>>>> * All the parties are here now needed to figure this out
> >>>>>> * Someone better than me is going to reply with specifics about what is
> >>>>>> not working in the buildsys
> >>>>>> * We all agree it's pretty important to get this figured out in a good
> >>>>>> way
> >>>>> Can you please explain specifically what the problem is?
> >>>> You cannot create files in a chroot of a context not known by the
> >>>> host policy. This means that if your host is running RHEL 5, you are
> >>>> unable to compose any trees/images/livecds with SELinux enabled for
> >>>> later releases.
> >>>>
> >>>> Bill
> >>>>
> >>>> --
> >>>> fedora-selinux-list mailing list
> >>>> fedora-selinux-list@redhat.com
> >>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>> Just catching up on this email chain.
> >>>
> >>> The far more insidious problem is the act of loading policy in the
> >>> chroot effects the kernel of the host. So processes that are running in
> >>> the host become invalidated when the client loads a policy. This
> >>> happens even in the case where you are building a chroot environment on
> >>> the SAME os. Since the spec file is running semanage commands to modify
> >>> and add unconfined_t users, the unconfined processes of the parent and
> >>> potential labels become unknown to the kernel for a period of time,
> >>> which ends up labeling the files and processes as unlabeled_t. When
> >>> this happens files labeled unlabeled_t can not be accesses by confined
> >>> process and if a process becomes unlabeled_t it will not be allowed any
> >>> access on the box, which can cause the process to crash or go into in
> >>> infinite loop. If I build a livedvd, I end
> >>>
> >>> setenforce 0
> >>> livedvd ...
> >>> load_policy
> >>> setenforce 1
> >>> And sometimes I still need to
> >>> fixfiles restore
> >> Could it be solved by kernel preventing loading the policy when the
> >> process which tries that is in the chroot? It seems to me that it
> >> doesn't make any sense to allow that. Then with enabling creating files
> >> with a context unknown to the policy the machine could run in enforcing
> >> mode although the process which does the compose would of course have to
> >> be unconfined.
> >
> > Why mount selinuxfs within the chroot at all? Policy load isn't
> > possible without selinuxfs.
> >
> > I had thought though that they wanted/needed to load the policy with
> > scope limited to children of rpm so that package scriptlets will run in
> > the correct domain and files created by them will be labeled as expected
> > for the image being built rather than based on the host policy. Which
> > is rather complicated - it requires a per-process policy pointer and
> > some way to deal with files that may be visible both to scriptlets
> > within the chroot and to rpm and other processes outside of it.
> >
> Well currently livecd tools to a relabel at the end. So we still have
> the problem of the labels being correct when the dvd is complete.
>
I am trying to keep up with this conversation and I don't expect
anyone to stop and explain all this but....
Can the image be built on a remote host?or a virtualized one(i caught
but do not completely understand the comment about being unable to
virtualize SELinux)? Would this not rather neatly avoid the chroot
problem(assuming I am understanding the problem correctly)? Which if i
understand it right is that you cannot load policy in the chroot
because the policy applies itself or is getting applied to the running
kernel even though it is not intended for that kernel but the one in
the image, which is of course not running. Perhaps these things have
been considered already but are not feasible? Mind you I have no idea
how to implement this, I am just beating my little gnat wings off the
west coast of Africa hoping I can cause the typhoon in south america.
I haven't been able to find much in the way of documentation on the
fedora build system. if anyone has a pointer to good docs, assuming
they exist, I would appreciate the link, what little I have found
seems incomplete or unfinished.

Max

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

On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > James Morris (jmorris@namei.org) said:
> > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > later releases.
> > > > >
> > > > > Ok, that's what I suspected.
> > > > >
> > > > > One of the possible plans for this is to allow a process to run in a
> > > > > separate policy namespace, and probably also utilize namespace support in
> > > > > general.
> > > > >
> > > > > This is non-trivial and needs more analysis.
> > > >
> > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > rather than a monolithic one.
> > >
> > > I assume you mean setting down unknown file labels rather than
> > > per-namespace or per-chroot policy support. I think they are related
> > > but different. The former is required if you always plan to install the
> > > files _before_ loading the policy. The latter is required primarily for
> > > getting any scriptlets to run in the right security contexts so that any
> > > files they create are labeled appropriately within the chroot.
> >
> > BTW, for reference, a patch to support setting down unknown file labels
> > was posted here a couple of years ago:
> > http://marc.info/?l=selinux&m=114771094617968&w=2
>
> And the last version of that patch was:
> http://marc.info/?l=selinux&m=114840466518263&w=2
> Not that it applies cleanly anymore, of course.

Note for anyone trying to revive that patch: please be sure to
introduce a new security class for that permission instead of adding it
to the security class as I did in that patch, so that we can be certain
that this new ability won't be allowed to unconfined domains by default.
We do not want unconfined_t user shells to be able to set arbitrary
label values w/o no warning that it wasn't valid; we want to limit this
to specific programs like rpm that will be aware of the implications and
(hopefully) do some validity checking of their own afterward.

--
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-04-22 at 12:38 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > James Morris (jmorris@namei.org) said:
> > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > later releases.
> > > > >
> > > > > Ok, that's what I suspected.
> > > > >
> > > > > One of the possible plans for this is to allow a process to run in a
> > > > > separate policy namespace, and probably also utilize namespace support in
> > > > > general.
> > > > >
> > > > > This is non-trivial and needs more analysis.
> > > >
> > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > rather than a monolithic one.
> > >
> > > I assume you mean setting down unknown file labels rather than
> > > per-namespace or per-chroot policy support. I think they are related
> > > but different. The former is required if you always plan to install the
> > > files _before_ loading the policy. The latter is required primarily for
> > > getting any scriptlets to run in the right security contexts so that any
> > > files they create are labeled appropriately within the chroot.
> >
> > BTW, for reference, a patch to support setting down unknown file labels
> > was posted here a couple of years ago:
> > http://marc.info/?l=selinux&m=114771094617968&w=2
>
> And the last version of that patch was:
> http://marc.info/?l=selinux&m=114840466518263&w=2
> Not that it applies cleanly anymore, of course.

An updated patch and discussion has started over on selinux list, see:
http://marc.info/?t=120958955400002&r=1&w=2

One question that has come up is whether the patch to support setting
unknown file labels is sufficient to support the buildsys needs, or
whether something more is required. My impression is that all we truly
need is:
1) support for setting unknown file labels for use by rpm, and
2) bind mount /dev/null over selinux/load within the chroot so that
policy loads within the chroot do nothing rather than changing the build
host's policy, and
3) bind mount a regular empty file over selinux/context within the
chroot so that attempts to validate/canonicalize contexts by rpm will
always return the original value w/o trying to validate against the
build host's policy.

Plus the associated policy changes to permit the above to take place.
Does that sufficient?

The per-chroot/namespace policy idea sounds nice and elegant, but is a
lot more complicated, so if the above is workable, it provides a much
shorter term path for solving the buildsys problem.

--
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 Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > > James Morris (jmorris@namei.org) said:
> > > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > > later releases.
> > > > > >
> > > > > > Ok, that's what I suspected.
> > > > > >
> > > > > > One of the possible plans for this is to allow a process to run in a
> > > > > > separate policy namespace, and probably also utilize namespace support in
> > > > > > general.
> > > > > >
> > > > > > This is non-trivial and needs more analysis.
> > > > >
> > > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > > rather than a monolithic one.
> > > >
> > > > I assume you mean setting down unknown file labels rather than
> > > > per-namespace or per-chroot policy support. I think they are related
> > > > but different. The former is required if you always plan to install the
> > > > files _before_ loading the policy. The latter is required primarily for
> > > > getting any scriptlets to run in the right security contexts so that any
> > > > files they create are labeled appropriately within the chroot.
> > >
> > > BTW, for reference, a patch to support setting down unknown file labels
> > > was posted here a couple of years ago:
> > > http://marc.info/?l=selinux&m=114771094617968&w=2
> >
> > And the last version of that patch was:
> > http://marc.info/?l=selinux&m=114840466518263&w=2
> > Not that it applies cleanly anymore, of course.
>
> An updated patch and discussion has started over on selinux list, see:
> http://marc.info/?t=120958955400002&r=1&w=2
>
> One question that has come up is whether the patch to support setting
> unknown file labels is sufficient to support the buildsys needs, or
> whether something more is required. My impression is that all we truly
> need is:
> 1) support for setting unknown file labels for use by rpm, and
> 2) bind mount /dev/null over selinux/load within the chroot so that
> policy loads within the chroot do nothing rather than changing the build
> host's policy, and
> 3) bind mount a regular empty file over selinux/context within the
> chroot so that attempts to validate/canonicalize contexts by rpm will
> always return the original value w/o trying to validate against the
> build host's policy.

We need to better understand the sequence of actions performed by rpm,
both from outside the chroot and from within the chroot, to know
precisely what is needed here.

It would be cleaner if we could just disable policy reload altogether.
libsemanage will skip policy reload if:
1) the caller asked to skip reload (e.g. semodule with the -n option) or
2) the caller asked to operate on a policy store other than the active
policy store (e.g. semodule with the -s option), or
3) SELinux appears to be disabled.

We can fake the last one, but I think that will confuse rpm with respect
to other actions we still want it to take, like labeling the files,
transitioning to a scriptlet domain, etc.

On the context validation/canonicalization, it would be cleaner if we
could have rpm validate and canonicalize against the target image's
policy rather than the build host's policy. This is likely doable, as
setfiles has to do something like this for its -c option when validating
a file contexts configuration against a policy at policy build time.
Requires calling a libselinux interface to register an alternative
validate callback.

> Plus the associated policy changes to permit the above to take place.
> Does that sufficient?
>
> The per-chroot/namespace policy idea sounds nice and elegant, but is a
> lot more complicated, so if the above is workable, it provides a much
> shorter term path for solving the buildsys problem.

--
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 Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
> > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > > > James Morris (jmorris@namei.org) said:
> > > > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > > > later releases.
> > > > > > >
> > > > > > > Ok, that's what I suspected.
> > > > > > >
> > > > > > > One of the possible plans for this is to allow a process to run in a
> > > > > > > separate policy namespace, and probably also utilize namespace support in
> > > > > > > general.
> > > > > > >
> > > > > > > This is non-trivial and needs more analysis.
> > > > > >
> > > > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > > > rather than a monolithic one.
> > > > >
> > > > > I assume you mean setting down unknown file labels rather than
> > > > > per-namespace or per-chroot policy support. I think they are related
> > > > > but different. The former is required if you always plan to install the
> > > > > files _before_ loading the policy. The latter is required primarily for
> > > > > getting any scriptlets to run in the right security contexts so that any
> > > > > files they create are labeled appropriately within the chroot.
> > > >
> > > > BTW, for reference, a patch to support setting down unknown file labels
> > > > was posted here a couple of years ago:
> > > > http://marc.info/?l=selinux&m=114771094617968&w=2
> > >
> > > And the last version of that patch was:
> > > http://marc.info/?l=selinux&m=114840466518263&w=2
> > > Not that it applies cleanly anymore, of course.
> >
> > An updated patch and discussion has started over on selinux list, see:
> > http://marc.info/?t=120958955400002&r=1&w=2
> >
> > One question that has come up is whether the patch to support setting
> > unknown file labels is sufficient to support the buildsys needs, or
> > whether something more is required. My impression is that all we truly
> > need is:
> > 1) support for setting unknown file labels for use by rpm, and
> > 2) bind mount /dev/null over selinux/load within the chroot so that
> > policy loads within the chroot do nothing rather than changing the build
> > host's policy, and
> > 3) bind mount a regular empty file over selinux/context within the
> > chroot so that attempts to validate/canonicalize contexts by rpm will
> > always return the original value w/o trying to validate against the
> > build host's policy.
>
> We need to better understand the sequence of actions performed by rpm,
> both from outside the chroot and from within the chroot, to know
> precisely what is needed here.
>
> It would be cleaner if we could just disable policy reload altogether.
> libsemanage will skip policy reload if:
> 1) the caller asked to skip reload (e.g. semodule with the -n option) or
> 2) the caller asked to operate on a policy store other than the active
> policy store (e.g. semodule with the -s option), or
> 3) SELinux appears to be disabled.
>
> We can fake the last one, but I think that will confuse rpm with respect
> to other actions we still want it to take, like labeling the files,
> transitioning to a scriptlet domain, etc.

In this case is scriptlet transition really important? What is to be
gained? Its not like we are getting file transitions...

>
> On the context validation/canonicalization, it would be cleaner if we
> could have rpm validate and canonicalize against the target image's
> policy rather than the build host's policy. This is likely doable, as
> setfiles has to do something like this for its -c option when validating
> a file contexts configuration against a policy at policy build time.
> Requires calling a libselinux interface to register an alternative
> validate callback.

This sounds like a great idea, but is clearly going to take work from
the RPM people....

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

On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote:
> On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
> > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
> > > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
> > > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
> > > > > > > James Morris (jmorris@namei.org) said:
> > > > > > > > > You cannot create files in a chroot of a context not known by the
> > > > > > > > > host policy. This means that if your host is running RHEL 5, you are
> > > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for
> > > > > > > > > later releases.
> > > > > > > >
> > > > > > > > Ok, that's what I suspected.
> > > > > > > >
> > > > > > > > One of the possible plans for this is to allow a process to run in a
> > > > > > > > separate policy namespace, and probably also utilize namespace support in
> > > > > > > > general.
> > > > > > > >
> > > > > > > > This is non-trivial and needs more analysis.
> > > > > > >
> > > > > > > Incidentally, this is also one of the blockers for policy-in-packages,
> > > > > > > rather than a monolithic one.
> > > > > >
> > > > > > I assume you mean setting down unknown file labels rather than
> > > > > > per-namespace or per-chroot policy support. I think they are related
> > > > > > but different. The former is required if you always plan to install the
> > > > > > files _before_ loading the policy. The latter is required primarily for
> > > > > > getting any scriptlets to run in the right security contexts so that any
> > > > > > files they create are labeled appropriately within the chroot.
> > > > >
> > > > > BTW, for reference, a patch to support setting down unknown file labels
> > > > > was posted here a couple of years ago:
> > > > > http://marc.info/?l=selinux&m=114771094617968&w=2
> > > >
> > > > And the last version of that patch was:
> > > > http://marc.info/?l=selinux&m=114840466518263&w=2
> > > > Not that it applies cleanly anymore, of course.
> > >
> > > An updated patch and discussion has started over on selinux list, see:
> > > http://marc.info/?t=120958955400002&r=1&w=2
> > >
> > > One question that has come up is whether the patch to support setting
> > > unknown file labels is sufficient to support the buildsys needs, or
> > > whether something more is required. My impression is that all we truly
> > > need is:
> > > 1) support for setting unknown file labels for use by rpm, and
> > > 2) bind mount /dev/null over selinux/load within the chroot so that
> > > policy loads within the chroot do nothing rather than changing the build
> > > host's policy, and
> > > 3) bind mount a regular empty file over selinux/context within the
> > > chroot so that attempts to validate/canonicalize contexts by rpm will
> > > always return the original value w/o trying to validate against the
> > > build host's policy.
> >
> > We need to better understand the sequence of actions performed by rpm,
> > both from outside the chroot and from within the chroot, to know
> > precisely what is needed here.
> >
> > It would be cleaner if we could just disable policy reload altogether.
> > libsemanage will skip policy reload if:
> > 1) the caller asked to skip reload (e.g. semodule with the -n option) or
> > 2) the caller asked to operate on a policy store other than the active
> > policy store (e.g. semodule with the -s option), or
> > 3) SELinux appears to be disabled.
> >
> > We can fake the last one, but I think that will confuse rpm with respect
> > to other actions we still want it to take, like labeling the files,
> > transitioning to a scriptlet domain, etc.
>
> In this case is scriptlet transition really important? What is to be
> gained? Its not like we are getting file transitions...

IIRC, failure to transition to rpm_script_t has caused problems in the
past, either with denials or subsequent domain transitions or subsequent
file transitions.

If we could ensure that rpm and forked children prior to exec continue
to see SELinux as enabled while faking selinux-disabled status when
running semodule and semanage, then that might work.

As a reminder, is_selinux_enabled() returns 1 if:
1) selinuxfs was found mounted on /selinux at startup, or
2) selinuxfs was found in /proc/mounts (mounted elsewhere) at startup,
or
3) selinuxfs is found in /proc/filesystems,

Thus, merely failing to mount selinuxfs within the chroot does not yield
selinux-disabled status. You'd have to also not mount /proc. Or
override is_selinux_enabled() in your own shared object.

> >
> > On the context validation/canonicalization, it would be cleaner if we
> > could have rpm validate and canonicalize against the target image's
> > policy rather than the build host's policy. This is likely doable, as
> > setfiles has to do something like this for its -c option when validating
> > a file contexts configuration against a policy at policy build time.
> > Requires calling a libselinux interface to register an alternative
> > validate callback.
>
> This sounds like a great idea, but is clearly going to take work from
> the RPM people....
--
Stephen Smalley
National Security Agency

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