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