Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16

[G Jahchan]

ls -Z /sbin/init
-rwxr-xr-x  root     root     system_u:object_r:staff_home_t   /sbin/init

/usr/sbin/sestatus -v | grep -v active
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 20
Policy from config file:        strict

Policy booleans:

Process contexts:
Current context:                    gjahchan:sysadm_r:sysadm_t
Init context:                       system_u:system_r:kernel_t

File contexts:
Controlling term:                   gjahchan:object_r:devpts_t
/etc/passwd                         system_u:object_r:staff_home_t
/etc/shadow                         system_u:object_r:shadow_t
/bin/bash                           system_u:object_r:staff_home_t
/bin/login                          system_u:object_r:staff_home_t
/bin/sh                             system_u:object_r:bin_t ->
system_u:object_r:staff_home_t
/sbin/agetty                        system_u:object_r:getty_exec_t
/sbin/init                          system_u:object_r:staff_home_t
/sbin/mingetty                      system_u:object_r:staff_home_t
/usr/sbin/sshd                      system_u:object_r:staff_home_t
/lib/libc.so.6                      system_u:object_r:lib_t ->
system_u:object_r:shlib_t
/lib/ld-linux.so.2                  system_u:object_r:lib_t ->
system_u:object_r

The results of audit2why seem to indicate a mismatch between current in-memory
boolean settings vs. permanent ones.

It sounds like I have a boolean problem. Now I remember, while booting, a
boolean error message very quickly scrolls, I never managed to read it, and it
is not logged in any of the logs (boot, dmesg, or messages). The audit daemon
would not have started at this stage. Any idea where the error is logged if at
all, or how to force a manual generation of the event post startup?

-----Original Message-----
From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
Sent: Friday, January 27, 2006 14:34
To: G Jahchan
Cc: Fedora SE Linux List
Subject: Re: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16


On Fri, 2006-01-27 at 12:36 +0200, G Jahchan wrote:
> I have been desperately trying to get selinux strict policy to work on my
> laptop to no avail. I have been using a strict policy in enforcing mode for a
> long time, but since I upgraded to the kernel / selinux versions listed
below,
> when in enforcing mode, the policy causes authentication to fail from the
> console (my default runlevel is 3).
>
> Even though I have the following statements in my custom.te under
> /etc/selinux/strict/src/policy/domains/misc/
>
> allow kernel_t sysadm_t:process transition;
> allow kernel_t sysadm_tty_device_t:chr_file { relabelfrom relabelto };
> allow sysadm_t sysadm_t:process transition;
>
> I keep getting corresponding 'avc: denied' events in the audit log.

These rules shouldn't be necessary, so they imply a more fundamental
problem.  They suggest that your login program is still running in
kernel_t rather than local_login_t.  In turn, this suggests that the
initial transition from kernel_t to init_t upon executing /sbin/init did
not occur.  What does ls -Z /sbin/init show?
What does '/usr/sbin/sestatus -v | grep -v active' show?

As a side note, avc denials can be caused by other components of the
policy beyond the TE rules, and the above permissions are likely being
(correctly) denied by the role-based restrictions and user-based
restrictions.  Normally, kernel_t doesn't need to be able to transition
to a user security context since kernel_t is only for the initial kernel
task and other kernel threads.  audit2why(8) will try to tell you why a
given avc denial occurred.

--
Stephen Smalley
National Security Agency