Core 2 SELinux installation

[Jeremy Katz]

On Thu, 2004-04-29 at 11:35 -0500, Nick wrote: 
> On Thu, 2004-04-29 at 10:05, Jeremy Katz wrote:
> > On Wed, 2004-04-28 at 22:06 -0500, Nick Gray wrote:
> > > On Wed, 2004-04-28 at 21:43, Jeremy Katz wrote:
> > > > On Wed, 2004-04-28 at 21:16 -0500, Nick wrote:
> > > > > Why are we using the command line option to install SELinux process. I
> > > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL to
> > > > > Core 1. 
> > > > 
> > > > The option has nothing to do with what packages get installed, it deals
> > > > instead with if we set up such things as xattrs on the filesystem and
> > > > whether policy will end up loading by default
> > > 
> > > Isn't all of that via packages? 
> > 
> > It's based on information in packages, but it's influenced also by _how_
> > the packages are installed.  Not by which packages are actually being
> > installed.  ie, what %__file_context_path is set to for RPM and thus
> > whether contexts are set on files as they're laid down on the
> > filesystem.  Also, what ends up in /etc/sysconfig/selinux which gets
> > looked at by init to determine whether policy should be loaded or not.
> 
> This seems like semantics, you won't need to set xattrs, setup a
> /selinux directory, or access any of the selinux packages if you are
> given the option not to install SEL. 

But you *have* to install some SELinux packages.  eg, libselinux is
always going to end up being installed due to dependencies of other
packages.  And doing an 'Everything' install (although I hate them) also
shouldn't necessarily imply that you want SELinux enabled and setup.

> > > Isn't the kernel build during install from a source package?
> > 
> > Ummm, no.  This would a) require the installation of a compiler and b)
> > make the install time much longer, especially on older hardware.
> 
> I vaguely recall this. So the default kernels must be pretty large to
> contain all of the modules, etc, for each option (Bluetooth etc.. ).

Yes, the kernel package is not small and contains many, many modules.

> > > So your saying that the switch is just a way of setting the level that
> > > is currently set in the firewall screen of the install?
> > 
> > Whether or not the control is even shown.  SELinux is not at this point
> > something that is going to be suitable for all users -- this will change
> > over time, but right now avoiding having the users who don't know better
> > from getting into trouble is a good idea just to cut down on the support
> > burden.
> 
> I still think you are missing my point. Is the SELinux kernel installed
> by default and directories such as '/etc/security' created even if the
> switch is off?

The kernel includes the support and the directories are created, but
without policy being loaded, etc, there isn't an impact.  Okay, that's
not 100% true.  There was a performance hit due to some additional hooks
being added, but with recent kernel changes, you can unregister on the
fly and so init will now do that if it's not loading a policy and thus
mitigate that.

> Assuming for the moment that selecting the switch during the install,
> prevents any trace of SEL from showing on the system, why do it via
> switch? Why not use the installation menu and leave the SELinux portion
> disabled by default?

Because there's not a way to give enough information on what all of the
ramifications are.  And with the current state of things, it's thus best
to make it an option for people who know what they're doing.

> Making the other assumption that all the binaries/directories are
> installed, and just not enabled. I think those of us who need to have
> this accredited are going to have a tough time with the distinction of
> installed but not used. The selection should let you go down one of two
> paths, installed or not installed. The distinction needs to be pristine
> if those of us who need this for secure implementations are going to
> present it

It's not that hard.  Take a look at is_selinux_enabled() in libselinux
for the way to determine this.  And even that's not even enough if
you're wanting to make some sort of "guarantee" on the security of the
system -- what your policy is directly defines this.  SELinux itself is
just a framework to provide the capability for having a secure
implementation.

Jeremy