sparc64 kernel won't boot with selinux enabled

[Tom Callaway]

I'm working on Aurora, which is a rebuild of Fedora Core for SPARC.
Lately, I've been testing with selinux enabled on the targeted policy,
but I haven't gotten very far. When I try to boot on a sparc64, I get
the following (copied by hand, apologies for any typos, I tried to be
accurate):

EXT3-fs: mounted filesystem with ordered data mode.
audit(1168807648.026:2): enforcing=1 old_enforcing=0 auid=4294967295
security:  3 users, 6 roles, 1584 types, 172 bools, 1 sens, 1024 cats
security:  59 classes, 49650 rules
security:  class dccp_socket not defined in policy
security:  permission dccp_recv in class node not defined in policy
security:  permission dccp_send in class node not defined in policy
security:  permission dccp_recv in class netif not defined in policy
security:  permission dccp_send in class netif not defined in policy
SELinux:  Completing initialization
SELinux:  Setting up existing superblocks.
SELinux: initialized (dev dm-0, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses
genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs
SELinux: initialized (dev inotifyfs, type inotifyfs), uses
genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
audit(1168807652.930:3): policy loaded auid=4294967295
audit(1168807653.174:4): avc:  denied  { execmem } for  pid=1
comm="init" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=process

...And there it sits, as init is denied. :)

