Bug 225443 - LSPP: No console login on first boot
LSPP: No console login on first boot
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.0
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-01-30 12:29 EST by George C. Wilson
Modified: 2009-06-19 10:09 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0544
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 11:38:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
messages file (146.23 KB, application/octet-stream)
2007-04-04 16:51 EDT, Linda Knippers
no flags Details

  None (edit)
Description George C. Wilson 2007-01-30 12:29:03 EST
Description of problem:

On a ppc64 LPAR I installed RHEL 5 Snap 7 (20070112) build with lspp.64 kernel,
selinux-policy-mls-2.4.6-32, libselinux-1.33.4-2, policycoreutils-1.33.12-1,
openssh-server-4.3p2-16, and the certification RPM / kickstart Version 18 from
Klaus Weidner.  Upon first boot, no login prompt is present on the console.

How reproducible:

Install Snap 7 with the 18 kickstart script.  During the postinstall phase,
install the recommended upgrade packages from the dwalsh and sgrubb repos.  Have
the post script install the 18 cert rpm.  Reboot at the reboot prompt.  On first
boot no console login prompt is presented.  Reboot the system.  The console
login is presented.

Testing by Linda Knippers showed that no mingetty was running on the console. 
init b causes an agetty to be run on the console instead of the mingetty
specified in /etc/inittab.  init s followed by init 3 causes the mingetty to be
run much like rebooting.

Steps to Reproduce:
1. Do a RHEL5 Snap 7 kickstart install using the 18 script.
2. During the post install phase, install recommended upgrade packages from the
dwalsh and sgrubb people page repos.
3. Let the post install script install the 18 certification rpm.
4. Reboot the system.
5. No console login will be presented.
  
Actual results:  No console login prompt.


Expected results:  Console login prompt.


Additional info:
Comment 1 Linda Knippers 2007-02-01 15:12:12 EST
Slight correction to the original posting, at least my part of it.
I saw the same thing with snapshot 6 on ia64, on a system with a serial console.

I can ssh in and see that there is no getty running on the console port
(/dev/ttyS1 in my case).  There are mingetty's running on the other tty
ports.  All my tty devices appear to be labeled correctly.  I don't see any
messages in the audit log or messages file that indicate a problem.

If I run "init q" I immediately get an agetty  which is what I'd expect 
based on the /etc/inittab on my system.  For some reason it looks like
the agetty isn't getting started on the first boot or is started and 
fails in a way that init doesn't notice.

I don't see any AVC messages or anything in /var/log messages or /var/log/secure
that provide any clues.

I will retest with the rc.
Comment 2 Linda Knippers 2007-02-01 19:21:59 EST
I just retested with the Jan 31 rc using an updated version of the
kickstart scripts (posted to the lspp list today) that allows me to
pick either a CAPP or an LSPP configuation.  There are few differences,
mostly just the policy and setting up polyinstantiation.

When I install an LSPP system, I have the problem with not getting
a login prompt on the console on the first boot.  When I install a 
CAPP system, I get a login promp on the first boot. 

If there's something you'd like me to instrument and try, let me know.
Comment 3 Bill Nottingham 2007-02-03 12:02:42 EST
Is it in /etc/inittab and not running, or not getting properly added on the
first boot?
Comment 4 Linda Knippers 2007-02-03 15:46:55 EST
My system is in the state now where's its rebooted after the kickstall 
installation and there's no getty running.  The getty line is in the
inittab (see below).  

#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
co:2345:respawn:/sbin/agetty ttyS1 9600 vt100-nav
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon
Comment 5 Bill Nottingham 2007-02-03 15:52:21 EST
Is the type right on the inittab? Can you see where the denial is coming from?
Comment 6 Linda Knippers 2007-02-03 16:19:01 EST
By type do you me the selinux type on the file?  It looks right.
-rw-r--r--  root root system_u:object_r:etc_runtime_t:SystemLow /etc/inittab

The /dev/ttyS1 device looks right.
crw-rw----  root uucp system_u:object_r:tty_device_t:SystemLow /dev/ttyS1

If I 'init q' the agetty will start and the device special file will
have a group of root.

I don't see any AVC denies or errors in any of the log files.  I think
I can escape from the ks script before the first boot and if so, I'll 
look at the inittab then.  
Comment 7 Linda Knippers 2007-02-07 15:05:09 EST
I built a debug version of /sbin/init and put it on my system before the
first boot.  I think the console line is not in the inittab at the time
init first runs:

Feb  7 14:54:51 cert-i4 init: Checking for children to start
Feb  7 14:54:51 cert-i4 init: Started id 1 (pid 1815)
Feb  7 14:54:51 cert-i4 init: Started id 2 (pid 1816)
Feb  7 14:54:51 cert-i4 init: Started id 3 (pid 1817)
Feb  7 14:54:51 cert-i4 init: Started id 4 (pid 1818)
Feb  7 14:54:51 cert-i4 init: Started id 5 (pid 1819)
Feb  7 14:54:51 cert-i4 init: Started id 6 (pid 1820)

