SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3

[Russell Coker]

On Monday 16 May 2005 22:11, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote:
> > I've found the problem.
> >
> > The domain anaconda_t seems to be unused (we should probably just delete
> > anaconda.te).  The installation process runs all initial programs from an
> > initrd (gzip compressed cpio file).  cpio has no support for SE Linux
> > labels so no domain transitions occur and everything runs in kernel_t. 
> > Everything that's not in an initrd is in a cramfs file system (which also
> > has no support for SE Linux labelling).  This means that created files
> > get the type of the directory - etc_t in the case of /etc/ld.so.cache.
>
> initrd or initramfs?  Sounds like the latter from your description.  An
> initrd should be able to support a labeled filesystem like ext2, unlike
> initramfs.

initrd.  Sure an initrd can support ext2 with labels, but that's not being 
done at the moment and such a significant change is unlikely to be made to 
the installer in a hurry.

> By created files, you just mean runtime-generated files, right?  Any
> files set down by rpm should be labeled explicitly and correctly by it.

Yes.

> > One possible method of dealing with this would be the following:
> > domain_auto_trans(kernel_t, ldconfig_exec_t, ldconfig_t)
>
> Is ldconfig labeled correctly at this point?  Is this an ldconfig that
> is installed by rpm on the disk (vs. one from the initramfs)?

Yes, it SHOULD be labeled correctly.  I haven't verified it (verifying exactly 
what happens at each stage of the install is painful), but it's supposed to 
be labeled and I have no reason to expect it not to be.

> > The other option is to run restorecon at the end of the install.  Both
> > options are ugly hacks.
>
> Applying restorecon selectively to runtime-generated files wouldn't be
> too bad.

True.  It seems likely that we will have to do that regardless (see my next 
message).

> > Given that we aren't doing anything with SE Linux at the install the best
> > option is probably to create a policy that defines all file types with a
> > single domain that can have read/write access to them, this will save
> > space in the stage2 files and also precious RAM (currently installing to
> > a machine with 64M of RAM is almost impossible, and 4176K of that problem
> > is the SE Linux policy).
>
> In that case, do you need to enable SELinux in the kernel at all for
> installation?  As long as the kernel provides the xattr API and the
> filesystem supports the security xattrs, rpm should be able to label all
> files it installs even with a SELinux-disabled kernel (although you
> might have to remove an is_selinux_enabled() test from rpm to make it do
> that).  With SELinux disabled, you don't need to load a policy at all to
> set the file contexts.

True.  But with SE Linux disabled I believe that files which are created by 
programs that are not SE Linux aware (IE the %post scripts run from RPM 
packages) will not have any labels.  Thus we would create another problem of 
how to get those files labeled.

Currently we have about a dozen files that have issues and an "everything" 
install might turn up another few dozen.  If we have SE Linux disabled then 
we can expect hundreds or maybe thousands.  It will be significantly more 
painful.

We can manage a list of a dozen problem files that occasionally changes.  We 
can't manage a list of a few thousand files that change more frequently in 
proportion to their number.

> But how does simplifying the install policy (or disabling SELinux
> altogether during install) address the problem of runtime-created files
> like /etc/ld.so.cache?

It doesn't.  I investigated the issue and went off on a tangent.  But these 
things are linked and need to be solved at the same time.

> Aside from that, I'm not adverse to compressing the policy (although I
> would think that collapsing all domains and reducing to a minimal set of
> allow rules would achieve that) for installation, although it would be
> even simpler if you could just install with SELinux disabled in the
> kernel and thus avoid requiring loading a policy at all.

My script does collapse all domains.  As for a minimal set of allow rules, I 
guess if we turn off auditing of AVC messages we could just remove all allow 
and dontaudit rules.  It's a hack, but that's the way the install process 
goes.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page