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:
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.
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.
Is it in /etc/inittab and not running, or not getting properly added on the first boot?
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.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
Is the type right on the inittab? Can you see where the denial is coming from?
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.
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)
inittab is modified kudzu. kudzu then calls telinit q. If kudzu doesn't have perms to actually signal init....
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
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?
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
Fixed in selinux-policy-2.4.6-37
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
Should be fixed in selinux-policy-2.4.6-47.el5
I am still seeing this bug on ppc64 with selinux-policy-2.4.6-49.el5 and the lspp.71 kernel.
Reopening based on comments #17.
Please attach avc messages.
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
Added privs to allow this in selinux-policy-mls-2.4.6-50.el5
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.
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
Created attachment 151714 [details] messages file This is the messages file with additional avcs in case they are of interest.
Oops, comment #24 goes along with this information from mra: 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
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
linda.knippers: Need a package to verify this.
George and Linda, please test this.
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.
Also broken on 54 policy
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
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.
I added allow kudzu_t init_t:process ptrace; but the problem still persists.
George, ok could you try with enableaudit.pp loaded.
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 };
I finally got a login prompt on first boot! Yay! I'm going to reinstall just to make sure. Thanks.
This is indeed fixed with the 55 policy. Thanks Dan, Linda, Matt and Bill.
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.
This appears to work just fine with the RHEL5 U1 Beta.
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