The inittab file is updated about the same time but could
we have a race?

-rw-r--r--  1 root root    49152 Feb  7 14:54 aliases.db
drwxr-xr-x  2 root root     4096 Feb  7 14:54 ssh
-rw-r--r--  1 root root      135 Feb  7 14:54 printcap
-rw-r--r--  1 root root     1716 Feb  7 14:54 inittab
-rw-------  1 root root      128 Feb  7 14:54 securetty
drwxr-xr-x  9 root root     4096 Feb  7 14:54 sysconfig
drwxr-xr-x  2 root root     4096 Feb  7 14:54 blkid
-rw-r--r--  1 root root      419 Feb  7 14:54 mtab

If I 'init q' then init sees the console entry:

INIT: Checking for children to start
INIT: Started id co (pid 2865)
INIT: Started id 1 (pid 2866)
INIT: Started id 2 (pid 2867)
INIT: Started id 3 (pid 2868)
INIT: Started id 4 (pid 2869)
INIT: Started id 5 (pid 2871)
INIT: Started id 6 (pid 2876)

Comment 8 Bill Nottingham 2007-02-07 15:07:59 EST
inittab is modified kudzu. kudzu then calls telinit q. If kudzu doesn't have
perms to actually signal init....
Comment 9 Linda Knippers 2007-02-07 15:14:13 EST
Ah, I found this in the /var/log/messages file.

Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:272): avc:  denied  {
getattr } for  pid=1374 comm="sh" name="initctl" dev=tmpfs ino=1273
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file
Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:273): avc:  denied  {
search } for  pid=1374 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:274): avc:  denied  {
search } for  pid=1374 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
Comment 10 Linda Knippers 2007-02-09 15:35:04 EST
I re-installed and did the first boot in permissive mode to see if that
would uncover any additional avcs.  I found these in the messages file:

Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:272): avc:  denied  {
getattr } for  pid=1374 comm="sh" name="initctl" dev=tmpfs ino=1273
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file
Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:273): avc:  denied  {
search } for  pid=1374 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
Feb  7 14:54:47 cert-i4 kernel: audit(1170878082.112:274): avc:  denied  {
search } for  pid=1374 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir

An audit2allow says this:
allow kudzu_t init_exec_t:file { execute_no_trans getattr read };
allow kudzu_t init_t:dir search;
allow kudzu_t init_t:lnk_file read;
allow kudzu_t init_t:process ptrace;
allow kudzu_t initctl_t:fifo_file { getattr write };
allow kudzu_t self:capability sys_ptrace;

Does that look right?
Comment 11 Linda Knippers 2007-02-09 15:37:45 EST
Actually, those were the old avcs.  This is the full set:

Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:271): avc:  denied  {
getattr } for  pid=1374 comm="sh" name="initctl" dev=tmpfs ino=1268
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:272): avc:  denied  {
search } for  pid=1374 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:273): avc:  denied  { read
} for  pid=1374 comm="sh" name="exe" dev=proc ino=65544
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=lnk_file
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:274): avc:  denied  {
sys_ptrace } for  pid=1374 comm="sh" capability=19
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=capability
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:275): avc:  denied  {
ptrace } for  pid=1374 comm="sh"
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=process
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.056:276): avc:  denied  {
getattr } for  pid=1374 comm="sh" name="init" dev=dm-0 ino=458850
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:init_exec_t:s0 tclass=file
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.057:277): avc:  denied  {
execute_no_trans } for  pid=1375 comm="sh" name="init" dev=dm-0 ino=458850
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:init_exec_t:s0 tclass=file
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.057:278): avc:  denied  { read
} for  pid=1375 comm="sh" name="init" dev=dm-0 ino=458850
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:init_exec_t:s0 tclass=file
Feb  9 15:23:50 cert-i4 kernel: audit(1171052628.058:279): avc:  denied  { write
} for  pid=1375 comm="telinit" name="initctl" dev=tmpfs ino=1268
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file
Comment 12 Daniel Walsh 2007-02-12 10:01:28 EST
Fixed in selinux-policy-2.4.6-37
Comment 15 Linda Knippers 2007-03-21 18:17:09 EDT
Matt just installed an ia64 system and loaded the latest policy 
before the first boot.  He still saw the problem with no console
login prompt and found the following AVC denies in the messages file.

I don't see any kudzu module changes when I compare the latest policy
sources to some old ones, so I don't know if my old sources aren't old
enough of if the fix to this problem got dropped.  It looks like a
different fix was submitted for inclusion upstream.

The nash-hotplug one is unreleated but puzzling as well. 

