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.