Bug 805371 - new selinux denials with 3.4 kernel
new selinux denials with 3.4 kernel
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-20 23:53 EDT by Dave Jones
Modified: 2015-01-04 17:31 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-27 11:00:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Jones 2012-03-20 23:53:51 EDT
With Linus' latest kernel tree, f16 fails to boot, because systemd is being prevented from creating a socket.

This doesn't affect the kernels currently shipping, but will eventually need fixing when we rebase when 3.4 comes out in a few months. It would be useful if this was fixed in the meantime, so I can continue to test bleeding edge kernels on a stable release.

(I haven't tried f17 yet, but I assume the same problems are there).


[   42.112134] type=1400 audit(1332286675.356:4): avc:  denied  { dyntransition } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=process
[   45.044703] type=1400 audit(1332301078.287:5): avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=unix_dgram_socket
[   45.075046] systemd[1]: systemd-shutdownd.socket failed to listen on sockets: Permission denied
[   45.181624] type=1400 audit(1332301078.424:6): avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=unix_dgram_socket
[   45.213047] systemd[1]: syslog.socket failed to listen on sockets: Permission denied
[   45.347360] type=1400 audit(1332301078.589:7): avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=netlink_kobject_uevent_socket
[   45.393034] systemd[1]: udev-kernel.socket failed to listen on sockets: Permission denied
[   45.438330] type=1400 audit(1332301078.680:8): avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=unix_stream_socket
[   45.470457] systemd[1]: udev-control.socket failed to listen on sockets: Permission denied
[   45.514336] type=1400 audit(1332301078.757:9): avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=unix_stream_socket
[   45.547534] systemd[1]: systemd-stdout-syslog-bridge.socket failed to listen on sockets: Permission denied
Comment 1 Daniel Walsh 2012-03-21 09:55:06 EDT
This looks like systemd did not do the proper transition.  Are you sure you do not have a labeling issue.

You have systemd running as kernel_t?
Comment 2 Dave Jones 2012-03-21 11:37:06 EDT
> This looks like systemd did not do the proper transition.  Are you sure you do
> not have a labeling issue.

I can try forcing a relabel later. Though 3.2 works fine with no avc's.

> You have systemd running as kernel_t?

How do I check that ?
Comment 3 Daniel Walsh 2012-03-21 13:22:13 EDT
ps -eZ | grep systemd

Boot with enforcing=0
Comment 4 Dave Jones 2012-03-21 19:23:46 EDT
it was kernel_t when I booted without any boot params and got dropped to an emergency shell.

if I boot with enforcing=0, then it becomes system_u:object_r:init_exec_t:s0
Comment 5 Dave Jones 2012-03-21 19:36:14 EDT
just did a relabel while permissive ..

Cleaning out /tmp
filespec_add:  conflicting specifications for /usr/lib/debug/usr/bin/getconf.debug and /usr/lib/debug/usr/libexec/getconf/POSIX_V7_LP64_OFF64.debug, using system_u:object_r:lib_t:s0.
filespec_add:  conflicting specifications for /var/named/chroot/usr/lib64/bind and /usr/lib64/bind, using system_u:object_r:lib_t:s0.
cat: /sys/fs/selinux/initial_contexts/unlabeled: No such file or directory
secon:  Couldn't read security context: Invalid argument
Comment 6 Daniel Walsh 2012-03-22 10:41:36 EDT
Well what is supposed to happen is systemd asks the kernel what type to transition to, when executing init_exec_t.

sesearch -T -s kernel_t -t init_exec_t
Found 1 semantic te rules:
   type_transition kernel_t init_exec_t : process init_t; 

systemd is supposed to get init_t, but it looks like it got back init_exec_t, which makes no sense.  Systemd then tries to set its context to init_exec_t, which is an illegal process context and when this fails, the process continues to run as kernel_t, causing all of the other AVCs.

If you run this command on you machine what do you see?
Comment 7 Eric Paris 2012-03-22 10:53:03 EDT
There were no 3.4 kernel changes related to SELinux.  So its going to have to be a policy or systemd change here....
Comment 8 Stephen Smalley 2012-03-22 10:58:20 EDT
Is your patch for the default source/target selectors in the Fedora kernel?
Is the Fedora policy relying on that patch?
Comment 9 Eric Paris 2012-03-22 11:02:24 EDT
Nope.  Not in Fedora kernel.  I don't know what whacky things Dan does with that policy   :)
Comment 10 Daniel Walsh 2012-03-22 11:10:44 EDT
Dave is stating that the previous kernel works fine, so not a change of policy, here, that I am aware of.

This is very strange.  Dave can I get a hold of that kernel?
Comment 11 Stephen Smalley 2012-03-22 11:26:17 EDT
The behavior described would fit with passing of a class value of 0 to (libselinux) security_compute_create to /sys/fs/selinux/create to (kernel) sel_write_create to security_transition_sid_user().  Then it would follow the non-process class case and use the object/target context by default; hence, init_exec_t rather than init_t.  So the question is why are we getting a class value of 0 from userspace.  systemd version? libselinux version?  Is it calling string_to_security_class() before policy load?
Comment 12 Dave Jones 2012-03-22 11:32:24 EDT
(In reply to comment #10)
> Dave is stating that the previous kernel works fine, so not a change of policy,
> here, that I am aware of.
> 
> This is very strange.  Dave can I get a hold of that kernel?

it's a hand-built one, not an rpm. I can give you the .config if you want ?
Comment 13 Stephen Smalley 2012-03-22 11:46:10 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > Dave is stating that the previous kernel works fine, so not a change of policy,
> > here, that I am aware of.
> > 
> > This is very strange.  Dave can I get a hold of that kernel?
> 
> it's a hand-built one, not an rpm. I can give you the .config if you want ?

yes, please, and git describe output.
And systemd, libselinux, and selinux-policy versions.
Comment 14 Dave Jones 2012-03-22 12:24:29 EDT
config is here http://codemonkey.org.uk/junk/805371-config

v3.3-4074-g5375871

systemd-37-17.fc16.x86_64
libselinux-2.1.6-6.fc16.x86_64
libselinux-2.1.6-6.fc16.i686
selinux-policy-3.10.0-80.fc16.noarch
Comment 15 Stephen Smalley 2012-03-22 12:30:48 EDT
I just confirmed the same behavior.  With systemd, libselinux, and selinux-policy unchanged (slightly older versions - systemd -15 and selinux-policy -75), and only changing the kernel from kernel-3.3.0-4.fc16 to the same git hash as above.

$ compute_create system_u:system_r:kernel_t:s0 system_u:object_r:init_exec_t:s0 process
system_u:object_r:init_exec_t:s0

Looks like a kernel regression.
Comment 16 Eric Paris 2012-03-22 12:50:59 EDT
git diff v3.3..5375871 -- security/selinux/


diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6a3683e..3049299 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -81,6 +81,8 @@
 #include <linux/syslog.h>
 #include <linux/user_namespace.h>
 #include <linux/export.h>
+#include <linux/msg.h>
+#include <linux/shm.h>
 
 #include "avc.h"
 #include "objsec.h"
Comment 17 Stephen Smalley 2012-03-22 14:24:04 EDT
strace shows that libselinux fails on mapping class strings to values due to errors from selinuxfs.

stat("/sys/fs/selinux/class/process/perms/execheap", 0x7fffe61fdf40) = -1 ENOENT (No such file or directory)

A number of files listed under /sys/fs/selinux are returning ENOENT on stat() calls with this kernel.
Comment 18 Stephen Smalley 2012-03-22 14:27:35 EDT
Hmmm..even with v3.3, ls -l /sys/fs/selinux shows rather interesting dates...the stat succeeds but it is partying like it is 1980?
Comment 19 Eric Paris 2012-03-22 14:43:08 EDT
3.2.9 looks fine
as does my 3.3.0-1 fedora kernel....
Comment 20 Stephen Smalley 2012-03-22 14:49:56 EDT
Never mind, it is just the hardware clock time on that machine.
I guess it gets set when selinuxfs is first mounted, before a software time is set.
So v3.3 is likely fine, but current linus is definitely broken.
Probably a vfs change.
Comment 21 Eric Paris 2012-03-22 15:31:40 EDT
bfcfaa77bdf0f775263e906015982a608df01c76 ???
Comment 22 Dave Jones 2012-03-22 16:01:33 EDT
yes. reverting that makes it boot again for me.
Comment 23 Eric Paris 2012-03-22 16:06:19 EDT
That's the commit that broke things.  I replied to a thread to Linus informing him that he blew up the world.
Comment 24 Dave Jones 2012-03-27 11:00:36 EDT
was fixed with Al Viro's commit.

Note You need to log in before you can comment on or make changes to this bug.