All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmill@redhat.com>
To: "Tom 'spot' Callaway" <tcallawa@redhat.com>,
	SELinux Mail List <selinux@tycho.nsa.gov>,
	fedora-selinux-list@redhat.com
Subject: [Fwd: Re: sparc64 kernel won't boot with selinux enabled]
Date: Mon, 15 Jan 2007 11:51:46 -0500	[thread overview]
Message-ID: <45ABB122.4010205@redhat.com> (raw)

[Forwarding to the correct list this time]

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

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

                 reply	other threads:[~2007-01-15 17:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45ABB122.4010205@redhat.com \
    --to=kmacmill@redhat.com \
    --cc=fedora-selinux-list@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=tcallawa@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.