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

Stephen Smalley sds at tycho.nsa.gov
Mon May 16 12:11:27 UTC 2005


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.

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

> 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)?

> 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.

> 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.  

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?

> I've attached a little Perl script that will munge a targeted policy.  It 
> replaces most type and domain definitions with typealias rules and reduces 
> the policy binary size from 4176K to 60K.  That saves 4116K of kernel memory 
> and almost 700K on the cramfs.  The saving of 4M of kernel memory will make a 
> huge difference to the install on small machines.  Currently it's almost 
> impossible to install a FC4 test version on a machine with 64M of RAM, this 
> change will give the same result as adding another 4M of RAM to machines for 
> the installer (particularly important for machines that run out of RAM before 
> completing the partitioning process).

As you discovered, SELinux only uses type aliases to allow applications
and users to specify alternative names; internally, it always
canonicalizes to the primary type name.  It is true that you can
presently set the context to a type alias on disk (but only because the
xattr API goes straight to the filesystem code and doesn't give SELinux
an opportunity to canonicalize the attribute value, unlike the old
SELinux API), but newly created files will always get the primary name.
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.

-- 
Stephen Smalley
National Security Agency




More information about the fedora-devel-list mailing list