grsecurity forums

Hi,

I just played with subject mode Z and got a kernel crash when I logged in as a user which had the following policy in its user role specification

Code: Select all

subject /bin/ls {
        /usr h
        bind disabled
        connect disabled
}

subject /bin/ls Z {
        /usr/src        r
        bind disabled
        connect disabled
}


System info: Gentoo 3.13.10-hardened, gradm v3.0

I just got the following message on the screen

Code: Select all

 ce5035c0 ce4fcac0 ce4f8880 00000312 001abebb 000003e8 00200282 ce551400
 ce551a80 ce5035c0 0004ddb0 ce551400 00000000 ce551a80 00000312 0003e879
 00000312 00000312 00000060 51777e90 ce503764 003961e3 00000312 00000312
Call Trace:
 [<001abebb>] ? gr_set_role_labe1+0x5b/0x1b0
 [<00200282>] ? acpi_pci_link_get_current+0x56/0xbe
 [<0004ddb0>] ? __commit_creds+0x50/0x180
 [<0003e879>] ? SyS_setresuid+0x129/0x140
 [<003961e3>] ? syscall_call+0x7/0xb
 [<00200246>] ? acpi_pci_link_get_current+0x1a/0xbe
 [<0039007b>] ? bug_at+0x38/0x4c
 [<00200246>] ? acpi_pci_link_get_current+0x1a/0xbe
 [<0000b069>] ? pax_randomize_kstack+0x39/0x40
 [<00396204>] ? restore_all_pax+0x7/0x7
 [<00210202>] ? acpi_hw_legacy_sleep+0x136/0x156
Code: 40 20 e8 9e fb ff ff 85 c0 75 8a al cc 4c 09 c2 89 e9 8b 50 7c 8b 40 14 8b 92 84 00 00 00 8b 40 20 e8 7f fb ff ff e9 6a ff ff ff <01> Ob 90 8d b4 26 00 00 00 00 57 56 89 c6 53 83 ec 08 8b ld 6c
EIP: [<001aaf76>] chk_subj_label+0xe6/0x10 SS:ESP 0068:ce68de9c
---[ end trace 8cbc463235c55e34 ]---
Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
atkbd serio0: Spurious ACE on isa0060/serio0. Some program might be trying to access hardware directly.


The crash is repeatable.

Regards

a few things:

1. chk_subj_label is RBAC code, so you'll have to wait till next week when spender can take a look
2. in the meantime, can you reproduce this with 3.14.x?
3. can you turn on frame pointers to get a better backtrace and perhaps also some remote logging (serial/netconsole/qemu) so that the beginning of the oops is visible as well?

There you go for 3.13.10 with frame pointers:

Code: Select all

kernel BUG at grsecurity/gracl.c:1038!
invalid opcode: 0000 [#1]
Modules linked in:
CPU: 0 PID: 1309 Comm: sshd Not tainted 3.13.10-hardened #3
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: cfa99600 ti: cfa9975c task.ti: cfa9975c
EIP: 0060:[<001ab1dc>] EFLAGS: 00210246 CPU: 0
EAX: 00000000 EBX: cf40a580 ECX: ce0d7940 EDX: 00000001
ESI: cf81725c EDI: cf817200 EBP: cf989ea8 ESP: cf989e98
 DS: 0068 ES: 0068 FS: 0000 GS: 007b SS: 0068
CR0: 80050033 CR2: b1d68180 CR3: 0fab8000 CR4: 00040790
Stack:
 ce0d7940 cfa99600 ce0d7940 cfb24180 cf989ec4 001ac0bf 000003e8 00200202
 cfa3c980 cfa3ca00 cfa99600 cf989edc 0004df38 cfa3ca00 cfa3c980 00000000
 cfa3ca00 cf989ef0 0004e09a 0003e651 cfa3c980 00000000 cf989f0c 0003e9ec
Call Trace:
 [<001ac0bf>] gr_set_role_label+0x5f/0x1b0
 [<00200202>] ? acpi_ns_convert_to_string+0x2f/0x98
 [<0004df38>] __commit_creds+0x48/0x190
 [<0004e09a>] commit_creds+0x1a/0xc0
 [<0003e651>] ? set_user+0x41/0x70
 [<0003e9ec>] SyS_setresuid+0x12c/0x150
 [<00384e93>] syscall_call+0x7/0xb
 [<00200246>] ? acpi_ns_convert_to_string+0x73/0x98
 [<0000b0cc>] ? pax_randomize_kstack+0x3c/0x40
 [<00384eb4>] ? restore_all_pax+0x7/0x7
 [<0038007b>] ? printk_sched+0x32/0x4e
 [<00200246>] ? acpi_ns_convert_to_string+0x73/0x98
 [<00200246>] ? acpi_ns_convert_to_string+0x73/0x98
 [<00210246>] ? resources_store+0xc6/0x300
Code: 9b fb ff ff 85 c0 75 87 a1 cc 4c 09 c2 8b 4d f0 8b 10 8b 40 14 8b 92 c0 01 00 00 8b 80 1c 01 00 00 e8 79 fb ff ff e9 64 ff ff ff <0f> 0b 66 90 55 89 e5 57 56 89 c6 53 83 ec 08 8b 1d 6c 4c 09 c2
EIP: [<001ab1dc>] chk_subj_label+0xec/0xf0 SS:ESP 0068:cf989e98
---[ end trace b496a56184cc588f ]---
Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.


This was produced on a different but similar virtual machine (KVM) upon logging in through SSH as the user whose user role policy contained

Code: Select all

subject /tmp/hello_world
        /tmp                    x
        /tmp/hello_world        x
        /var/tmp                h

subject /tmp/hello_world        Z
        /tmp                    h
        /tmp/hello_world        x
        /var/tmp                rwcd


Trying a few variations:

• First ssh, then gradm -E: crash
• simply duplicating the subject definition: crash
• scp instead of ssh: crash

ssh-ing into the machine as someone else doesn't crash the kernel.

Regards

Same for 3.14.3-hardened-r2

Regards

I was away on vacation, but will look into this.

Thanks,
-Brad

It should be fixed with the latest gradm. Let me know if you still have problems.

Thanks for the report!
-Brad

Now I found time to look at this again.

Looks good, no crashes.