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?

> 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 ?

ps -eZ | grep systemd

Boot with enforcing=0

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

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

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?

There were no 3.4 kernel changes related to SELinux.  So its going to have to be a policy or systemd change here....

Is your patch for the default source/target selectors in the Fedora kernel?
Is the Fedora policy relying on that patch?

Nope.  Not in Fedora kernel.  I don't know what whacky things Dan does with that policy   :)

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?

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?

(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 ?

(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.

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

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.

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"

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.

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?

3.2.9 looks fine
as does my 3.3.0-1 fedora kernel....

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.

bfcfaa77bdf0f775263e906015982a608df01c76 ???

yes. reverting that makes it boot again for me.

That's the commit that broke things.  I replied to a thread to Linus informing him that he blew up the world.

was fixed with Al Viro's commit.