[Fedora-livecd-list] Cleanups to squashfs and selinux disabling

[Toshio Kuratomi]

On 4/3/06, J. Hartline <jasperhartline at adelphia.net> wrote:
> Toshio Kuratomi wrote:
>
> >kadischi-kmodules.patch:
> >
> I'll get these up sometime later, it isn't a big issue as modules aren't
> exactly huge nor are the
> loop nodes, but if we don't need them, we should'nt install them. :-P
>
Yep :-)

> >kadischi-selinux.patch:
> >* install-boot.sh: Remove the selinux=0 kernel parameter as we want a
> >more generic and finer grained option for the future.
> >* 04auth.sh: Use sed within the chroot to change the value of SELINUX=
> >in /etc/selinux/config to 'disabled'  When we have a filesystem that
> >supports extended atributes, we can modify this behaviour by setting
> >SELINUXSTATE to enforcing, permissive, etc.  A similar method can be
> >used to configure SELINUXTYPE (strict/targeted/mls) at that time as
> >well.
> >
> >
> This probably won't be neccessary. We already have $kernel_params with
> selinux=0.
> What I was discussing about this being a bad idea is having selinux
> turned off in the debug option of
> the Isolinux configs. Which is how I modified this to be anyhow. The
> kernel parameter is much simpler.
>
I moved the selinux configuration out of here onto the kernel
commandline originally because I had to get rid of the dependency on
lokkit (I'm creating a minimal CD and don't want lokkit on the CD.) 
After thinking about this further, it seemed the kernel's selinux=0 is
not fine grained enough for our future needs.  At some point we're
going to have a compressed filesystem capable of storing selinux
security labels.  Then we'll want to be able to change the selinux
state and selinux type when we create the image.

> >* 05fsclean.sh: Add .autorelabel to the list of files to remove.  We
> >can't relabel a read-only filesystem.
> >
> >
> This file isn't created by default that I can tell in particular,
Hmm.. You're right.  This is unnecessary then.

> likewise in rc.sysinit
> if this file exists a relabel is tried else the file is touched which
> can't happen
> In fact I've filed an RFE against initscripts some time agi regarding
> this issue
> the BZ entry is here:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181829
> It is purely a cosmetic issue as far as I am concerned.
>
Okay.  We'll wait for a fix from "upstream" Fedora.

> >+### FIXME:
> > # We could eventually make this more useful, and maybe in another way.
> >-# With selinux=0 we shouldn't be having SELinux problems.
> >-# Likewise a firewall will exist unless we've used kickstart to disable it.
> >+# We can't depend on lokkit being present in our new install.  The sed line should
> >+# allow us to take care of selinux configuration but we still need something to
> >+# change the firewall from the anaconda default.
> >
> >
> This is of course very "fuzzy" to me. With the way it is now, yes
> Anaconda will set a default set of firewall rules.
> The only way currently to alleviate this (Without disabling it
> completely) is to be using kickstart with the
> firewall options set in the ks.cfg. However, a better immediate approach
> to this I think is to chroot and run
> lokkit and (possibly) ntsysv during a post_install_script, say
> 07userconfig.sh  after checking first if we
> are or aren't invoked using kickstart or cmdline. In either instance we
> should assume:
> 1) cmdline is non interactive of course, don't run lokkit or ntsysv.
> 2) kickstart ks.cfg should contain some firewall rules if the builder
> expects certain rules.
> Otherwise we run lokkit, and only if it exists, so it isn't required to
> successfully build a CD.
>
> What do you think about this instead?
>
kadischi should allow creation time setting of firewall rules/system
services without requiring the presence of advanced programs on the CD
for space and in case the admin wants to limit the eases with which
their end-users can reconfigure the system.  lokkit and ntsysv will be
excess baggage in a lot of cases but the function they perform at ISO
build time is necessary.

Currently, we're in the realm of one-offs where a custom post-install
script can set these things up.  Using a conditionalized chroot
lokkit/ntsysv as you suggest would be better. Implementing this inside
of kadischi (as the SELinux portion of this patch starts to do) gets
us where we want to be but we have to implement it ourselves. Having
lokkit and ntsysv run outside of the rootdir with a
'--rootpath=/var/tmp/kadischi-root/' option would be ideal.

-Toshio