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.
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?
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.
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
On Wed, 16 Apr 2008, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
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
On Thu, 2008-04-17 at 10:43 +1000, James Morris wrote:
On Wed, 16 Apr 2008, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
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
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
Bill
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
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.
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
But unfortunately we weren't able to sort the remaining issues discussed in that thread.
Also, I wanted to emphasize that chroot is different than unsharing the filesystem namespace, and per-chroot policy is not the same thing as per-namespace policy. I'd expect though that it would actually be a per-process policy mechanism, with most processes sharing the same policy but programs like rpm being able to unshare policy from their parent and then load a private policy to be applied only to their descendants.
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
But unfortunately we weren't able to sort the remaining issues discussed in that thread.
Also, I wanted to emphasize that chroot is different than unsharing the filesystem namespace, and per-chroot policy is not the same thing as per-namespace policy. I'd expect though that it would actually be a per-process policy mechanism, with most processes sharing the same policy but programs like rpm being able to unshare policy from their parent and then load a private policy to be applied only to their descendants.
On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
Note for anyone trying to revive that patch: please be sure to introduce a new security class for that permission instead of adding it to the security class as I did in that patch, so that we can be certain that this new ability won't be allowed to unconfined domains by default. We do not want unconfined_t user shells to be able to set arbitrary label values w/o no warning that it wasn't valid; we want to limit this to specific programs like rpm that will be aware of the implications and (hopefully) do some validity checking of their own afterward.
On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
An updated patch and discussion has started over on selinux list, see: http://marc.info/?t=120958955400002&r=1&w=2
One question that has come up is whether the patch to support setting unknown file labels is sufficient to support the buildsys needs, or whether something more is required. My impression is that all we truly need is: 1) support for setting unknown file labels for use by rpm, and 2) bind mount /dev/null over selinux/load within the chroot so that policy loads within the chroot do nothing rather than changing the build host's policy, and 3) bind mount a regular empty file over selinux/context within the chroot so that attempts to validate/canonicalize contexts by rpm will always return the original value w/o trying to validate against the build host's policy.
Plus the associated policy changes to permit the above to take place. Does that sufficient?
The per-chroot/namespace policy idea sounds nice and elegant, but is a lot more complicated, so if the above is workable, it provides a much shorter term path for solving the buildsys problem.
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
> You cannot create files in a chroot of a context not known by the > host policy. This means that if your host is running RHEL 5, you are > unable to compose any trees/images/livecds with SELinux enabled for > later releases.
Ok, that's what I suspected.
One of the possible plans for this is to allow a process to run in a separate policy namespace, and probably also utilize namespace support in general.
This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
An updated patch and discussion has started over on selinux list, see: http://marc.info/?t=120958955400002&r=1&w=2
One question that has come up is whether the patch to support setting unknown file labels is sufficient to support the buildsys needs, or whether something more is required. My impression is that all we truly need is:
- support for setting unknown file labels for use by rpm, and
- 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.
On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote:
James Morris (jmorris@namei.org) said: > > You cannot create files in a chroot of a context not known by the > > host policy. This means that if your host is running RHEL 5, you are > > unable to compose any trees/images/livecds with SELinux enabled for > > later releases. > > Ok, that's what I suspected. > > One of the possible plans for this is to allow a process to run in a > separate policy namespace, and probably also utilize namespace support in > general. > > This is non-trivial and needs more analysis.
Incidentally, this is also one of the blockers for policy-in-packages, rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
An updated patch and discussion has started over on selinux list, see: http://marc.info/?t=120958955400002&r=1&w=2
One question that has come up is whether the patch to support setting unknown file labels is sufficient to support the buildsys needs, or whether something more is required. My impression is that all we truly need is:
- support for setting unknown file labels for use by rpm, and
- 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:
- the caller asked to skip reload (e.g. semodule with the -n option) or
- 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....
On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote:
On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote:
On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote:
On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote:
On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote:
On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: > James Morris (jmorris@namei.org) said: > > > You cannot create files in a chroot of a context not known by the > > > host policy. This means that if your host is running RHEL 5, you are > > > unable to compose any trees/images/livecds with SELinux enabled for > > > later releases. > > > > Ok, that's what I suspected. > > > > One of the possible plans for this is to allow a process to run in a > > separate policy namespace, and probably also utilize namespace support in > > general. > > > > This is non-trivial and needs more analysis. > > Incidentally, this is also one of the blockers for policy-in-packages, > rather than a monolithic one.
I assume you mean setting down unknown file labels rather than per-namespace or per-chroot policy support. I think they are related but different. The former is required if you always plan to install the files _before_ loading the policy. The latter is required primarily for getting any scriptlets to run in the right security contexts so that any files they create are labeled appropriately within the chroot.
BTW, for reference, a patch to support setting down unknown file labels was posted here a couple of years ago: http://marc.info/?l=selinux&m=114771094617968&w=2
And the last version of that patch was: http://marc.info/?l=selinux&m=114840466518263&w=2 Not that it applies cleanly anymore, of course.
An updated patch and discussion has started over on selinux list, see: http://marc.info/?t=120958955400002&r=1&w=2
One question that has come up is whether the patch to support setting unknown file labels is sufficient to support the buildsys needs, or whether something more is required. My impression is that all we truly need is:
- support for setting unknown file labels for use by rpm, and
- 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:
- the caller asked to skip reload (e.g. semodule with the -n option) or
- 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....
-----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@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:
- support for setting unknown file labels for use by rpm, and
- 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:
- the caller asked to skip reload (e.g. semodule with the -n option) or
- 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:
- selinuxfs was found mounted on /selinux at startup, or
- 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.
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:
- support for setting unknown file labels for use by rpm, and
- 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
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:
- support for setting unknown file labels for use by rpm, and
- 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
On Fri, 09 May 2008 16:00:17 -0400 Eric Paris eparis@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:
- support for setting unknown file labels for use by rpm, and
- 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.
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:
- support for setting unknown file labels for use by rpm, and
- 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
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
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz katzj@redhat.com wrote:
On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote:
On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
So I added O_TRUNC to both of the callers to /selinux/context in libselinux and that took care of the lsetfilecon() crap but I still get tons and tons of "scriptlet failed, exit status 255"
Anyone have ideas/suggestions how to debug those more?
Ah, it is likely failing on the rpm_execcon(3) -> security_compute_create(3) call i.e. writing to /selinux/create. Which computes the context in which to run the scriptlet or helper from the policy. If that returns the same as rpm's own context, then we fall back to rpm_script_t. So this affects things like ldconfig.
I increasingly suspect we're better off not mounting selinuxfs within the chroot at all and addressing any issues that arise via policy.
If we don't mount selinuxfs, then anything that attempts to figure out if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled to determine whether or not to set the xattrs) will fail. Also, I don't remember for certain without looking, but even restorecon checks like that from what I remember. So we have to at least have some of /selinux present or we have to do deeper tricks with labeling outside of chroots which ... pain :-/
That shouldn't actually be true - the fundamental test for whether or not SELinux is enabled is the presence or absence of selinuxfs in /proc/filesystems (i.e. is it registered in the kernel), not whether or not selinuxfs is actually mounted anywhere. The libselinux logic should fall back to that /proc/filesystems test.
And looking at the libselinux code, it does appear to handle ENOENT on /selinux/context by skipping the normal context validation, so not having it present at all in /selinux within the chroot should help _unless_ rpm calls matchpathcon() will outside of the chroot (that's what I'm unclear on - when rpm is operating within the chroot and when it is operating outside the chroot).
The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain; it should just fall back to a normal execve() in that situation. Which could be addressed in policy largely by collapsing rpm_script_t and rpm_t into a single domain. I'm not sure how much we are using the distinction at present - I think they are both effectively unconfined so it would only differ possibly in outbound type transitions.
Anyway, I'd be interested in having Eric try the install with no selinuxfs mounted or fake selinux nodes within the chroot and see what happens, both in permissive mode and enforcing mode.
On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley stephen.smalley@gmail.com wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz katzj@redhat.com wrote:
On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote:
On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote:
So I added O_TRUNC to both of the callers to /selinux/context in libselinux and that took care of the lsetfilecon() crap but I still get tons and tons of "scriptlet failed, exit status 255"
Anyone have ideas/suggestions how to debug those more?
Ah, it is likely failing on the rpm_execcon(3) -> security_compute_create(3) call i.e. writing to /selinux/create. Which computes the context in which to run the scriptlet or helper from the policy. If that returns the same as rpm's own context, then we fall back to rpm_script_t. So this affects things like ldconfig.
I increasingly suspect we're better off not mounting selinuxfs within the chroot at all and addressing any issues that arise via policy.
If we don't mount selinuxfs, then anything that attempts to figure out if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled to determine whether or not to set the xattrs) will fail. Also, I don't remember for certain without looking, but even restorecon checks like that from what I remember. So we have to at least have some of /selinux present or we have to do deeper tricks with labeling outside of chroots which ... pain :-/
That shouldn't actually be true - the fundamental test for whether or not SELinux is enabled is the presence or absence of selinuxfs in /proc/filesystems (i.e. is it registered in the kernel), not whether or not selinuxfs is actually mounted anywhere. The libselinux logic should fall back to that /proc/filesystems test.
And looking at the libselinux code, it does appear to handle ENOENT on /selinux/context by skipping the normal context validation, so not having it present at all in /selinux within the chroot should help _unless_ rpm calls matchpathcon() will outside of the chroot (that's what I'm unclear on - when rpm is operating within the chroot and when it is operating outside the chroot).
The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain;
Ah, sorry - I misspoke above. Since is_selinux_enabled() ultimately comes down to presence/absence of selinuxfs in /proc/filesystems, rpm_execcon() will see SELinux as enabled but the security_compute_create() call will fail and this will cause it to abort rather than execve(). That's the problem Eric presently has. So possibly changing rpm_execcon() to fall back to setting the default domain to rpm_script_t and proceeding if security_compute_create() fails would allow him to proceed. That would still leave us in rpm_script_t rather than ldconfig_t, so we'd have a labeling problem, but that's likely fixable via a selective restorecon after the fact.
it should just fall back to a normal execve() in that situation. Which could be addressed in policy largely by collapsing rpm_script_t and rpm_t into a single domain. I'm not sure how much we are using the distinction at present - I think they are both effectively unconfined so it would only differ possibly in outbound type transitions.
Anyway, I'd be interested in having Eric try the install with no selinuxfs mounted or fake selinux nodes within the chroot and see what happens, both in permissive mode and enforcing mode.
On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz katzj@redhat.com wrote:
The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain;
How does it do this check? Guess I should pull some rpm sources. My lord I don't wanna....
Anyway, I'd be interested in having Eric try the install with no selinuxfs mounted or fake selinux nodes within the chroot and see what happens, both in permissive mode and enforcing mode.
I've got my fake selinux mount inside the chroot much like I previously described. /selinux/create is still getting long strings in it that don't make much sense. I guess something is using it directly and not through the libselinux interface?!?!
enforcing=1 /selinux inside the chroot is the little thing that I made up to fake it.
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user guest_u libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user xguest_u
ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. /sbin/restorecon reset / context system_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
On Mon, May 12, 2008 at 5:26 PM, Eric Paris eparis@redhat.com wrote:
On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz katzj@redhat.com wrote:
The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain;
How does it do this check? Guess I should pull some rpm sources. My lord I don't wanna....
You don't have to look at rpm for that - rpm_execcon() is a helper function provided by libselinux for use by rpm. I sent you a patch separately for it that should get it past a missing /selinux/create node, so you should be able to completely remove /selinux/context and /selinux/create and still proceed (at least in permissive mode).
Anyway, I'd be interested in having Eric try the install with no selinuxfs mounted or fake selinux nodes within the chroot and see what happens, both in permissive mode and enforcing mode.
I've got my fake selinux mount inside the chroot much like I previously described. /selinux/create is still getting long strings in it that don't make much sense. I guess something is using it directly and not through the libselinux interface?!?!
No, it is just that /selinux/create is a transactional interface that takes multiple input arguments and returns a single output argument, so using a regular file for it won't work at all. Just remove it and use the patch I supplied for rpm_execcon.
enforcing=1 /selinux inside the chroot is the little thing that I made up to fake it.
I'm not sure you need anything there; as I've said, is_selinux_enabled() will just fall back to checking /proc/filesystems for selinuxfs as the authoritative indicator of whether or not SELinux is enabled.
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u
Hmm...so you are installing a policy with MLS enabled, but tried to add a user without a MLS level. I think this is likely a bug/limitation of semanage, where it tries to deduce whether or not to include the MLS field based on whether the host has MLS enabled. This has come up before on selinux list; we need a libsemanage interface for querying whether MLS is enabled in the policy store vs. on the host. Or you could fake a /selinux/mls node that contains "1".
libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user guest_u libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user xguest_u
ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. /sbin/restorecon reset / context system_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
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris eparis@redhat.com wrote:
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u
Hmm...so you are installing a policy with MLS enabled, but tried to add a user without a MLS level. I think this is likely a bug/limitation of semanage, where it tries to deduce whether or not to include the MLS field based on whether the host has MLS enabled. This has come up before on selinux list; we need a libsemanage interface for querying whether MLS is enabled in the policy store vs. on the host. Or you could fake a /selinux/mls node that contains "1".
I have one that has a 1\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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Paris wrote:
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris eparis@redhat.com wrote:
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u
Hmm...so you are installing a policy with MLS enabled, but tried to add a user without a MLS level. I think this is likely a bug/limitation of semanage, where it tries to deduce whether or not to include the MLS field based on whether the host has MLS enabled. This has come up before on selinux list; we need a libsemanage interface for querying whether MLS is enabled in the policy store vs. on the host. Or you could fake a /selinux/mls node that contains "1".
I have one that has a 1\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@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.
On Tue, 2008-05-13 at 09:03 -0400, Eric Paris wrote:
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris eparis@redhat.com wrote:
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u
Hmm...so you are installing a policy with MLS enabled, but tried to add a user without a MLS level. I think this is likely a bug/limitation of semanage, where it tries to deduce whether or not to include the MLS field based on whether the host has MLS enabled. This has come up before on selinux list; we need a libsemanage interface for querying whether MLS is enabled in the policy store vs. on the host. Or you could fake a /selinux/mls node that contains "1".
I have one that has a 1\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.
On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 5:26 PM, Eric Paris eparis@redhat.com wrote:
On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote:
On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz katzj@redhat.com wrote:
The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain;
How does it do this check? Guess I should pull some rpm sources. My lord I don't wanna....
You don't have to look at rpm for that - rpm_execcon() is a helper function provided by libselinux for use by rpm. I sent you a patch separately for it that should get it past a missing /selinux/create node, so you should be able to completely remove /selinux/context and /selinux/create and still proceed (at least in permissive mode).
Will do.....
I'm not sure you need anything there; as I've said, is_selinux_enabled() will just fall back to checking /proc/filesystems for selinuxfs as the authoritative indicator of whether or not SELinux is enabled.
But we have other problems without /selinux mounted inside the chroot (and this is without the rpm_execcon patch which I'm about to put in, does rpm statically or dynamically link?) :(
New, Interesting and different at least:
Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.policydb_write: policy version 15 cannot support MLS
I assume this is because there isn't an selinux/policyvers?
libsepol.policydb_to_image: could not compute policy length libsepol.policydb_to_image: could not create policy image SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No such file or directory /usr/sbin/load_policy: Can't load policy: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.23. (No such file or directory). semodule: Failed! /usr/sbin/semanage: Invalid prefix user /usr/sbin/semanage: Invalid prefix user
ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
/sbin/restorecon reset /dev/stderr context unconfined_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?
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.
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
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.
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.
^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
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.
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.
-----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@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.
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
On Tue, 13 May 2008 12:29:30 -0500 Dennis Gilmore dennis@ausil.us wrote:
On Tuesday 13 May 2008, Daniel J Walsh wrote:
I don't have a problem with calling restorecon on every single file, since this is a limited number of files. The goal is to allow the chroot to run without mucking around with the host security. So I don't have to run permissive or disabled if I use mock/livecd. If mock/livecd have to relabel when they complete that is fine.
I would really like to enable selinux on the actual builders. Right now it has to be disabled. If not alot of things build ok but certain packages will switch to enforcing inside the chroot when the host is in permissive mode. and it causes all sorts of fun and failed builds.
Which packages do this?
I run my own mock builders with selinux enforcing on F8 and haven't come across anything like that, though obviously the Fedora builders are exposed to a much wider variety of packages than my small collection.
Paul.
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:
- support for setting unknown file labels for use by rpm, and
- 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.
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:
- support for setting unknown file labels for use by rpm, and
- 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.
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:
- support for setting unknown file labels for use by rpm, and
- 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.
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.
On Mon, 2008-05-12 at 11:26 -0400, Bill Nottingham wrote:
Eric Paris (eparis@redhat.com) said:
same problem. Wonder how people would feel about really hacking up the buildroot creator to force install selinux stuff first and then run the full install transaction set....
Due to dependencies, you can never load the policy 'first'.
Just to make this a little bit more explicit for others following along, we can't due this because loading the policy requires that the policy be installed on disk as well as things like load_policy being on disk. That depends on having libc, etc in the chroot as well. So ignoring questions of taste, you'd still have the chicken and egg problem.
But as far as taste as concerned, hacking up every single thing that ever creates a chroot feels wrong, wrong, wrong, wrong, wrong. Especially because it's not little hacks, it's a big hack involving creating a new micro-transaction with only a subset of the packages. It also becomes "interesting" when you start to think about update operations within a chroot.
Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Could it be solved by kernel preventing loading the policy when the process which tries that is in the chroot? It seems to me that it doesn't make any sense to allow that. Then with enabling creating files with a context unknown to the policy the machine could run in enforcing mode although the process which does the compose would of course have to be unconfined.
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Could it be solved by kernel preventing loading the policy when the process which tries that is in the chroot? It seems to me that it doesn't make any sense to allow that. Then with enabling creating files with a context unknown to the policy the machine could run in enforcing mode although the process which does the compose would of course have to be unconfined.
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
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Could it be solved by kernel preventing loading the policy when the process which tries that is in the chroot? It seems to me that it doesn't make any sense to allow that. Then with enabling creating files with a context unknown to the policy the machine could run in enforcing mode although the process which does the compose would of course have to be unconfined.
Why mount selinuxfs within the chroot at all? Policy load isn't possible without selinuxfs.
I had thought though that they wanted/needed to load the policy with scope limited to children of rpm so that package scriptlets will run in the correct domain and files created by them will be labeled as expected for the image being built rather than based on the host policy. Which is rather complicated - it requires a per-process policy pointer and some way to deal with files that may be visible both to scriptlets within the chroot and to rpm and other processes outside of it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen Smalley wrote:
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
- All the parties are here now needed to figure this out
- Someone better than me is going to reply with specifics about what is
not working in the buildsys
- We all agree it's pretty important to get this figured out in a good
way
Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Could it be solved by kernel preventing loading the policy when the process which tries that is in the chroot? It seems to me that it doesn't make any sense to allow that. Then with enabling creating files with a context unknown to the policy the machine could run in enforcing mode although the process which does the compose would of course have to be unconfined.
Why mount selinuxfs within the chroot at all? Policy load isn't possible without selinuxfs.
I had thought though that they wanted/needed to load the policy with scope limited to children of rpm so that package scriptlets will run in the correct domain and files created by them will be labeled as expected for the image being built rather than based on the host policy. Which is rather complicated - it requires a per-process policy pointer and some way to deal with files that may be visible both to scriptlets within the chroot and to rpm and other processes outside of it.
Well currently livecd tools to a relabel at the end. So we still have the problem of the labels being correct when the dvd is complete.
On Tue, Apr 22, 2008 at 3:20 PM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen Smalley wrote:
On Tue, 2008-04-22 at 16:58 +0200, Tomas Mraz wrote:
Bill Nottingham wrote:
James Morris (jmorris@namei.org) said:
> * All the parties are here now needed to figure this out > * Someone better than me is going to reply with specifics about what is > not working in the buildsys > * We all agree it's pretty important to get this figured out in a good > way Can you please explain specifically what the problem is?
You cannot create files in a chroot of a context not known by the host policy. This means that if your host is running RHEL 5, you are unable to compose any trees/images/livecds with SELinux enabled for later releases.
Bill
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Just catching up on this email chain.
The far more insidious problem is the act of loading policy in the chroot effects the kernel of the host. So processes that are running in the host become invalidated when the client loads a policy. This happens even in the case where you are building a chroot environment on the SAME os. Since the spec file is running semanage commands to modify and add unconfined_t users, the unconfined processes of the parent and potential labels become unknown to the kernel for a period of time, which ends up labeling the files and processes as unlabeled_t. When this happens files labeled unlabeled_t can not be accesses by confined process and if a process becomes unlabeled_t it will not be allowed any access on the box, which can cause the process to crash or go into in infinite loop. If I build a livedvd, I end
setenforce 0 livedvd ... load_policy setenforce 1 And sometimes I still need to fixfiles restore
Could it be solved by kernel preventing loading the policy when the process which tries that is in the chroot? It seems to me that it doesn't make any sense to allow that. Then with enabling creating files with a context unknown to the policy the machine could run in enforcing mode although the process which does the compose would of course have to be unconfined.
Why mount selinuxfs within the chroot at all? Policy load isn't possible without selinuxfs.
I had thought though that they wanted/needed to load the policy with scope limited to children of rpm so that package scriptlets will run in the correct domain and files created by them will be labeled as expected for the image being built rather than based on the host policy. Which is rather complicated - it requires a per-process policy pointer and some way to deal with files that may be visible both to scriptlets within the chroot and to rpm and other processes outside of it.
Well currently livecd tools to a relabel at the end. So we still have the problem of the labels being correct when the dvd is complete.
I am trying to keep up with this conversation and I don't expect anyone to stop and explain all this but.... Can the image be built on a remote host?or a virtualized one(i caught but do not completely understand the comment about being unable to virtualize SELinux)? Would this not rather neatly avoid the chroot problem(assuming I am understanding the problem correctly)? Which if i understand it right is that you cannot load policy in the chroot because the policy applies itself or is getting applied to the running kernel even though it is not intended for that kernel but the one in the image, which is of course not running. Perhaps these things have been considered already but are not feasible? Mind you I have no idea how to implement this, I am just beating my little gnat wings off the west coast of Africa hoping I can cause the typhoon in south america. I haven't been able to find much in the way of documentation on the fedora build system. if anyone has a pointer to good docs, assuming they exist, I would appreciate the link, what little I have found seems incomplete or unfinished.
Max
selinux@lists.fedoraproject.org