On Monday 16 May 2005 22:11, Stephen Smalley <sds(a)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