Race condition?
Posted: Sat Jul 15, 2006 12:47 pmRecently I've tried to get mgetty working on an RBAC enabled host.
I'm running x86 Hardened Gentoo. The kernel is based on 2.6.16-hardened-r9 including grsec-2.1.9-2.6.16.19-200606041421, but I've bumped kernel subversion from .19 to .24 and also applied some netfilter patch-o-matic extensions.
I had known, that I'll have hard times to get mgetty work, because wrong RBAC settings may render the machine unresponsive. My expectations were correct, since I've failed to create the necessary RBAC rules for the first couple of times. As I expected, the logs were populated by error messages. It wasn't suprising, that init sensed the problem, and disabled the fastly respawning mgetty.
But my kernel produced an oops for each unsuccesful try. I assume it shouldn't happen, even if I influenced some core components of the system.
It may be also important, that I'm using dazuko kernel module combined with clamuko. But it's enabled exclusively for /home.
Since I've managed to prepare the necessary permissions I've experienced no problems. Unfortunatelly I don't have the possibility to reproduce the symptoms on a grsec patched vanilla kernel.
I can also attach my config and dmesg upon request.
Is it an mgetty bug? But even if it is, the kernel shouldn't get hurt this way.
Regards,
Dw.
I'm running x86 Hardened Gentoo. The kernel is based on 2.6.16-hardened-r9 including grsec-2.1.9-2.6.16.19-200606041421, but I've bumped kernel subversion from .19 to .24 and also applied some netfilter patch-o-matic extensions.
I had known, that I'll have hard times to get mgetty work, because wrong RBAC settings may render the machine unresponsive. My expectations were correct, since I've failed to create the necessary RBAC rules for the first couple of times. As I expected, the logs were populated by error messages. It wasn't suprising, that init sensed the problem, and disabled the fastly respawning mgetty.
But my kernel produced an oops for each unsuccesful try. I assume it shouldn't happen, even if I influenced some core components of the system.
It may be also important, that I'm using dazuko kernel module combined with clamuko. But it's enabled exclusively for /home.
- Code: Select all
Jul 7 13:51:26 host grsec: (root:U:/) denied access to hidden file /var/log/mgetty by /usr/sbin/mgetty[mgetty:4500] uid/euid:
Jul 7 13:51:26 host grsec: (root:U:/) use of CAP_SYS_TTY_CONFIG denied for /usr/sbin/mgetty[mgetty:4500] uid/euid:0/0 gid/egi
Jul 7 13:51:26 host grsec: (root:U:/) use of CAP_SYS_TTY_CONFIG denied for /usr/sbin/mgetty[mgetty:4500] uid/euid:0/0 gid/egi
Jul 7 13:51:26 host grsec: (root:U:/) denied create of /var/run/mgetty.pid.ttyS1 for writing by /usr/sbin/mgetty[mgetty:4500]
Jul 7 13:51:26 host grsec: (root:U:/) denied create of /var/lock/LCK..TM.XoUfNb for reading writing by /usr/sbin/mgetty[mgett
Jul 7 13:51:26 host Unable to handle kernel NULL pointer dereference at virtual address 0000000c
Jul 7 13:51:26 host printing eip:
Jul 7 13:51:26 host c02a9e15
Jul 7 13:51:26 host *pgd = 0
Jul 7 13:51:26 host *pmd = 0
Jul 7 13:51:26 host Oops: 0000 [#1]
Jul 7 13:51:26 host SMP
Jul 7 13:51:26 host Modules linked in: eeprom w83781d hwmon_vid i2c_isa i2c_dev capability dazuko i2c_amd756 radeon pktcdvd c
Jul 7 13:51:26 host CPU: 0
Jul 7 13:51:26 host EIP: 0060:[<c02a9e15>] Not tainted VLI
Jul 7 13:51:26 host EFLAGS: 00010202 (2.6.16-hardened-r7 #5)
Jul 7 13:51:26 host EIP is at gr_check_hidden_task+0x15/0x40
Jul 7 13:51:26 host eax: 00000000 ebx: c05b9980 ecx: c05b9980 edx: 00000000
Jul 7 13:51:26 host esi: c1906e1c edi: cb9c6534 ebp: cb9c6534 esp: cfe69d10
Jul 7 13:51:26 host ds: 007b es: 007b ss: 0068
Jul 7 13:51:26 host Process mgetty (pid: 4500, threadinfo=cfe68000 task=dacf1030)
Jul 7 13:51:26 host Stack: <0>c01ebfdb c05b9980 00000000 cb9c6534 fffffff4 c1906e1c cb9c6534 c1906e90
Jul 7 13:51:26 host c01bce85 c1906e1c cb9c6534 cfe69ee4 00000000 cfe69d9c cfe69ee4 c18e71a0
Jul 7 13:51:26 host c01bd1bd c1901614 cfe69da4 cfe69ee4 eb15c008 00002121 cfe69da4 eb15c006
Jul 7 13:51:26 host Call Trace:
Jul 7 13:51:26 host [<c01ebfdb>] proc_pid_lookup+0x6b/0x260
Jul 7 13:51:26 host [<c01bce85>] real_lookup+0xc5/0x100
Jul 7 13:51:26 host [<c01bd1bd>] do_lookup+0x9d/0xb0
Jul 7 13:51:26 host [<c01bd2ee>] __link_path_walk+0x11e/0xf90
Jul 7 13:51:26 host [<c01bd68e>] __link_path_walk+0x4be/0xf90
Jul 7 13:51:26 host [<c01be1b9>] link_path_walk+0x59/0x100
Jul 7 13:51:26 host [<c01ac7b0>] get_unused_fd+0x40/0x100
Jul 7 13:51:26 host [<c01be590>] do_path_lookup+0x120/0x260
Jul 7 13:51:26 host [<c01ae642>] get_empty_filp+0x82/0x140
Jul 7 13:51:26 host [<c01be731>] __path_lookup_intent_open+0x41/0x80
Jul 7 13:51:26 host [<c01be7a7>] path_lookup_open+0x37/0x40
Jul 7 13:51:26 host [<c01bf12c>] open_namei+0x8c/0x780
Jul 7 13:51:26 host [<c0161b50>] __wake_up+0x40/0x60
Jul 7 13:51:26 host [<c01ac5ca>] do_filp_open+0x3a/0x60
Jul 7 13:51:26 host [<c01ac7b0>] get_unused_fd+0x40/0x100
Jul 7 13:51:26 host [<c01ac9a3>] do_sys_open+0x63/0x110
Jul 7 13:51:26 host [<c01aca77>] sys_open+0x27/0x30
Jul 7 13:51:26 host [<c01450b9>] syscall_call+0x7/0xb
Jul 7 13:51:26 host Code: 24 1c 8b 6c 24 20 83 c4 24 c3 25 ff 03 f0 ff e9 5e ff ff ff 89 f6 31 d2 f6 05 4c 19 69 c0 01 74 2a
Jul 7 13:51:26 host BUG: mgetty/4500, lock held at task exit time!
Jul 7 13:51:26 host [c1906e90] {inode_init_once}
Jul 7 13:51:26 host .. held by: mgetty: 4500 [dacf1030, 117]
Jul 7 13:51:26 host ... acquired at: real_lookup+0x24/0x100
Since I've managed to prepare the necessary permissions I've experienced no problems. Unfortunatelly I don't have the possibility to reproduce the symptoms on a grsec patched vanilla kernel.
I can also attach my config and dmesg upon request.
Is it an mgetty bug? But even if it is, the kernel shouldn't get hurt this way.
Regards,
Dw.