SELinux silently disabled on boot under 2.6.14/2.6.14.2 on FC3 system ?

[rhp]

12-nov-05

Hello:

I have a FC3 box which requires compiling the kernel from source to accomodate
acpi & ec.c related hardware quirks, (its a generic laptop).

When compiling & installing the latest kernels, I have discovered an apparent
problem with both the 2.6.14 & 2.6.14.2 kernels and SELinux.

After compiling these kernels, SELinux is silently disabled on boot;

e.g.:

sestatus shows SELinux as disabled regardless of /etc/selinux/config
being set for 'Permissive-targeted'.

ps -Z & ls -Z show no xattributes but returns these values/messages:
torus:~/selinux/kernel-tests> ps -Z
LABEL                             PID TTY          TIME CMD
kernel                           3979 pts/6    00:00:00 tcsh
kernel                           4005 pts/6    00:00:00 ps
torus:~/selinux/kernel-tests> ls -Z
Sorry, this option can only be used on a SELinux kernel.

dmesg does not have any further SELinux entries after these four:

SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
SELinux:  Registering netfilter hooks

nor are there any error messages in /var/log/messages.

Kernels built from the 2.6.13.4 & 2.6.12-1.1381_FC3, source trees both work
normally with regard to SELinux.

After a comparison of the '.config' files from the related builds,
I've noticed that the 2.6.14 and 2.6.14.2 kernels no longer support
extended attributes for the pseudo filesystems, while the 2.6.13.4 and
2.6.12-1.1381_FC3 kernels do support the extended attributes, this is
the only significant difference I could find between these kernels'
'.config' files.

i.e. Referring to 'make xconfig': in linux-2.6.14/linux-2.6.14.2 these
two filesystems no longer exist:

'Psuedo Filesystems -> /dev/pts Extended Attributes -> /dev/pts
Security Labels''Psuedo Filesystems -> Virtual memory file system
support ->
tmpfs Extended Attributes -> tmpfs Security Lables'.

Note these error messages were returned when using the '.config' from 2.6.13.4
as a starting point for the '.config' in the 2.6.14/2.6.14.2 trees:

/boot/config-2.6.13.4:2649: trying to assign nonexistent symbol DEVPTS_FS_XATTR
/boot/config-2.6.13.4:2650: trying to assign nonexistent symbol
DEVPTS_FS_SECURITY

The Help sections for these options from the 2.6.13.4 kernel indicate these are
used by Selinux:

Help for /dev/pts Security Labels (DEVPTS_FS_SECURITY)

"Security labels support alternative access control models
implemented by security modules like SELinux. This option
enables an extended attribute handler for file security
label in the /dev/pts filesystem.
If you are not using a security module that requires using
extended attributes for file security labels, say N."

Help for tmpfs Security Labels (TMPFS_SECURITY)

"Security labels support alternative access control models
implemented by security modules like SELinux. This option
enables an extended attribute handler for file security
labels in the tmpfs filesystem.
If you are not using a security module that requires using
extended attributes for file security labels, say N."

I would like to stress that _All_ previous 2.6 kernels that I have
tried prior to 2.6.14 work as expected with regard to SELinux.

Has there been a change to SELinux in the FC4 tree but not in the FC3
tree which anticipated this disappearance of the extended attributes
in the 2.6.14 kernel's pseudo filesystems - or am I on the wrong track
?

Here is my current selinux configuration:

selinux-doc-1.14.1-1
selinux-policy-targeted-sources-1.17.30-3.16
libselinux-1.23.10-2
libselinux-devel-1.23.10-2
selinux-policy-targeted-1.17.30-3.16
setools-gui-2.1.1-2
setools-2.1.1-2
checkpolicy-1.23.1-1

I intend to upgrade to FC4/FC5 when I can get the disks, and wonder if
the problem could be
due to subtle conflicts in the above configuration rather than the
disappearance of the extended attributes in the psuedo filesystem in
the 2.6.14 kernel series.

Thank you,
Brgds
Bob

--
rhp.lpt(a)gmail.com

[Stephen Smalley]

On Sat, 2005-11-12 at 15:23 +0700, rhp wrote:
>  I have a FC3 box which requires compiling the kernel from source to
> accomodate
>  acpi & ec.c related hardware quirks, (its a generic laptop).
>  
>  When compiling & installing the latest kernels, I have discovered an apparent
>  problem with both the 2.6.14 & 2.6.14.2 kernels and SELinux.
>  
>  After compiling these kernels, SELinux is silently disabled on boot;
>  
>  e.g.:
>  
>  sestatus shows SELinux as disabled regardless of /etc/selinux/config
>  being set for 'Permissive-targeted'. 
Yes, this is a known issue.  /sbin/init in FC3 (and FC4) only tries
loading the current binary policy format version supported by the kernel
and one version lower before giving up altogether, and there have been
two version increments since FC3 was shipped.  Note that if
your /etc/selinux/config was set to enforcing, /sbin/init should have
halted the system at that point; it was only because it was permissive
that it proceeded.  However I'd agree that the lack of any log message
about the inability to load policy is undesirable - not sure why that
is.

In rawhide, /sbin/init has been changed to use a libselinux helper
function to load policy that is more resilient in several respects, and
I think that the plan was to back port those changes to FC3 if/when a
2.6.14 kernel is released for it.  FC4 is still ok since there has only
been one version increment since it was shipped, but will encounter the
same issue when/if another version increment occurs and the
corresponding kernel is released for it, so it should also get the
new /sbin/init and libselinux helper code.  