I found this thread
(http://www.redhat.com/archives/fedora-selinux-list/2005-April/msg00037.html)
while looking through google for other cases of this error message, and
I looked through bugzilla 149819. The sparc64 kernel has
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1, and I tried booting with
"checkreqprot=0", but it does not change the result. Booting with
selinux=permissive works fine. I booted as selinux=permissive and ran
fixfiles relabel, but again, no change seen.

Here are the relevant versions of packages which I have installed:
kernel-2.6.19-1.2906.al3.4.sparc64.rpm
libselinux-1.33.4-2.al3.sparc.rpm
libsemanage-1.9.2-1.al3.sparc.rpm
libsepol-1.15.3-1.al3.sparc.rpm
checkpolicy-1.33.1-2.al3.sparc.rpm
policycoreutils-1.33.12-2.al3.sparc.rpm
selinux-policy-2.4.6-21.al3.noarch.rpm

For obvious reasons (Aurora, like Fedora, enables selinux by default),
I'd like to get this fixed. Any ideas where I should go from here?

Thanks in advance,

~spot

[Karl MacMillan]

Tom 'spot' Callaway wrote:
>  I'm working on Aurora, which is a rebuild of Fedora Core for
> SPARC.
>  Lately, I've been testing with selinux enabled on the targeted policy,
>  but I haven't gotten very far. When I try to boot on a sparc64, I get
>  the following (copied by hand, apologies for any typos, I tried to be
>  accurate):
>   
[CC'ing selinux list]

>  EXT3-fs: mounted filesystem with ordered data mode.
>  audit(1168807648.026:2): enforcing=1 old_enforcing=0 auid=4294967295
>  security:  3 users, 6 roles, 1584 types, 172 bools, 1 sens, 1024 cats
>  security:  59 classes, 49650 rules
>  security:  class dccp_socket not defined in policy
>  security:  permission dccp_recv in class node not defined in policy
>  security:  permission dccp_send in class node not defined in policy
>  security:  permission dccp_recv in class netif not defined in policy
>  security:  permission dccp_send in class netif not defined in policy 
Seems that there is a mismatch between your policy and the kernel.

>  SELinux:  Completing initialization
>  SELinux:  Setting up existing superblocks.
>  SELinux: initialized (dev dm-0, type ext3), uses xattr
>  SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>  SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
>  SELinux: initialized (dev selinuxfs, type selinuxfs), uses
>  genfs_contexts
>  SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
>  SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
>  genfs_contexts
>  SELinux: initialized (dev devpts, type devpts), uses transition SIDs
>  SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs
>  SELinux: initialized (dev inotifyfs, type inotifyfs), uses
>  genfs_contexts
>  SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>  SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
>  SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
>  SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
>  SELinux: initialized (dev proc, type proc), uses genfs_contexts
>  SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
>  SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
>  SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
>  audit(1168807652.930:3): policy loaded auid=4294967295
>  audit(1168807653.174:4): avc:  denied  { execmem } for  pid=1
>  comm="init" scontext=system_u:system_r:kernel_t:s0
>  tcontext=system_u:system_r:kernel_t:s0 tclass=process
>  
>  ...And there it sits, as init is denied. :)
>   
Init requiring execmem is surprising to say the least - it certainly 
doesn't on i386. Are you seeing a lot of execmem denials in the logs? I 
don't really know what is going on, but there is likely a kernel or 
compiler / toolchain issue causing overly broad execmem requests.

As a work around you can do (after booting into permissive):

setsebool -P allow_execmem=1

The next reboot will allow this globally and you may get farther in 
permissive. You can also change this default in the policy packages.

Karl

[Stephen Smalley]

On Mon, 2007-01-15 at 11:43 -0500, Karl MacMillan wrote:
>  Tom 'spot' Callaway wrote:
>  > I'm working on Aurora, which is a rebuild of Fedora Core for SPARC.
>  > Lately, I've been testing with selinux enabled on the targeted policy,
>  > but I haven't gotten very far. When I try to boot on a sparc64, I get
>  > the following (copied by hand, apologies for any typos, I tried to be
>  > accurate):
>  > 
>  
>  [CC'ing selinux list]
>  
>  > EXT3-fs: mounted filesystem with ordered data mode.
>  > audit(1168807648.026:2): enforcing=1 old_enforcing=0 auid=4294967295
>  > security:  3 users, 6 roles, 1584 types, 172 bools, 1 sens, 1024 cats
>  > security:  59 classes, 49650 rules
>  > security:  class dccp_socket not defined in policy
>  > security:  permission dccp_recv in class node not defined in policy
>  > security:  permission dccp_send in class node not defined in policy
>  > security:  permission dccp_recv in class netif not defined in policy
>  > security:  permission dccp_send in class netif not defined in policy
>  
>  Seems that there is a mismatch between your policy and the kernel.
>  
>  > SELinux:  Completing initialization
>  > SELinux:  Setting up existing superblocks.
>  > SELinux: initialized (dev dm-0, type ext3), uses xattr
>  > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>  > SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
>  > SELinux: initialized (dev selinuxfs, type selinuxfs), uses
>  > genfs_contexts
>  > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
>  > SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
>  > genfs_contexts
>  > SELinux: initialized (dev devpts, type devpts), uses transition SIDs
>  > SELinux: initialized (dev eventpollfs, type eventpollfs), uses task SIDs
>  > SELinux: initialized (dev inotifyfs, type inotifyfs), uses
>  > genfs_contexts
>  > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>  > SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
>  > SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
>  > SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
>  > SELinux: initialized (dev proc, type proc), uses genfs_contexts
>  > SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
>  > SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
>  > SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
>  > audit(1168807652.930:3): policy loaded auid=4294967295
>  > audit(1168807653.174:4): avc:  denied  { execmem } for  pid=1
>  > comm="init" scontext=system_u:system_r:kernel_t:s0
>  > tcontext=system_u:system_r:kernel_t:s0 tclass=process
>  > 
>  > ...And there it sits, as init is denied. :)
>  > 
>  
>  Init requiring execmem is surprising to say the least - it certainly 
>  doesn't on i386. Are you seeing a lot of execmem denials in the logs? I 
>  don't really know what is going on, but there is likely a kernel or 
>  compiler / toolchain issue causing overly broad execmem requests. 
Compiler / toolchain problem; we've seen the same thing in the past on
ppc32 and ia64, e.g. see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178747
Those were ultimately resolved by toolchain changes and rebuilt
userland, but the temporary fix was to disable the exec* checks in the
kernel for those architectures.

>  
>  As a work around you can do (after booting into permissive):
>  
>  setsebool -P allow_execmem=1
>  
>  The next reboot will allow this globally and you may get farther in 
>  permissive. You can also change this default in the policy packages. 
-- 
Stephen Smalley
National Security Agency