bash-3.1# grep avc /var/log/messages | grep denied
Mar 21 17:28:28 cert-i1 kernel: audit(1174516092.318:3): avc:  denied  {
write } for  pid=351 comm="nash-hotplug" name="zero" dev=tmpfs ino=713
scontext=system_u:system_r:kernel_t:s15:c0.c1023
tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
Mar 21 17:28:29 cert-i1 kernel: audit(1174516101.393:274): avc:  denied
 { getattr } for  pid=1257 comm="sh" name="initctl" dev=tmpfs ino=1243
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file
Mar 21 17:28:29 cert-i1 kernel: audit(1174516101.393:275): avc:  denied
 { sys_ptrace } for  pid=1257 comm="sh" capability=19
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=capability
Mar 21 17:28:29 cert-i1 kernel: audit(1174516101.393:276): avc:  denied
 { sys_ptrace } for  pid=1257 comm="sh" capability=19
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=capability
Comment 16 Daniel Walsh 2007-03-26 16:19:05 EDT
Should be fixed in selinux-policy-2.4.6-47.el5
Comment 17 George C. Wilson 2007-03-28 19:41:41 EDT
I am still seeing this bug on ppc64 with selinux-policy-2.4.6-49.el5 and the
lspp.71 kernel.
Comment 18 Irina Boverman 2007-03-29 10:50:13 EDT
Reopening based on comments #17.
Comment 19 Daniel Walsh 2007-03-30 10:40:11 EDT
Please attach avc messages.
Comment 20 George C. Wilson 2007-04-01 13:38:57 EDT
grep denied messages
Apr  1 11:47:37 hvracer4 kernel: audit(1175446041.298:319): avc:  denied  {
search } for  pid=1602 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
Apr  1 11:47:37 hvracer4 kernel: audit(1175446041.299:320): avc:  denied  {
search } for  pid=1602 comm="sh" name="1" dev=proc ino=65538
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=dir
[root/sysadm_r/SystemLow@hvracer4 log]# uname -a
Linux hvracer4.ltc.austin.ibm.com 2.6.18-8.1.1.lspp.72.el5 #1 SMP Wed Mar 28
16:15:08 EDT 2007 ppc64 ppc64 ppc64 GNU/Linux
[root/sysadm_r/SystemLow@hvracer4 log]# rpm -q selinux-policy-mls
selinux-policy-mls-2.4.6-49.el5
Comment 21 Daniel Walsh 2007-04-02 13:32:26 EDT
Added privs to allow this in selinux-policy-mls-2.4.6-50.el5
Comment 22 George C. Wilson 2007-04-03 16:19:27 EDT
This is still broken on a ppc64 LPAR running selinux-policy-mls-2.4.6-50.el5.
But no more AVCs :-/ Checked both /var/log/messages, audit.log, and really
everything in /var/log.
Comment 23 George C. Wilson 2007-04-03 17:33:07 EDT
FYI on a ppc64 lpar, the console device is usually /dev/hvc0:

  [root/sysadm_r/SystemLow@hvracer4 log]# grep hvc /etc/inittab
  co:2345:respawn:/sbin/agetty hvc0 38400 vt100-nav

  [root/sysadm_r/SystemLow@hvracer4 log]# cat /proc/cmdline
  root=/dev/rootvg/rootlv ro console=hvc0

After first boot (no console login):

  [root/sysadm_r/SystemLow@hvracer4 log]# ls -Z /dev/hvc0
  crw-rw----  root uucp system_u:object_r:tty_device_t:SystemLow /dev/hvc0

After 2nd boot (console appears):

  [root/sysadm_r/SystemLow@hvracer4 root]# ls -Z /dev/hvc0
  crw-------  root root system_u:object_r:tty_device_t:SystemLow /dev/hvc0
Comment 24 Linda Knippers 2007-04-04 16:51:27 EDT
Created attachment 151714 [details]
messages file

This is the messages file with additional avcs in case they
are of interest.
Comment 25 Linda Knippers 2007-04-04 16:52:42 EDT
Oops, comment #24 goes along with this information from mra@hp.com:

On Steve's suggestion I loaded enableaudit.pp prior to the first boot on
my ia64 test system.  After the reboot there wasn't a console prompt but I was
able to ssh in, here are the AVCs related to kudzu that I found in
/var/log/messages.

grep kudzu messages
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.504:902): avc:  denied
 { siginh } for  pid=1245 comm="kudzu"
scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=process
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.504:903): avc:  denied
 { rlimitinh } for  pid=1245 comm="kudzu"
scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=process
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.505:904): avc:  denied
 { noatsecure } for  pid=1245 comm="kudzu"
scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=process
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.590:905): avc:  denied
 { execute } for  pid=1246 comm="sh" name="init" dev=dm-0 ino=918115
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:object_r:init_exec_t:s0 tclass=file
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.591:906): avc:  denied
 { sys_ptrace } for  pid=1246 comm="sh" capability=19
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=capability
Apr  4 16:21:40 cert-i1 kernel: audit(1175721684.591:907): avc:  denied
 { sys_ptrace } for  pid=1246 comm="sh" capability=19
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023 tclass=capability

-matt
Comment 26 Daniel Walsh 2007-04-05 10:22:22 EDT
I think the init execute is the problem.   This is in the rawhide version but
not in the RHEL5.

Fixed in selinux-policy-2.4.6-52
Comment 27 George C. Wilson 2007-04-09 16:17:52 EDT
linda.knippers: Need a package to verify this.
Comment 28 George C. Wilson 2007-04-10 11:37:14 EDT
George and Linda, please test this.
Comment 29 George C. Wilson 2007-04-10 15:44:29 EDT
This is still broken on a ppc64 LPAR with the 73 kernel and 53 policy. I will
look at the install and try to provide useful logs.
Comment 30 George C. Wilson 2007-04-10 17:06:04 EDT
Also broken on 54 policy
Comment 31 Daniel Walsh 2007-04-10 17:17:35 EDT
54 just fixes a file_context problem in 54.  Could you run this test in
permissive mode so we can gather all of the avc messages and see what is going on.

Dan
Comment 32 George C. Wilson 2007-04-10 18:47:27 EDT
I reinstalled and booted the ppc64 LPAR with enforcing=0. This is the only avc
denied message it produces either in audit.log or /var/log/messages:

Apr 10 16:39:39 hvracer4 kernel: audit(1176241163.999:318): avc:  denied  {
ptrace } for  pid=1604 comm="sh"
scontext=system_u:system_r:kudzu_t:s0-s15:c0.c1023
tcontext=system_u:system_r:init_t:s0-s15:c0.c1023 tclass=process

Dunno if allowing that is sufficient to fix the issue. I'll gen a module and
install it during the install.
Comment 33 George C. Wilson 2007-04-10 20:53:28 EDT
I added

allow kudzu_t init_t:process ptrace;

but the problem still persists.
Comment 34 Daniel Walsh 2007-04-11 10:14:12 EDT
George, ok could you try with enableaudit.pp loaded.

Comment 35 Linda Knippers 2007-04-11 13:34:35 EDT
In comment 24 mra had run the enableaudit.pp and provided the avcs so it
will be interesting to see what George discovers. 

I've been experimenting with some policy tools and when I use the 
dispol test tool that's in the checkpolicy src rpm, I can see all
the kudzu/init related rules.  With the .54 policy I see quite
a few dontaudits, like:

dontaudit initrc_t kudzu_var_run_t : file { ioctl write };
dontaudit initrc_t kudzu_exec_t : file { execute };
dontaudit kudzu_t initrc_exec_t : file { execute };
dontaudit kudzu_t init_exec_t : file { execute };
dontaudit kudzu_t initrc_su_t : fd { use };
dontaudit kudzu_t run_init_exec_t : file { execute };
dontaudit run_init_t kudzu_var_run_t : dir { search };
dontaudit run_init_t kudzu_tmp_t : dir { search };
dontaudit run_init_t kudzu_exec_t : dir { search };
dontaudit initrc_t kudzu_t : process { noatsecure siginh rlimitinh };
dontaudit initrc_t kudzu_t : fifo_file { getattr };
dontaudit initrc_t kudzu_t : tcp_socket { getattr };
dontaudit initrc_t kudzu_t : udp_socket { getattr };
dontaudit initrc_t kudzu_t : unix_dgram_socket { getattr };

Some of these show up in the avcs that mra generated.

Looks like the most recent policy update is this addition:
allow kudzu_t init_exec_t : file { ioctl read getattr lock execute
execute_no_trans };

Does that look right?

The only rule I see related to ptrace is this:

allow initrc_t kudzu_t : process { transition sigchld sigkill sigstop signull
signal ptrace getsession getattr };

Comment 36 George C. Wilson 2007-04-11 21:25:17 EDT
I finally got a login prompt on first boot! Yay! I'm going to reinstall just to
make sure. Thanks.
Comment 37 George C. Wilson 2007-04-12 16:48:40 EDT
This is indeed fixed with the 55 policy. Thanks Dan, Linda, Matt and Bill.
Comment 40 John Poelstra 2007-08-14 15:41:49 EDT
A fix for this issue has been included in the packages contained in the beta
(RHN channel) or most recent snapshot (partners.redhat.com) for RHEL5.1.  Please
verify that your issue is fixed.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to ASSIGNED.
Comment 41 Linda Knippers 2007-08-15 10:54:39 EDT
This appears to work just fine with the RHEL5 U1 Beta.
Comment 43 errata-xmlrpc 2007-11-07 11:38:13 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0544.html

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