>  After a comparison of the '.config' files from the related
> builds,
>  I've noticed that the 2.6.14 and 2.6.14.2 kernels no longer support
>  extended attributes for the pseudo filesystems, while the 2.6.13.4 and
>  2.6.12-1.1381_FC3 kernels do support the extended attributes, this is
>  the only significant difference I could find between these kernels'
>  '.config' files. 
That is a red herring; the xattr support for pseudo filesystems is still
present, but handled via a generic fallback in the VFS rather than
separate handlers (so the separate config option is no longer needed).

-- 
Stephen Smalley
National Security Agency

[Bill Nottingham]

CC'ing Dave.

Stephen Smalley (sds(a)tycho.nsa.gov) said: 
>  In rawhide, /sbin/init has been changed to use a libselinux helper
>  function to load policy that is more resilient in several respects, and
>  I think that the plan was to back port those changes to FC3 if/when a
>  2.6.14 kernel is released for it.  
2.6.14 for FC3 isn't planned, as far as I know.

>  FC4 is still ok since there has only
>  been one version increment since it was shipped, but will encounter the
>  same issue when/if another version increment occurs and the
>  corresponding kernel is released for it, so it should also get the
>  new /sbin/init and libselinux helper code.   
Hm, OK. We'll probably need poked again if/when that happens.

Bill

[Dave Jones]

On Mon, Nov 14, 2005 at 12:07:00PM -0500, Bill Nottingham wrote:
>  CC'ing Dave.
>  
>  Stephen Smalley (sds(a)tycho.nsa.gov) said: 
>  > In rawhide, /sbin/init has been changed to use a libselinux helper
>  > function to load policy that is more resilient in several respects, and
>  > I think that the plan was to back port those changes to FC3 if/when a
>  > 2.6.14 kernel is released for it. 
>  
>  2.6.14 for FC3 isn't planned, as far as I know. 
Correct. FC3 will stay at 2.6.12 until end of life.
Any remaining kernel updates will likely be security errata only
at this point.

>  > FC4 is still ok since there has only
>  > been one version increment since it was shipped, but will encounter the
>  > same issue when/if another version increment occurs and the
>  > corresponding kernel is released for it, so it should also get the
>  > new /sbin/init and libselinux helper code.  
>  
>  Hm, OK. We'll probably need poked again if/when that happens. 
FC4 will continue to rebase to newer upstream kernels until a few
months before its end of life. (As has happened with FC3).

		Dave

[rhp]

15-nov-05

Hello Dave, Bill, & Stephen:

Ok. thanks for the information, I can live with that and just use the
2.6.12-FC3 source for any further upgrades in the FC3 kernel rather
than pulling from kernel.org.

Would there be any benefit in installing the rawhide /sbin/init on a
FC3 box ? I'm rather ambivalent about upgrading to FC4 at this point
given FC5 is scheduled for February.

FWIW: I did try booting 'enforcing' with 2.6.14 earlier just to see
what would happen and, if memory serves, I got a kernel panic on 'no
policy loaded' but I didn't pursue it as I got distracted by the
'xattr red herring'

Brgds
Bob


On 11/15/05, Dave Jones <davej(a)redhat.com&gt; wrote:
>  On Mon, Nov 14, 2005 at 12:07:00PM -0500, Bill Nottingham wrote:
>   > CC'ing Dave.
>   >
>   > Stephen Smalley (sds(a)tycho.nsa.gov) said:
>   > > In rawhide, /sbin/init has been changed to use a libselinux helper
>   > > function to load policy that is more resilient in several respects, and
>   > > I think that the plan was to back port those changes to FC3 if/when a
>   > > 2.6.14 kernel is released for it.
>   >
>   > 2.6.14 for FC3 isn't planned, as far as I know.
>
>  Correct. FC3 will stay at 2.6.12 until end of life.
>  Any remaining kernel updates will likely be security errata only
>  at this point.
>
>   > > FC4 is still ok since there has only
>   > > been one version increment since it was shipped, but will encounter the
>   > > same issue when/if another version increment occurs and the
>   > > corresponding kernel is released for it, so it should also get the
>   > > new /sbin/init and libselinux helper code.
>   >
>   > Hm, OK. We'll probably need poked again if/when that happens.
>
>  FC4 will continue to rebase to newer upstream kernels until a few
>  months before its end of life. (As has happened with FC3).
>
>                  Dave
>
>  

--
rhp.lpt(a)gmail.com

[Stephen Smalley]

On Tue, 2005-11-15 at 12:21 +0700, rhp wrote:
>  Would there be any benefit in installing the rawhide /sbin/init on a
>  FC3 box ? I'm rather ambivalent about upgrading to FC4 at this point
>  given FC5 is scheduled for February. 
If you do, you'll need the rawhide libselinux and libsepol as well.  

>  FWIW: I did try booting 'enforcing' with 2.6.14 earlier just
> to see
>  what would happen and, if memory serves, I got a kernel panic on 'no
>  policy loaded' but I didn't pursue it as I got distracted by the
>  'xattr red herring' 
Yes, that is the correct behavior for enforcing mode when no policy can
be loaded.  Still not sure why init didn't display any kind of message
in permissive mode about not being able to load the policy.

-- 
Stephen Smalley
National Security Agency