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.
> > > > provided to the SEL list, a comp.xml skeleton that I used to add SEL
> > > > 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
> 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
> > 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
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
Assuming for the moment that selecting the switch during the
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
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