3:57 p.m.
As announced on fedora-devel-list[1], we'd like to come to a resolution
(consensus, actions) on the challenges we have with SELinux in the
Fedora build system.
I expect the following:
* 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
One example of a project blocking on this work is the Fedora spin
server. We would have to put a non-SELinux secured server in the loop
somewhere for the actual spin building, and any way we do that is going
to be hacky and whacky.
The main problem I see outside of the technical issues is a marketing
one. Fedora's infrastructure is a set of open tools that anyone can
download and make work themselves. We know that people do that. Fedora
Infrastructure is a feature producer; just as Fedora Docs supplies a
full-course documentation toolchain, so does Infrastructure supply a
full-course FLOSS project toolset.[2]
We do *not* want to be explaining that a new feature doesn't work with
SELinux. At the very minimum, we have been consistent about the value
of SELinux in Fedora, and to ship something as a Fedora feature that
cannot run under SELinux ... well, that would be bad.
This is why other Fedora folks are asking the Fedora SELinux team to
take this off the backburner.
Thanks - Karsten
[1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01064.html
[2] Yep, that's right; Fedora Infrastructure is a feature of Fedora.
For example, the new grid project 'Fedora Sleepwalker' is looking to get
integrated into firstboot or some kind of JoinBuddy. When that happens,
adding your install to the Fedora Sleepwalker grid is going to be touted
as a major feature for that release.
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
6:45 p.m.
On Wed, 16 Apr 2008, Karsten 'quaid' Wade wrote:
As announced on fedora-devel-list[1], we'd like to come to a
resolution
(consensus, actions) on the challenges we have with SELinux in the
Fedora build system.
I expect the following:
* 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?
--
James Morris
<jmorris(a)namei.org>
7:14 p.m.
> the challenges we have with SELinux in the Fedora build system.
Can you please explain specifically what the problem is?
One of the problems is that the result of a pungi compose that is performed
with SELinux enforcing, does not install SELinux enabled by default,
because [a chain of events] the DVD/CD does not contain the policy file,
partly because under enforcing you cannot create a virtualized /dev/null
that has the right context.
http://bugzilla.redhat.com/show_bug.cgi?id=343861
http://bugzilla.redhat.com/show_bug.cgi?id=343851
The workaround is "setenforce 0" during the pungi compose.
In general, it looks to me like SELinux itself cannot be virtualized.
[I really didn't expect it, but nevertheless I cannot find it.]
This means that any time you want to "fake it", then you must
turn off enforcing, or create a full virtualized OS instance
that has enforcing off.
--
7:22 p.m.
James Morris (jmorris(a)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
7:43 p.m.
On Wed, 16 Apr 2008, Bill Nottingham wrote:
James Morris (jmorris(a)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.
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.
- James
--
James Morris
<jmorris(a)namei.org>
9:24 p.m.
On Thu, 2008-04-17 at 10:43 +1000, James Morris wrote:
On Wed, 16 Apr 2008, Bill Nottingham wrote:
> James Morris (jmorris(a)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.
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.
Thanks. When we get to the point of needing to justify resource
allocation on the Red Hat side, I'm here to present the "Fedora
leadership request", if needed. Otherwise, not sure if this is going to
be important enough to the intersecting sets of Fedoran and SELinux
hacker who are not part of the @redhat.com set.
- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
10:23 p.m.
James Morris (jmorris(a)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.
Bill
8:12 a.m.
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris(a)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.
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
10:55 a.m.
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(a)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
11:38 a.m.
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(a)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
11:58 a.m.
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(a)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
12:20 p.m.
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(a)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
8:35 a.m.
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(a)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
9:07 a.m.
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(a)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....
9:24 a.m.
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(a)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
12:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen Smalley wrote:
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(a)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....
I think a lot of this is experimental. The easiest thing
would to first
get livecd creation to work. Once we have a workable solution there we
could probably extend it to Mock and other parts of the Fedora
Infrastructure.
Offhand we need to handle calls made by semodule, restorecon/setfiles,
potential problems with udev, rpmscript execution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkggm+YACgkQrlYvE4MpobN25wCeITCT9Kj4QlgIk/mVKEaH7eAD
ahIAn2iwFNxqQdOp56M8c1dQcPASuSj2
=IJzJ
-----END PGP SIGNATURE-----
2:33 p.m.
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
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.
So I ran livecd-creator today with a couple of things inside the
chroot /selinux
load -> /dev/null
null -> /dev/null
context = [blank file]
mls = 1
enforcing = 1
policyvers = 22
This was attempting to build a F9 livecd on an F9 box, so I wasn't
worried about the labeling issues (although the kernel in question is
patched to support unknown labels)
Things blew up spectacularly :)
warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
Installing: libgcc ##################### [ 1/129]
error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
Installing: setup ##################### [ 2/129]
error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon
Installing: filesystem ##################### [ 3/129]
error: unpacking of archive failed on file /: cpio: lsetfilecon
Installing: basesystem ##################### [ 4/129]
Installing: ncurses-base ##################### [ 5/129]
error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon
So I took a look at what's in "context" and I see
"t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this
is a libselinux function using this. I wonder if I change that to use
O_TRUNC if things would go a bit more smoothly....
-Eric
3 p.m.
On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> 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.
So I ran livecd-creator today with a couple of things inside the
chroot /selinux
load -> /dev/null
null -> /dev/null
context = [blank file]
mls = 1
enforcing = 1
policyvers = 22
This was attempting to build a F9 livecd on an F9 box, so I wasn't
worried about the labeling issues (although the kernel in question is
patched to support unknown labels)
Things blew up spectacularly :)
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?
warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
Installing: libgcc ##################### [ 1/129]
error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
Installing: setup ##################### [ 2/129]
Installing: filesystem ##################### [ 3/129]
Installing: basesystem ##################### [ 4/129]
Installing: ncurses-base ##################### [ 5/129]
Installing: tzdata ##################### [ 6/129]
Installing: rootfiles ##################### [ 7/129]
Installing: glibc ##################### [ 8/129]
error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
Installing: ncurses-libs ##################### [ 9/129]
error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255
Installing: popt ##################### [ 10/129]
error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
Installing: zlib ##################### [ 11/129]
error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255
5:48 p.m.
On Fri, 09 May 2008 16:00:17 -0400
Eric Paris <eparis(a)redhat.com> wrote:
On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > 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.
>
> So I ran livecd-creator today with a couple of things inside the
> chroot /selinux
>
> load -> /dev/null
> null -> /dev/null
> context = [blank file]
> mls = 1
> enforcing = 1
> policyvers = 22
>
> This was attempting to build a F9 livecd on an F9 box, so I wasn't
> worried about the labeling issues (although the kernel in question
> is patched to support unknown labels)
>
> Things blew up spectacularly :)
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?
warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID
4f2a6fd2 Installing: libgcc
##################### [ 1/129] error: %post(libgcc-4.3.0-8.x86_64)
scriptlet failed, exit status 255 Installing:
setup ##################### [ 2/129]
Installing: filesystem #####################
[ 3/129] Installing: basesystem
##################### [ 4/129] Installing:
ncurses-base ##################### [ 5/129]
Installing: tzdata #####################
[ 6/129] Installing: rootfiles
##################### [ 7/129] Installing:
glibc ##################### [ 8/129] error:
%post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
Installing: ncurses-libs #####################
[ 9/129] error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64)
scriptlet failed, exit status 255 Installing:
popt ##################### [ 10/129] error:
%post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
Installing: zlib #####################
[ 11/129] error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed,
exit status 255
These all look like library packages so I'd hazard a guess that the
thing that's failing is ldconfig. Perhaps you could replace ldconfig
with a wrapper than runs it under strace?
Paul.
7:17 a.m.
On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > 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.
>
> So I ran livecd-creator today with a couple of things inside the
> chroot /selinux
>
> load -> /dev/null
> null -> /dev/null
> context = [blank file]
> mls = 1
> enforcing = 1
> policyvers = 22
>
> This was attempting to build a F9 livecd on an F9 box, so I wasn't
> worried about the labeling issues (although the kernel in question is
> patched to support unknown labels)
>
> Things blew up spectacularly :)
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.
warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID
4f2a6fd2
Installing: libgcc ##################### [ 1/129]
error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
Installing: setup ##################### [ 2/129]
Installing: filesystem ##################### [ 3/129]
Installing: basesystem ##################### [ 4/129]
Installing: ncurses-base ##################### [ 5/129]
Installing: tzdata ##################### [ 6/129]
Installing: rootfiles ##################### [ 7/129]
Installing: glibc ##################### [ 8/129]
error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255
Installing: ncurses-libs ##################### [ 9/129]
error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255
Installing: popt ##################### [ 10/129]
error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255
Installing: zlib ##################### [ 11/129]
error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255
--
Stephen Smalley
National Security Agency
3:33 p.m.
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 :-/
Jeremy
4:05 p.m.
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj(a)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.
4:19 p.m.
On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley
<stephen.smalley(a)gmail.com> wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj(a)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.
4:26 p.m.
On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz <katzj(a)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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /bin context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/rvi context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/touch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/mountpoint context
unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0
/sbin/restorecon reset /bin/arch context
unconfined_u:object_r:file_t:s0->system_u:object_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_notrans_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_notrans_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
7:44 a.m.
On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis(a)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(a)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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /bin context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/rvi context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/touch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
/sbin/restorecon reset /bin/mountpoint context
unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0
/sbin/restorecon reset /bin/arch context
unconfined_u:object_r:file_t:s0->system_u:object_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_notrans_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_notrans_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
8:03 a.m.
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis(a)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\n 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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
> /sbin/restorecon reset /bin context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
> /sbin/restorecon reset /bin/rvi context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
> /sbin/restorecon reset /bin/touch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
> /sbin/restorecon reset /bin/mountpoint context
unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0
> /sbin/restorecon reset /bin/arch context
unconfined_u:object_r:file_t:s0->system_u:object_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_notrans_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_notrans_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
>
>
8:10 a.m.
-----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(a)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\n 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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
>> /sbin/restorecon reset /bin context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
>> /sbin/restorecon reset /bin/rvi context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
>> /sbin/restorecon reset /bin/touch context
unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0
>> /sbin/restorecon reset /bin/mountpoint context
unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0
>> /sbin/restorecon reset /bin/arch context
unconfined_u:object_r:file_t:s0->system_u:object_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_notrans_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_notrans_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(a)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
iEYEARECAAYFAkgpk0QACgkQrlYvE4MpobPk4ACguXKMnC7uUM9jaqont/bxthSI
ZlYAnRvebyTJ54f9RdSEkjHUZ/I/cwPE
=LiD+
-----END PGP SIGNATURE-----
8:15 a.m.
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(a)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\n 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
9:36 a.m.
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris <eparis(a)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(a)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_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/stdin context
unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/random context
unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0
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?
9:46 a.m.
On Tue, 2008-05-13 at 10:36 -0400, Eric Paris wrote:
> I'm not sure you need anything there; as I've said,
> is_selinux_enabled() will just fall back to checking /proc/filesystems
> for selinuxfs as the authoritative indicator of whether or not SELinux
> is enabled.
But we have other problems without /selinux mounted inside the chroot
(and this is without the rpm_execcon patch which I'm about to put in,
does rpm statically or dynamically link?) :(
Looks like rpm and rpmi are dynamically linked. Don't know if there is
a static version somewhere for bootstrapping.
New, Interesting and different at least:
Installing: selinux-policy ##################### [128/129]
Installing: selinux-policy-targeted ##################### [129/129]
libsemanage.dbase_llist_query: could not query record value
libsepol.policydb_write: policy version 15 cannot support MLS
I assume this is because there isn't an selinux/policyvers?
Yes, but all of this flows from the fact that semodule/libsemanage are
trying to actually load a new policy. Which they wouldn't if we
completely faked that SELinux was disabled within the chroot by making a
fake /proc/filesystems. But allegedly that breaks rpm? Which I don't
fully understand as it should just check whether SELinux is enabled
prior to chroot'ing and keep using that saved enabled status throughout
IMHO. Or if you invoked semodule with -n it wouldn't try to reload.
If all else fails, I suppose you could create a /selinux/policyvers
and /selinux/mls to try to appease it. And maybe still a /dev/null link
as /selinux/load to appease policy load.
libsepol.policydb_to_image: could not compute policy length
libsepol.policydb_to_image: could not create policy image
SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23,
searching for an older version.
SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No
such file or directory
/usr/sbin/load_policy: Can't load policy: No such file or directory
Yes, trying to load policy is the root problem here. So ideally we'd
just disable that altogether as above or failing that fake it as above.
ERROR:dbus.proxies:Introspect error on
:1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security policy blocked the
reply, the reply timeout expired, or the network connection was broken.
That might just be a bug in the host policy, not allowing something that
ought to be allowed and that only happens to get triggered here.
/sbin/restorecon reset /dev/stderr context
unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/stdin context
unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0
/sbin/restorecon reset /dev/random context
unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0
That may make sense given that udev manages device node labels for us
these days. But /dev/stderr is just a symlink to /proc/self/fd/2
anyway, right?
There were actually a whole lot less when the restorecon ran through
(still a bunch but a lot less), so I think that part is better.
After the restorecon finished and before the e2fsck I got:
Only root can do that.
Anyone have ideas what that might have been?
mount would do that if it didn't think it was running as root.
--
Stephen Smalley
National Security Agency
11:06 a.m.
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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /lib context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
We are back to calling restorecon on every single file.....
-Eric
11:53 a.m.
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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /lib context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_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
12:27 p.m.
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
3:38 p.m.
> ^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
1:36 p.m.
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
2:10 p.m.
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
11:55 a.m.
-----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_u:object_r:file_t:s0->system_u:object_r:root_t:s0
/sbin/restorecon reset /lib context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
/sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context
unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0
We are back to calling restorecon on every single file.....
-Eric
--
fedora-selinux-list mailing list
fedora-selinux-list(a)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
iEYEARECAAYFAkgpyBkACgkQrlYvE4MpobNUlACbBN5WJvv0IUH6Voq3L2GgLIej
MXYAn3ja4+e8pZpHQTXbctm5fYIe9UOj
=a9ex
-----END PGP SIGNATURE-----
12:29 p.m.
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
5:50 p.m.
On Tue, 13 May 2008 12:29:30 -0500
Dennis Gilmore <dennis(a)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.
7:08 a.m.
On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> 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.
So I ran livecd-creator today with a couple of things inside the
chroot /selinux
load -> /dev/null
null -> /dev/null
context = [blank file]
mls = 1
enforcing = 1
policyvers = 22
This was attempting to build a F9 livecd on an F9 box, so I wasn't
worried about the labeling issues (although the kernel in question is
patched to support unknown labels)
Things blew up spectacularly :)
warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
Installing: libgcc ##################### [ 1/129]
error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
Installing: setup ##################### [ 2/129]
error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon
Installing: filesystem ##################### [ 3/129]
error: unpacking of archive failed on file /: cpio: lsetfilecon
Installing: basesystem ##################### [ 4/129]
Installing: ncurses-base ##################### [ 5/129]
error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon
So I took a look at what's in "context" and I see
"t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this
is a libselinux function using this. I wonder if I change that to use
O_TRUNC if things would go a bit more smoothly....
I think it would be better to just adjust userspace as we discussed to
perform context validation against the target policy rather than the
build host policy as is done by setfiles -c.
Or disable context validation altogether in userspace in that instance.
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.
--
Stephen Smalley
National Security Agency
9:45 a.m.
On Mon, 2008-05-12 at 08:08 -0400, Stephen Smalley wrote:
On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > 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.
>
> So I ran livecd-creator today with a couple of things inside the
> chroot /selinux
>
> load -> /dev/null
> null -> /dev/null
> context = [blank file]
> mls = 1
> enforcing = 1
> policyvers = 22
>
> This was attempting to build a F9 livecd on an F9 box, so I wasn't
> worried about the labeling issues (although the kernel in question is
> patched to support unknown labels)
>
> Things blew up spectacularly :)
>
> warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
> Installing: libgcc ##################### [ 1/129]
> error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
> Installing: setup ##################### [ 2/129]
> error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon
> Installing: filesystem ##################### [ 3/129]
> error: unpacking of archive failed on file /: cpio: lsetfilecon
> Installing: basesystem ##################### [ 4/129]
> Installing: ncurses-base ##################### [ 5/129]
> error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon
>
> So I took a look at what's in "context" and I see
> "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this
> is a libselinux function using this. I wonder if I change that to use
> O_TRUNC if things would go a bit more smoothly....
I think it would be better to just adjust userspace as we discussed to
perform context validation against the target policy rather than the
build host policy as is done by setfiles -c.
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....
Or disable context validation altogether in userspace in that
instance.
Anyone have suggestions on how to go about this?
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.
9:53 a.m.
On Mon, 2008-05-12 at 10:45 -0400, Eric Paris wrote:
On Mon, 2008-05-12 at 08:08 -0400, Stephen Smalley wrote:
> On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote:
> > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
> > > 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.
> >
> > So I ran livecd-creator today with a couple of things inside the
> > chroot /selinux
> >
> > load -> /dev/null
> > null -> /dev/null
> > context = [blank file]
> > mls = 1
> > enforcing = 1
> > policyvers = 22
> >
> > This was attempting to build a F9 livecd on an F9 box, so I wasn't
> > worried about the labeling issues (although the kernel in question is
> > patched to support unknown labels)
> >
> > Things blew up spectacularly :)
> >
> > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
> > Installing: libgcc ##################### [ 1/129]
> > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255
> > Installing: setup ##################### [ 2/129]
> > error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon
> > Installing: filesystem ##################### [ 3/129]
> > error: unpacking of archive failed on file /: cpio: lsetfilecon
> > Installing: basesystem ##################### [ 4/129]
> > Installing: ncurses-base ##################### [ 5/129]
> > error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon
> >
> > So I took a look at what's in "context" and I see
> > "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume
this
> > is a libselinux function using this. I wonder if I change that to use
> > O_TRUNC if things would go a bit more smoothly....
>
> I think it would be better to just adjust userspace as we discussed to
> perform context validation against the target policy rather than the
> build host policy as is done by setfiles -c.
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*.
> 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.
--
Stephen Smalley
National Security Agency
3:33 p.m.
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.
10:26 a.m.
Eric Paris (eparis(a)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'.
Bill
3:33 p.m.
On Mon, 2008-05-12 at 11:26 -0400, Bill Nottingham wrote:
Eric Paris (eparis(a)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
9:02 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Nottingham wrote:
James Morris (jmorris(a)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(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkgN7/wACgkQrlYvE4MpobNzEgCgysNQd6+WuH9GrSSTJy2YZuwd
cNwAn2ioJTeBG416OT+CITaKwoAjWsC9
=/F7+
-----END PGP SIGNATURE-----
9:58 a.m.
Bill Nottingham wrote:
> James Morris (jmorris(a)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(a)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.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
10:11 a.m.
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
> Bill Nottingham wrote:
> > James Morris (jmorris(a)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(a)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.
How about changes to selinuxfs?
mount selinuxfs /chroot/selinux -t selinuxfs -o ro
if we are mounted with ro we make everything inside ro so the process
inside the chroot using the chroot version of selinuxfs couldn't screw
the system.
Still doesn't allow laying down invalid types on disk, is that a problem
today? Although I didn't like the rpm demands for illegal types this
seems like a case where we might want to take that patch...
-Eric
10:59 a.m.
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
> Bill Nottingham wrote:
> > James Morris (jmorris(a)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(a)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
2:20 p.m.
-----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(a)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(a)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
iEYEARECAAYFAkgOOnAACgkQrlYvE4MpobNtGgCdGbX4swbPMBsnC+BpL6PTNEWM
x4QAoKd+OpqR7ycGKZviGeb+ywYnQyjE
=O3UV
-----END PGP SIGNATURE-----
10:56 a.m.
On Tue, Apr 22, 2008 at 3:20 PM, Daniel J Walsh <dwalsh(a)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(a)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(a)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
5825
days inactive
5854
days old
selinux@lists.fedoraproject.org
50 comments
13 participants
participants (13)
-
Bill Nottingham -
Daniel J Walsh -
Dennis Gilmore -
Eric Paris -
James Morris -
Jeremy Katz -
John Reiser -
Karsten Wade -
max -
Paul Howarth -
Stephen Smalley -
Stephen Smalley -
Tomas Mraz