Description of problem: Today's rawhide (beta?) fails to boot (and fails to shutdown after update) when in SELinux enforcing. Generates endless sper: Mar 11 07:32:07 localhost init: Error on control socket: Permission denied Booting with 'enforcing=0' shows the following AVC: Mar 11 07:35:32 localhost kernel: type=1400 audit(1205246125.183:3): avc: denied { sendto } for pid=1 comm="init" path=002F636F6D2F7562756E74752F757073746172742F31383031 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket Generating a local policy (via audit2allow -M) with #============= init_t ============== allow init_t initrc_t:unix_dgram_socket sendto; Allows system to boot. Version-Release number of selected component (if applicable): kernel-2.6.25-0.105.rc5.fc9.i686 upstart-0.3.9-9.fc9.i386 initscripts-8.65-1.i386 How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
upstart hasn't appreciably changed recently - did something change in policy?
Today's updates include initscripts, kernel, hal, .... This appears to hit after udev, and after file systems are remounted. Looks like it occurs before rsyslog starts. Here is snippet from /var/log/messages (booted with 'enforcing=0'): Mar 11 07:35:32 localhost kernel: loop: module loaded Mar 11 07:35:32 localhost kernel: EXT3 FS on dm-0, internal journal Mar 11 07:35:32 localhost kernel: kjournald starting. Commit interval 5 seconds Mar 11 07:35:32 localhost kernel: EXT3 FS on sda3, internal journal Mar 11 07:35:32 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode. Mar 11 07:35:32 localhost kernel: fuse init (API version 7.9) Mar 11 07:35:32 localhost kernel: Adding 2031608k swap on /dev/mapper/VolGroup00-LogVol01. Priority:-1 extents:1 across:2031608k Mar 11 07:35:32 localhost kernel: type=1400 audit(1205246125.183:3): avc: denied { sendto } for pid=1 comm="init" path=002F636F6D2F7562756E74752F757073746172742F31383031 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket Mar 11 07:35:32 localhost kernel: NET: Registered protocol family 10 Mar 11 07:35:32 localhost kernel: lo: Disabled Privacy Extensions Mar 11 07:35:32 localhost kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team Mar 11 07:35:32 localhost kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Mar 11 07:35:32 localhost kernel: type=1400 audit(1205246126.412:4): avc: denied { sendto } for pid=1 comm="init" path=002F636F6D2F7562756E74752F757073746172742F31393031 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket Mar 11 07:35:32 localhost kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Mar 11 07:35:32 localhost kernel: Loading iSCSI transport class v2.0-869. Mar 11 07:35:32 localhost kernel: iscsi: registered transport (tcp) Mar 11 07:35:32 localhost kernel: iscsi: registered transport (iser) Mar 11 07:35:32 localhost kernel: warning: `mcstransd' uses 32-bit capabilities (legacy support in use) Mar 11 07:35:32 localhost kernel: type=1400 audit(1205246132.030:5): avc: denied { read } for pid=2182 comm="rsyslogd" name="System.map-2.6.25-0.105.rc5.fc9" dev=sda3 ino=6051 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:system_map_t:s0 tclass=file
Backing out the new initscripts "makes it work" without the added policy. Something in initscripts-8.65-1.i386 appears to cause this.... Reassigning to initscrips. Sorry for the hasty assignment to upstart.
Its the calls to initctl in the new /etc/rc I bet :) selinux doesn't allow initctl to run from that context.
Right, but that shouldn't prevent booting at all.
OK, the reason this fails is that SELinux is confining *init*, not letting init send a response. Things go downhill from there. I think what needs to happen is that the init_telinit interface needs to be: ... dev_list_all_dev_nodes($1) allow $1 initctl_t:fifo_file rw_fifo_file_perms; allow $1 init_t:unix_dgram_socket sendto; allow init_t $1:unix_dgram_socket sendto; init_exec($1) ') Right now, we only allow one-way communication with init_telinit.
Fixed in selinux-policy-3.3.1-14.fc9