4:36 a.m.
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.
Kernel auditing is enabled at boot time (audit=1 kernel switch) and the audit
daemon is set to run at boot time.
I am using:
kernel-2.6.14-1.1653_FC4
selinux-policy-strict-sources-1.27.1-2.16
How can I go about fixing this issue?
6:33 a.m.
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
9:49 a.m.
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@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
10:44 a.m.
On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote:
ls -Z /sbin/init
-rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init
That's your problem - your filesystem is incorrectly labeled. Don't
know how your /sbin/init program ended up with the type of a staff home
directory; it should have init_exec_t.
/sbin/restorecon -nv /sbin/init
If that correctly relabels to init_exec_t, then proceed to do a full
relabel, i.e. touch /.autorelabel and reboot or pass 'autorelabel' on
the kernel command line. Or shut down to single-user and run 'fixfiles
relabel'. All variations on the same theme...
/etc/passwd system_u:object_r:staff_home_t
Should be etc_t.
/bin/bash system_u:object_r:staff_home_t
shell_exec_t
/bin/login system_u:object_r:staff_home_t
login_exec_t
/sbin/init system_u:object_r:staff_home_t
init_exec_t
/sbin/mingetty system_u:object_r:staff_home_t
getty_exec_t
/usr/sbin/sshd system_u:object_r:staff_home_t
sshd_exec_t
The results of audit2why seem to indicate a mismatch between current
in-memory
boolean settings vs. permanent ones.
No, just a filesystem labeling problem. audit2why can't determine that;
it just diagnoses policy problems.
--
Stephen Smalley
National Security Agency
10:51 a.m.
On Fri, 2006-01-27 at 11:44 -0500, Stephen Smalley wrote:
On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote:
> ls -Z /sbin/init
> -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init
That's your problem - your filesystem is incorrectly labeled. Don't
know how your /sbin/init program ended up with the type of a staff home
directory; it should have init_exec_t.
/sbin/restorecon -nv /sbin/init
Oops, that should just be:
/sbin/restorecon -v /sbin/init
The -n prevents it from actually relabeling, so -nv is useful when you
want to see what it would do without actually applying the change, but
in this case, we do want to make the change as well as see exactly what
it does (hence -v for verbose).
If that correctly relabels to init_exec_t, then proceed to do a full
relabel, i.e. touch /.autorelabel and reboot or pass 'autorelabel' on
the kernel command line. Or shut down to single-user and run 'fixfiles
relabel'. All variations on the same theme...
Given the extent of labeling errors reported by sestatus, you definitely
want to do a full relabel, after verifying that at least the above
manual restorecon of init is working properly. If that restorecon
doesn't work properly, then possibly your file_contexts.homedirs is not
being correctly generated by genhomedircon. You don't happen to have
users with home directories of /sbin and /bin, do you?
--
Stephen Smalley
National Security Agency
1:18 p.m.
On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said:
On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote:
> ls -Z /sbin/init
> -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init
That's your problem - your filesystem is incorrectly labeled. Don't
know how your /sbin/init program ended up with the type of a staff home
directory; it should have init_exec_t.
It's probably related to the strict policy whoopsage I reported - the system
would end up with only some 10% of the policy modules in place, and a restorecon
wouldn't include the *.fc rules for the missing modules - so some less-restrictive
rule would set the context (I ended up with almost everything as default_t,
but I could see how staff_home_t might happen too...)
At one point, every single process on my laptop was running in kernel_t, because
the various init_t and similar types weren't defined, nor were the transitions for
them. Good thing I'm running in permissive. ;)
1:29 p.m.
On Fri, 2006-01-27 at 14:18 -0500, Valdis.Kletnieks(a)vt.edu wrote:
On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said:
> On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote:
> > ls -Z /sbin/init
> > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init
>
> That's your problem - your filesystem is incorrectly labeled. Don't
> know how your /sbin/init program ended up with the type of a staff home
> directory; it should have init_exec_t.
It's probably related to the strict policy whoopsage I reported - the system
would end up with only some 10% of the policy modules in place, and a restorecon
wouldn't include the *.fc rules for the missing modules - so some less-restrictive
rule would set the context (I ended up with almost everything as default_t,
but I could see how staff_home_t might happen too...)
At one point, every single process on my laptop was running in kernel_t, because
the various init_t and similar types weren't defined, nor were the transitions for
them. Good thing I'm running in permissive. ;)
Except that his message indicated that he is running FC4, not rawhide
(look at his kernel and policy versions).
--
Stephen Smalley
National Security Agency
5:47 a.m.
I have not had time to do much testing, but first indications are that
incorrect labeling was the culprit.
I initiated a boot-time relabeling. When done, I restarted the system (in
permissive mode), switched to enforcing mode (/usr/sbin/setenforce 1) and was
able to log in normally from tty1, (while su'd as root in tty0) though there
are plenty of 'avc: denied' messages in /var/log/messages and
/var/log/audit/audit.log) that I need to look at.
I still have the problem of reported Boolean errors that are scrolling too fast
to read as selinux loads at boot time, and do not seem to be logged anywhere.
Can you help with those? All I was able to make up from the fast-scrolling
display is the word 'mozilla' repeated four or five times in an error message,
followed by a Boolean error message.
-----Original Message-----
From: fedora-selinux-list-bounces(a)redhat.com
[mailto:fedora-selinux-list-bounces@redhat.com]On Behalf Of Stephen
Smalley
Sent: Friday, January 27, 2006 21:29
To: Valdis.Kletnieks(a)vt.edu
Cc: G Jahchan; Fedora SE Linux List
Subject: Re: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16
On Fri, 2006-01-27 at 14:18 -0500, Valdis.Kletnieks(a)vt.edu wrote:
On Fri, 27 Jan 2006 11:44:07 EST, Stephen Smalley said:
> On Fri, 2006-01-27 at 17:49 +0200, G Jahchan wrote:
> > ls -Z /sbin/init
> > -rwxr-xr-x root root system_u:object_r:staff_home_t /sbin/init
>
> That's your problem - your filesystem is incorrectly labeled. Don't
> know how your /sbin/init program ended up with the type of a staff home
> directory; it should have init_exec_t.
It's probably related to the strict policy whoopsage I reported - the system
would end up with only some 10% of the policy modules in place, and a
restorecon
wouldn't include the *.fc rules for the missing modules - so some
less-restrictive
rule would set the context (I ended up with almost everything as
default_t,
but I could see how staff_home_t might happen too...)
At one point, every single process on my laptop was running in kernel_t,
because
the various init_t and similar types weren't defined, nor were
the
transitions for
them. Good thing I'm running in permissive. ;)
Except that his message indicated that he is running FC4, not rawhide
(look at his kernel and policy versions).
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
9:30 a.m.
On Mon, 2006-01-30 at 13:47 +0200, G Jahchan wrote:
I have not had time to do much testing, but first indications are
that
incorrect labeling was the culprit.
I initiated a boot-time relabeling. When done, I restarted the system (in
permissive mode), switched to enforcing mode (/usr/sbin/setenforce 1) and was
able to log in normally from tty1, (while su'd as root in tty0) though there
are plenty of 'avc: denied' messages in /var/log/messages and
/var/log/audit/audit.log) that I need to look at.
I still have the problem of reported Boolean errors that are scrolling too fast
to read as selinux loads at boot time, and do not seem to be logged anywhere.
Can you help with those? All I was able to make up from the fast-scrolling
display is the word 'mozilla' repeated four or five times in an error message,
followed by a Boolean error message.
Likely just stale boolean settings in your booleans.local file, which
are just skipped with a warning. To reproduce, run:
/usr/sbin/load_policy -b /etc/selinux/targeted/policy/policy.19
If you have any "boolean ... no longer in policy" messages, just remove
those lines from your /etc/selinux/targeted/booleans.local file.
--
Stephen Smalley
National Security Agency
2:12 a.m.
I have upgraded the kernel to 2.6.14-1.1656 and pam to 0.79.9 (from
2.6.14-1.1653 & 0.79.8 respectively) and I am back to the drawing board.
Authentication is no longer possible when in enforcing mode, but this time
there are NO reported 'avc: denied' messages in any of the logs.
The problem may not lie strictly with selinux, as even when in permissive mode,
the first authentication attempt to a console always fails, but the second
works (with the exact same credentials). Ditto when sudoing a command that
requires authentication: never works the first time if in permissive mode, and
not at all if in enforcing mode. su on the other hand always works in
permissive mode, but never in enforcing mode.
When in KDE, a locked station cannot be unlocked, regardless of the status of
selinux - permissive or enforcing, it makes no difference.
-----Original Message-----
From: fedora-selinux-list-bounces(a)redhat.com
[mailto:fedora-selinux-list-bounces@redhat.com]On Behalf Of Stephen Smalley
Sent: Monday, January 30, 2006 17:31
To: G Jahchan
Cc: Fedora SE Linux List
Subject: RE: Kernel 2.6.14-1.1653 & selinux 1.27.1.-2.16
On Mon, 2006-01-30 at 13:47 +0200, G Jahchan wrote:
I have not had time to do much testing, but first indications are
that
incorrect labeling was the culprit.
I initiated a boot-time relabeling. When done, I restarted the system (in
permissive mode), switched to enforcing mode (/usr/sbin/setenforce 1) and was
able to log in normally from tty1, (while su'd as root in tty0) though there
are plenty of 'avc: denied' messages in /var/log/messages and
/var/log/audit/audit.log) that I need to look at.
I still have the problem of reported Boolean errors that are scrolling too
fast
to read as selinux loads at boot time, and do not seem to be logged
anywhere.
Can you help with those? All I was able to make up from the fast-scrolling
display is the word 'mozilla' repeated four or five times in an error
message,
followed by a Boolean error message.
Likely just stale boolean settings in your booleans.local file, which
are just skipped with a warning. To reproduce, run:
/usr/sbin/load_policy -b /etc/selinux/targeted/policy/policy.19
If you have any "boolean ... no longer in policy" messages, just remove
those lines from your /etc/selinux/targeted/booleans.local file.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
6:59 a.m.
On Wed, 2006-02-01 at 10:12 +0200, G Jahchan wrote:
I have upgraded the kernel to 2.6.14-1.1656 and pam to 0.79.9 (from
2.6.14-1.1653 & 0.79.8 respectively) and I am back to the drawing board.
Authentication is no longer possible when in enforcing mode, but this time
there are NO reported 'avc: denied' messages in any of the logs.
The problem may not lie strictly with selinux, as even when in permissive mode,
the first authentication attempt to a console always fails, but the second
works (with the exact same credentials). Ditto when sudoing a command that
requires authentication: never works the first time if in permissive mode, and
not at all if in enforcing mode. su on the other hand always works in
permissive mode, but never in enforcing mode.
When in KDE, a locked station cannot be unlocked, regardless of the status of
selinux - permissive or enforcing, it makes no difference.
Any other SELinux messages there? Look for SELINUX_ERR (or
use /sbin/ausearch -m selinux_err).
Turn on full auditing by SELinux:
cd /etc/selinux/strict/src/policy
make clean enableaudit load
<re-test>
make clean load
<check /var/log/audit/audit.log again>
That will yield a lot of noise in the logs, but you might find something
useful.
Other possibility is that you are running into an audit_write or
audit_control capability denial from the kernel audit subsystem; those
aren't audited presently by SELinux since they occur in receiver
context. Need to make sure that login and friends have those
capabilities. But it looks like they are there in the FC4 strict policy
(indirectly via authentication_domain(auth_chkpwd)).
--
Stephen Smalley
National Security Agency
6668
days inactive
6673
days old
selinux@lists.fedoraproject.org
10 comments
3 participants
participants (3)
-
G Jahchan -
Stephen Smalley -
Valdis.Kletnieks＠vt.edu