* file access causes a kernel bug
@ 2014-01-29 8:04 Matthew Thode
2014-01-29 8:11 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-29 8:04 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]
This happens consistantly, just ls a particular dir and wheeeeee.
[ 473.893141] ------------[ cut here ]------------
[ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
[ 473.995314] invalid opcode: 0000 [#6] SMP
[ 474.027196] Modules linked in:
[ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
3.13.0-grsec #1
[ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
[ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[ 474.556058] Stack:
[ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[ 474.690461] Call Trace:
[ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
[ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
[ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
[ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
[ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
[ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
[ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
[ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
[ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
[ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
[ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
[ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
[ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
[ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[ 475.255884] RIP [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[ 475.296120] RSP <ffff8805c0ac3c38>
[ 475.328734] ---[ end trace f076482e9d754adc ]---
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 8:04 file access causes a kernel bug Matthew Thode
@ 2014-01-29 8:11 ` Matthew Thode
2014-01-29 13:55 ` Paul Moore
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-29 8:11 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]
On 01/29/2014 02:04 AM, Matthew Thode wrote:
> This happens consistantly, just ls a particular dir and wheeeeee.
>
> [ 473.893141] ------------[ cut here ]------------
> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
> [ 473.995314] invalid opcode: 0000 [#6] SMP
> [ 474.027196] Modules linked in:
> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
> 3.13.0-grsec #1
> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
> 07/29/10
> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
> ffff8805f50cd488
> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
> context_struct_compute_av+0xce/0x308
> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
> 0000000000000100
> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
> ffff8805e8aaa000
> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
> 0000000000000006
> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
> 0000000000000006
> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
> 0000000000000000
> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
> knlGS:0000000000000000
> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
> 00000000000207f0
> [ 474.556058] Stack:
> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
> ffff8805f1190a40
> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
> ffff8805e8aac860
> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
> ffff8805c0ac3d94
> [ 474.690461] Call Trace:
> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
> [ 475.255884] RIP [<ffffffff814681c7>]
> context_struct_compute_av+0xce/0x308
> [ 475.296120] RSP <ffff8805c0ac3c38>
> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
sorry, forgot to add, this is for 3.13.0 as well.
ls ./.config/ipython/profile_default/
Segmentation fault
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 8:11 ` Matthew Thode
@ 2014-01-29 13:55 ` Paul Moore
2014-01-29 14:07 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Paul Moore @ 2014-01-29 13:55 UTC (permalink / raw)
To: selinux, mthode
On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
> On 01/29/2014 02:04 AM, Matthew Thode wrote:
> > This happens consistantly, just ls a particular dir and wheeeeee.
> >
> > [ 473.893141] ------------[ cut here ]------------
> > [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
> > [ 473.995314] invalid opcode: 0000 [#6] SMP
> > [ 474.027196] Modules linked in:
> > [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
> > 3.13.0-grsec #1
> > [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
> > 07/29/10
> > [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
> > ffff8805f50cd488
> > [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
> > context_struct_compute_av+0xce/0x308
> > [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
> > [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
> > 0000000000000100
> > [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
> > ffff8805e8aaa000
> > [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
> > 0000000000000006
> > [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
> > 0000000000000006
> > [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
> > 0000000000000000
> > [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
> > knlGS:0000000000000000
> > [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
> > 00000000000207f0
> > [ 474.556058] Stack:
> > [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
> > ffff8805f1190a40
> > [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
> > ffff8805e8aac860
> > [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
> > ffff8805c0ac3d94
> > [ 474.690461] Call Trace:
> > [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
> > [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
> > [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
> > [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
> > [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
> > [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
> > [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
> > [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
> > [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
> > [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
> > [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
> > [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
> > [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
> > [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
> > 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
> > 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
> > [ 475.255884] RIP [<ffffffff814681c7>]
> > context_struct_compute_av+0xce/0x308
> > [ 475.296120] RSP <ffff8805c0ac3c38>
> > [ 475.328734] ---[ end trace f076482e9d754adc ]---
> >
>
> sorry, forgot to add, this is for 3.13.0 as well.
>
> ls ./.config/ipython/profile_default/
> Segmentation fault
Thanks for passing this along, but can you elaborate a bit more on this?
Distribution? Kernel package? SELinux policy? Any unusual configuration?
etc.
I ask because I'm not seeing this problem on my system and it seems like a
fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
expect we would be flooded with angry users right now ...
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 13:55 ` Paul Moore
@ 2014-01-29 14:07 ` Stephen Smalley
2014-01-29 14:17 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-29 14:07 UTC (permalink / raw)
To: Paul Moore, selinux, mthode
On 01/29/2014 08:55 AM, Paul Moore wrote:
> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>
>>> [ 473.893141] ------------[ cut here ]------------
>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>> [ 474.027196] Modules linked in:
>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>> 3.13.0-grsec #1
>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>> 07/29/10
>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>> ffff8805f50cd488
>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>> context_struct_compute_av+0xce/0x308
>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>> 0000000000000100
>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>> ffff8805e8aaa000
>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>> 0000000000000006
>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>> 0000000000000006
>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>> 0000000000000000
>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>> knlGS:0000000000000000
>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>> 00000000000207f0
>>> [ 474.556058] Stack:
>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>> ffff8805f1190a40
>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>> ffff8805e8aac860
>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>> ffff8805c0ac3d94
>>> [ 474.690461] Call Trace:
>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>> context_struct_compute_av+0xce/0x308
>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>
>>
>> sorry, forgot to add, this is for 3.13.0 as well.
>>
>> ls ./.config/ipython/profile_default/
>> Segmentation fault
>
> Thanks for passing this along, but can you elaborate a bit more on this?
> Distribution? Kernel package? SELinux policy? Any unusual configuration?
> etc.
>
> I ask because I'm not seeing this problem on my system and it seems like a
> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
> expect we would be flooded with angry users right now ...
Does it happen on any filesystem other than ZFS?
Do you have any prior SELinux output leading up to this bug?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 14:07 ` Stephen Smalley
@ 2014-01-29 14:17 ` Stephen Smalley
2014-01-29 16:58 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-29 14:17 UTC (permalink / raw)
To: Paul Moore, selinux, mthode
On 01/29/2014 09:07 AM, Stephen Smalley wrote:
> On 01/29/2014 08:55 AM, Paul Moore wrote:
>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>
>>>> [ 473.893141] ------------[ cut here ]------------
>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>> [ 474.027196] Modules linked in:
>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>> 3.13.0-grsec #1
>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>> 07/29/10
>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>> ffff8805f50cd488
>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>> context_struct_compute_av+0xce/0x308
>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>> 0000000000000100
>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>> ffff8805e8aaa000
>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>> 0000000000000006
>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>> 0000000000000006
>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>> 0000000000000000
>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>> knlGS:0000000000000000
>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>> 00000000000207f0
>>>> [ 474.556058] Stack:
>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>> ffff8805f1190a40
>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>> ffff8805e8aac860
>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>> ffff8805c0ac3d94
>>>> [ 474.690461] Call Trace:
>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>> context_struct_compute_av+0xce/0x308
>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>
>>>
>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>
>>> ls ./.config/ipython/profile_default/
>>> Segmentation fault
>>
>> Thanks for passing this along, but can you elaborate a bit more on this?
>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>> etc.
>>
>> I ask because I'm not seeing this problem on my system and it seems like a
>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>> expect we would be flooded with angry users right now ...
>
> Does it happen on any filesystem other than ZFS?
>
> Do you have any prior SELinux output leading up to this bug?
Also, what policy are you using and what is the security context on that
file?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 14:17 ` Stephen Smalley
@ 2014-01-29 16:58 ` Matthew Thode
2014-01-29 21:36 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-29 16:58 UTC (permalink / raw)
To: Stephen Smalley, Paul Moore, selinux, Richard Yao, behlendorf
[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]
On 01/29/2014 08:17 AM, Stephen Smalley wrote:
> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>
>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>> [ 474.027196] Modules linked in:
>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>> 3.13.0-grsec #1
>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>> 07/29/10
>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>> ffff8805f50cd488
>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>> context_struct_compute_av+0xce/0x308
>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>> 0000000000000100
>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>> ffff8805e8aaa000
>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>> 0000000000000006
>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>> 0000000000000006
>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>> 0000000000000000
>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>> knlGS:0000000000000000
>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>> 00000000000207f0
>>>>> [ 474.556058] Stack:
>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>> ffff8805f1190a40
>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>> ffff8805e8aac860
>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>> ffff8805c0ac3d94
>>>>> [ 474.690461] Call Trace:
>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>> context_struct_compute_av+0xce/0x308
>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>
>>>>
>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>
>>>> ls ./.config/ipython/profile_default/
>>>> Segmentation fault
>>>
>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>> etc.
>>>
>>> I ask because I'm not seeing this problem on my system and it seems like a
>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>> expect we would be flooded with angry users right now ...
>>
>> Does it happen on any filesystem other than ZFS?
>>
>> Do you have any prior SELinux output leading up to this bug?
>
> Also, what policy are you using and what is the security context on that
> file?
>
Ok, one at a time :D
I'm on gentoo using the strict policy (in permissive for now...)
Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
patches went in :D))
using basepol 2.20130424
No unusual config that I can think of. I've found multiple files that
this happens with).
Only on zfs that I can see
Dunno what you mean by prior selinux output, just some random selinux
denials because restorecon -RF fails because of this.
I can't see either the file name or the context of that file. As soon
as anything tries to access anything about the file I get that backtrace.
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 16:58 ` Matthew Thode
@ 2014-01-29 21:36 ` Stephen Smalley
2014-01-29 22:35 ` Brian Behlendorf
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-29 21:36 UTC (permalink / raw)
To: mthode, Paul Moore, selinux, Richard Yao, behlendorf
On 01/29/2014 11:58 AM, Matthew Thode wrote:
> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>
>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>> [ 474.027196] Modules linked in:
>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>> 3.13.0-grsec #1
>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>> 07/29/10
>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>> ffff8805f50cd488
>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>> context_struct_compute_av+0xce/0x308
>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>> 0000000000000100
>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>> ffff8805e8aaa000
>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>> 0000000000000006
>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>> 0000000000000006
>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>> 0000000000000000
>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>> knlGS:0000000000000000
>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>> 00000000000207f0
>>>>>> [ 474.556058] Stack:
>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>> ffff8805f1190a40
>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>> ffff8805e8aac860
>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>> ffff8805c0ac3d94
>>>>>> [ 474.690461] Call Trace:
>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>> context_struct_compute_av+0xce/0x308
>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>
>>>>>
>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>
>>>>> ls ./.config/ipython/profile_default/
>>>>> Segmentation fault
>>>>
>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>> etc.
>>>>
>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>> expect we would be flooded with angry users right now ...
>>>
>>> Does it happen on any filesystem other than ZFS?
>>>
>>> Do you have any prior SELinux output leading up to this bug?
>>
>> Also, what policy are you using and what is the security context on that
>> file?
>>
> Ok, one at a time :D
>
> I'm on gentoo using the strict policy (in permissive for now...)
>
> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
> patches went in :D))
>
> using basepol 2.20130424
>
> No unusual config that I can think of. I've found multiple files that
> this happens with).
>
> Only on zfs that I can see
>
> Dunno what you mean by prior selinux output, just some random selinux
> denials because restorecon -RF fails because of this.
>
> I can't see either the file name or the context of that file. As soon
> as anything tries to access anything about the file I get that backtrace.
Looking at the code in question, I don't see any way to reach that BUG
without memory corruption in the kernel. Which could just as easily be
in ZFS as anything else...
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 21:36 ` Stephen Smalley
@ 2014-01-29 22:35 ` Brian Behlendorf
2014-01-29 22:39 ` Richard Yao
0 siblings, 1 reply; 24+ messages in thread
From: Brian Behlendorf @ 2014-01-29 22:35 UTC (permalink / raw)
To: Stephen Smalley, mthode, Paul Moore, selinux, Richard Yao, behlendorf
On 01/29/14 13:36, Stephen Smalley wrote:
> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>
>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>> [ 474.027196] Modules linked in:
>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>> 3.13.0-grsec #1
>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>> 07/29/10
>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>> ffff8805f50cd488
>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>> 0000000000000100
>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>> ffff8805e8aaa000
>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>> 0000000000000006
>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>> 0000000000000006
>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>> 0000000000000000
>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>> knlGS:0000000000000000
>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>> 00000000000207f0
>>>>>>> [ 474.556058] Stack:
>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>> ffff8805f1190a40
>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>> ffff8805e8aac860
>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>> ffff8805c0ac3d94
>>>>>>> [ 474.690461] Call Trace:
>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>
>>>>>>
>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>
>>>>>> ls ./.config/ipython/profile_default/
>>>>>> Segmentation fault
>>>>>
>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>> etc.
>>>>>
>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>> expect we would be flooded with angry users right now ...
>>>>
>>>> Does it happen on any filesystem other than ZFS?
>>>>
>>>> Do you have any prior SELinux output leading up to this bug?
>>>
>>> Also, what policy are you using and what is the security context on that
>>> file?
>>>
>> Ok, one at a time :D
>>
>> I'm on gentoo using the strict policy (in permissive for now...)
>>
>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>> patches went in :D))
>>
>> using basepol 2.20130424
>>
>> No unusual config that I can think of. I've found multiple files that
>> this happens with).
>>
>> Only on zfs that I can see
>>
>> Dunno what you mean by prior selinux output, just some random selinux
>> denials because restorecon -RF fails because of this.
>>
>> I can't see either the file name or the context of that file. As soon
>> as anything tries to access anything about the file I get that backtrace.
>
> Looking at the code in question, I don't see any way to reach that BUG
> without memory corruption in the kernel. Which could just as easily be
> in ZFS as anything else...
Memory corruption is possible but we haven't seen any other evidence of
that in ZFS. If Gentoo has a kernel-debug package similar to
Fedora/RHELs that may be worth a try. The additional debugging may
catch something non-obvious.
Thanks,
Brian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 22:35 ` Brian Behlendorf
@ 2014-01-29 22:39 ` Richard Yao
2014-01-30 8:20 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Richard Yao @ 2014-01-29 22:39 UTC (permalink / raw)
To: Brian Behlendorf; +Cc: behlendorf, Stephen Smalley, selinux
Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
> On 01/29/14 13:36, Stephen Smalley wrote:
>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>
>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>> 3.13.0-grsec #1
>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>> 07/29/10
>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>> ffff8805f50cd488
>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>> 0000000000000100
>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>> ffff8805e8aaa000
>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>> 0000000000000006
>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>> 0000000000000006
>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>> 0000000000000000
>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>> knlGS:0000000000000000
>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>> 00000000000207f0
>>>>>>>> [ 474.556058] Stack:
>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>> ffff8805f1190a40
>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>> ffff8805e8aac860
>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>> ffff8805c0ac3d94
>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>
>>>>>>>
>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>
>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>> Segmentation fault
>>>>>>
>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>> etc.
>>>>>>
>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>> expect we would be flooded with angry users right now ...
>>>>>
>>>>> Does it happen on any filesystem other than ZFS?
>>>>>
>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>
>>>> Also, what policy are you using and what is the security context on that
>>>> file?
>>>>
>>> Ok, one at a time :D
>>>
>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>
>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>> patches went in :D))
>>>
>>> using basepol 2.20130424
>>>
>>> No unusual config that I can think of. I've found multiple files that
>>> this happens with).
>>>
>>> Only on zfs that I can see
>>>
>>> Dunno what you mean by prior selinux output, just some random selinux
>>> denials because restorecon -RF fails because of this.
>>>
>>> I can't see either the file name or the context of that file. As soon
>>> as anything tries to access anything about the file I get that backtrace.
>>
>> Looking at the code in question, I don't see any way to reach that BUG
>> without memory corruption in the kernel. Which could just as easily be
>> in ZFS as anything else...
>
> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>
> Thanks,
> Brian
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-29 22:39 ` Richard Yao
@ 2014-01-30 8:20 ` Matthew Thode
2014-01-30 13:43 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-30 8:20 UTC (permalink / raw)
To: Richard Yao, Brian Behlendorf; +Cc: behlendorf, Stephen Smalley, selinux
[-- Attachment #1: Type: text/plain, Size: 7324 bytes --]
On 01/29/2014 04:39 PM, Richard Yao wrote:
> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>
> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>
>> On 01/29/14 13:36, Stephen Smalley wrote:
>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>
>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>> 07/29/10
>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>> ffff8805f50cd488
>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>> 0000000000000100
>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>> ffff8805e8aaa000
>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>> 0000000000000006
>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>> 0000000000000006
>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>> 0000000000000000
>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>> knlGS:0000000000000000
>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>> 00000000000207f0
>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>> ffff8805f1190a40
>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>> ffff8805e8aac860
>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>
>>>>>>>>
>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>
>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>> Segmentation fault
>>>>>>>
>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>> etc.
>>>>>>>
>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>
>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>
>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>
>>>>> Also, what policy are you using and what is the security context on that
>>>>> file?
>>>>>
>>>> Ok, one at a time :D
>>>>
>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>
>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>> patches went in :D))
>>>>
>>>> using basepol 2.20130424
>>>>
>>>> No unusual config that I can think of. I've found multiple files that
>>>> this happens with).
>>>>
>>>> Only on zfs that I can see
>>>>
>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>> denials because restorecon -RF fails because of this.
>>>>
>>>> I can't see either the file name or the context of that file. As soon
>>>> as anything tries to access anything about the file I get that backtrace.
>>>
>>> Looking at the code in question, I don't see any way to reach that BUG
>>> without memory corruption in the kernel. Which could just as easily be
>>> in ZFS as anything else...
>>
>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>
>> Thanks,
>> Brian
>
Ok, booted up without selinux, does this seem right to you (note the
empty security.selinux field for
'.config/ipython/profile_default/history.sqlite-journal').
# getfattr -n security.selinux .config/ipython/profile_default/*
# file: .config/ipython/profile_default/db
security.selinux="root:object_r:xdg_config_home_t"
# file: .config/ipython/profile_default/history.sqlite
security.selinux="root:object_r:xdg_config_home_t"
# file: .config/ipython/profile_default/history.sqlite-journal
security.selinux
# file: .config/ipython/profile_default/log
security.selinux="root:object_r:xdg_config_home_t"
# file: .config/ipython/profile_default/pid
security.selinux="root:object_r:xdg_config_home_t"
# file: .config/ipython/profile_default/security
security.selinux="root:object_r:xdg_config_home_t"
# file: .config/ipython/profile_default/startup
security.selinux="root:object_r:xdg_config_home_t"
storage ~ # touch asdasdasdadasdasd
storage ~ # getfattr -n security.selinux asdasdasdadasdasd
asdasdasdadasdasd: security.selinux: No such attribute
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 8:20 ` Matthew Thode
@ 2014-01-30 13:43 ` Stephen Smalley
2014-01-30 15:38 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-30 13:43 UTC (permalink / raw)
To: mthode, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
On 01/30/2014 03:20 AM, Matthew Thode wrote:
> On 01/29/2014 04:39 PM, Richard Yao wrote:
>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>
>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>
>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>
>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>> 07/29/10
>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>> 0000000000000100
>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>> 0000000000000006
>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>> 0000000000000006
>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>> 0000000000000000
>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>> 00000000000207f0
>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>
>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>> Segmentation fault
>>>>>>>>
>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>
>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>
>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>
>>>>>> Also, what policy are you using and what is the security context on that
>>>>>> file?
>>>>>>
>>>>> Ok, one at a time :D
>>>>>
>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>
>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>> patches went in :D))
>>>>>
>>>>> using basepol 2.20130424
>>>>>
>>>>> No unusual config that I can think of. I've found multiple files that
>>>>> this happens with).
>>>>>
>>>>> Only on zfs that I can see
>>>>>
>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>> denials because restorecon -RF fails because of this.
>>>>>
>>>>> I can't see either the file name or the context of that file. As soon
>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>
>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>> without memory corruption in the kernel. Which could just as easily be
>>>> in ZFS as anything else...
>>>
>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>
>>> Thanks,
>>> Brian
>>
> Ok, booted up without selinux, does this seem right to you (note the
> empty security.selinux field for
> '.config/ipython/profile_default/history.sqlite-journal').
>
> # getfattr -n security.selinux .config/ipython/profile_default/*
>
> # file: .config/ipython/profile_default/db
> security.selinux="root:object_r:xdg_config_home_t"
>
> # file: .config/ipython/profile_default/history.sqlite
> security.selinux="root:object_r:xdg_config_home_t"
>
> # file: .config/ipython/profile_default/history.sqlite-journal
> security.selinux
>
> # file: .config/ipython/profile_default/log
> security.selinux="root:object_r:xdg_config_home_t"
>
> # file: .config/ipython/profile_default/pid
> security.selinux="root:object_r:xdg_config_home_t"
>
> # file: .config/ipython/profile_default/security
> security.selinux="root:object_r:xdg_config_home_t"
>
> # file: .config/ipython/profile_default/startup
> security.selinux="root:object_r:xdg_config_home_t"
>
> storage ~ # touch asdasdasdadasdasd
> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
> asdasdasdadasdasd: security.selinux: No such attribute
No, should never be empty, although that shouldn't lead to this BUG
either, just a warning that the inode was found to have an invalid
context in your dmesg and remapping it to the unlabeled context. Full
dmesg or /var/log/messages output (or at least all lines with SELinux,
audit, or avc in them) when running the SE-enabled kernel would be of
interest.
Files created while running a non-SE kernel will normally not have any
security.selinux attribute, so that isn't surprising. You have to
relabel when switching back and forth between non-SE and SE. But again,
that shouldn't produce this BUG, just an unlabeled file that could yield
some avc denials until it is relabeled.
The BUG in question has to do with a flex_array_get() call returning
NULL on an array that was preallocated via flex_array_prealloc(). So
the only way for it to occur is if the provided index (tcontext->type -
1) is out of range, yet those values are validated via
policydb_context_isvalid() before they are ever added to the sidtab. So
you are looking at memory corruption of either the flex array or the
context structure. And as we have never seen this BUG in a mainline
kernel with ext[432] or any other mainline filesystem, I have to think
that it has something to do with your specific kernel, either in ZFS or
in some other change in your specific kernel.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 13:43 ` Stephen Smalley
@ 2014-01-30 15:38 ` Matthew Thode
2014-01-30 15:45 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-30 15:38 UTC (permalink / raw)
To: Stephen Smalley, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 9671 bytes --]
On 01/30/2014 07:43 AM, Stephen Smalley wrote:
> On 01/30/2014 03:20 AM, Matthew Thode wrote:
>> On 01/29/2014 04:39 PM, Richard Yao wrote:
>>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>>
>>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>>
>>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>>
>>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>>> 07/29/10
>>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>>> 0000000000000100
>>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>>> 0000000000000006
>>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>>> 0000000000000006
>>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>>> 0000000000000000
>>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>>> 00000000000207f0
>>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>>
>>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>>> Segmentation fault
>>>>>>>>>
>>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>>
>>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>>
>>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>>
>>>>>>> Also, what policy are you using and what is the security context on that
>>>>>>> file?
>>>>>>>
>>>>>> Ok, one at a time :D
>>>>>>
>>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>>
>>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>>> patches went in :D))
>>>>>>
>>>>>> using basepol 2.20130424
>>>>>>
>>>>>> No unusual config that I can think of. I've found multiple files that
>>>>>> this happens with).
>>>>>>
>>>>>> Only on zfs that I can see
>>>>>>
>>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>>> denials because restorecon -RF fails because of this.
>>>>>>
>>>>>> I can't see either the file name or the context of that file. As soon
>>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>>
>>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>>> without memory corruption in the kernel. Which could just as easily be
>>>>> in ZFS as anything else...
>>>>
>>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>>
>>>> Thanks,
>>>> Brian
>>>
>> Ok, booted up without selinux, does this seem right to you (note the
>> empty security.selinux field for
>> '.config/ipython/profile_default/history.sqlite-journal').
>>
>> # getfattr -n security.selinux .config/ipython/profile_default/*
>>
>> # file: .config/ipython/profile_default/db
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> # file: .config/ipython/profile_default/history.sqlite
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> # file: .config/ipython/profile_default/history.sqlite-journal
>> security.selinux
>>
>> # file: .config/ipython/profile_default/log
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> # file: .config/ipython/profile_default/pid
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> # file: .config/ipython/profile_default/security
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> # file: .config/ipython/profile_default/startup
>> security.selinux="root:object_r:xdg_config_home_t"
>>
>> storage ~ # touch asdasdasdadasdasd
>> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
>> asdasdasdadasdasd: security.selinux: No such attribute
>
> No, should never be empty, although that shouldn't lead to this BUG
> either, just a warning that the inode was found to have an invalid
> context in your dmesg and remapping it to the unlabeled context. Full
> dmesg or /var/log/messages output (or at least all lines with SELinux,
> audit, or avc in them) when running the SE-enabled kernel would be of
> interest.
>
> Files created while running a non-SE kernel will normally not have any
> security.selinux attribute, so that isn't surprising. You have to
> relabel when switching back and forth between non-SE and SE. But again,
> that shouldn't produce this BUG, just an unlabeled file that could yield
> some avc denials until it is relabeled.
>
> The BUG in question has to do with a flex_array_get() call returning
> NULL on an array that was preallocated via flex_array_prealloc(). So
> the only way for it to occur is if the provided index (tcontext->type -
> 1) is out of range, yet those values are validated via
> policydb_context_isvalid() before they are ever added to the sidtab. So
> you are looking at memory corruption of either the flex array or the
> context structure. And as we have never seen this BUG in a mainline
> kernel with ext[432] or any other mainline filesystem, I have to think
> that it has something to do with your specific kernel, either in ZFS or
> in some other change in your specific kernel.
>
Well, it is empty :P as far as AVC denials go it was just for stuff
that wasn't relabled from the previous boot.
I can't relabel this file because accessing it (even a dir listing)
causes BUG!
I also tracked it down to the flex array get function, but that's the
limit of my C knowlege atm.
I feel like this is a bug in both mainline and zfs; Mainline because it
can't handle the context and zfs because it generated the context. I'm
also not convinced about the memory corruption though.
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 15:38 ` Matthew Thode
@ 2014-01-30 15:45 ` Stephen Smalley
2014-01-30 15:51 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-30 15:45 UTC (permalink / raw)
To: mthode, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
On 01/30/2014 10:38 AM, Matthew Thode wrote:
> On 01/30/2014 07:43 AM, Stephen Smalley wrote:
>> On 01/30/2014 03:20 AM, Matthew Thode wrote:
>>> On 01/29/2014 04:39 PM, Richard Yao wrote:
>>>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>>>
>>>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>>>
>>>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>>>
>>>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>>>> 07/29/10
>>>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>>>> 0000000000000100
>>>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>>>> 00000000000207f0
>>>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>>>
>>>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>>>> Segmentation fault
>>>>>>>>>>
>>>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>>>> etc.
>>>>>>>>>>
>>>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>>>
>>>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>>>
>>>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>>>
>>>>>>>> Also, what policy are you using and what is the security context on that
>>>>>>>> file?
>>>>>>>>
>>>>>>> Ok, one at a time :D
>>>>>>>
>>>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>>>
>>>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>>>> patches went in :D))
>>>>>>>
>>>>>>> using basepol 2.20130424
>>>>>>>
>>>>>>> No unusual config that I can think of. I've found multiple files that
>>>>>>> this happens with).
>>>>>>>
>>>>>>> Only on zfs that I can see
>>>>>>>
>>>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>>>> denials because restorecon -RF fails because of this.
>>>>>>>
>>>>>>> I can't see either the file name or the context of that file. As soon
>>>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>>>
>>>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>>>> without memory corruption in the kernel. Which could just as easily be
>>>>>> in ZFS as anything else...
>>>>>
>>>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>>>
>>>>> Thanks,
>>>>> Brian
>>>>
>>> Ok, booted up without selinux, does this seem right to you (note the
>>> empty security.selinux field for
>>> '.config/ipython/profile_default/history.sqlite-journal').
>>>
>>> # getfattr -n security.selinux .config/ipython/profile_default/*
>>>
>>> # file: .config/ipython/profile_default/db
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> # file: .config/ipython/profile_default/history.sqlite
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> # file: .config/ipython/profile_default/history.sqlite-journal
>>> security.selinux
>>>
>>> # file: .config/ipython/profile_default/log
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> # file: .config/ipython/profile_default/pid
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> # file: .config/ipython/profile_default/security
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> # file: .config/ipython/profile_default/startup
>>> security.selinux="root:object_r:xdg_config_home_t"
>>>
>>> storage ~ # touch asdasdasdadasdasd
>>> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
>>> asdasdasdadasdasd: security.selinux: No such attribute
>>
>> No, should never be empty, although that shouldn't lead to this BUG
>> either, just a warning that the inode was found to have an invalid
>> context in your dmesg and remapping it to the unlabeled context. Full
>> dmesg or /var/log/messages output (or at least all lines with SELinux,
>> audit, or avc in them) when running the SE-enabled kernel would be of
>> interest.
>>
>> Files created while running a non-SE kernel will normally not have any
>> security.selinux attribute, so that isn't surprising. You have to
>> relabel when switching back and forth between non-SE and SE. But again,
>> that shouldn't produce this BUG, just an unlabeled file that could yield
>> some avc denials until it is relabeled.
>>
>> The BUG in question has to do with a flex_array_get() call returning
>> NULL on an array that was preallocated via flex_array_prealloc(). So
>> the only way for it to occur is if the provided index (tcontext->type -
>> 1) is out of range, yet those values are validated via
>> policydb_context_isvalid() before they are ever added to the sidtab. So
>> you are looking at memory corruption of either the flex array or the
>> context structure. And as we have never seen this BUG in a mainline
>> kernel with ext[432] or any other mainline filesystem, I have to think
>> that it has something to do with your specific kernel, either in ZFS or
>> in some other change in your specific kernel.
>>
>
> Well, it is empty :P as far as AVC denials go it was just for stuff
> that wasn't relabled from the previous boot.
>
> I can't relabel this file because accessing it (even a dir listing)
> causes BUG!
>
> I also tracked it down to the flex array get function, but that's the
> limit of my C knowlege atm.
>
> I feel like this is a bug in both mainline and zfs; Mainline because it
> can't handle the context and zfs because it generated the context. I'm
> also not convinced about the memory corruption though.
I was able to reproduce it w/o ZFS, so ZFS is clear on the BUG part, but
unclear how you get an empty xattr value there.
su
setenforce 0
touch foo
setfattr -n security.selinux foo
triggers the BUG.
We'll have to investigate, as that obviously shouldn't be possible.
Wouldn't be allowed in enforcing mode or for any non-root process.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 15:45 ` Stephen Smalley
@ 2014-01-30 15:51 ` Matthew Thode
2014-01-30 16:41 ` Stephen Smalley
0 siblings, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-30 15:51 UTC (permalink / raw)
To: Stephen Smalley, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 10874 bytes --]
On 01/30/2014 09:45 AM, Stephen Smalley wrote:
> On 01/30/2014 10:38 AM, Matthew Thode wrote:
>> On 01/30/2014 07:43 AM, Stephen Smalley wrote:
>>> On 01/30/2014 03:20 AM, Matthew Thode wrote:
>>>> On 01/29/2014 04:39 PM, Richard Yao wrote:
>>>>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>>>>
>>>>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>>>>
>>>>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>>>>> 07/29/10
>>>>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>>>>> 0000000000000100
>>>>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>>>>> 00000000000207f0
>>>>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>>>>
>>>>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>>>>> Segmentation fault
>>>>>>>>>>>
>>>>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>>>>> etc.
>>>>>>>>>>>
>>>>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>>>>
>>>>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>>>>
>>>>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>>>>
>>>>>>>>> Also, what policy are you using and what is the security context on that
>>>>>>>>> file?
>>>>>>>>>
>>>>>>>> Ok, one at a time :D
>>>>>>>>
>>>>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>>>>
>>>>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>>>>> patches went in :D))
>>>>>>>>
>>>>>>>> using basepol 2.20130424
>>>>>>>>
>>>>>>>> No unusual config that I can think of. I've found multiple files that
>>>>>>>> this happens with).
>>>>>>>>
>>>>>>>> Only on zfs that I can see
>>>>>>>>
>>>>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>>>>> denials because restorecon -RF fails because of this.
>>>>>>>>
>>>>>>>> I can't see either the file name or the context of that file. As soon
>>>>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>>>>
>>>>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>>>>> without memory corruption in the kernel. Which could just as easily be
>>>>>>> in ZFS as anything else...
>>>>>>
>>>>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>>>>
>>>>>> Thanks,
>>>>>> Brian
>>>>>
>>>> Ok, booted up without selinux, does this seem right to you (note the
>>>> empty security.selinux field for
>>>> '.config/ipython/profile_default/history.sqlite-journal').
>>>>
>>>> # getfattr -n security.selinux .config/ipython/profile_default/*
>>>>
>>>> # file: .config/ipython/profile_default/db
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> # file: .config/ipython/profile_default/history.sqlite
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> # file: .config/ipython/profile_default/history.sqlite-journal
>>>> security.selinux
>>>>
>>>> # file: .config/ipython/profile_default/log
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> # file: .config/ipython/profile_default/pid
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> # file: .config/ipython/profile_default/security
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> # file: .config/ipython/profile_default/startup
>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>
>>>> storage ~ # touch asdasdasdadasdasd
>>>> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
>>>> asdasdasdadasdasd: security.selinux: No such attribute
>>>
>>> No, should never be empty, although that shouldn't lead to this BUG
>>> either, just a warning that the inode was found to have an invalid
>>> context in your dmesg and remapping it to the unlabeled context. Full
>>> dmesg or /var/log/messages output (or at least all lines with SELinux,
>>> audit, or avc in them) when running the SE-enabled kernel would be of
>>> interest.
>>>
>>> Files created while running a non-SE kernel will normally not have any
>>> security.selinux attribute, so that isn't surprising. You have to
>>> relabel when switching back and forth between non-SE and SE. But again,
>>> that shouldn't produce this BUG, just an unlabeled file that could yield
>>> some avc denials until it is relabeled.
>>>
>>> The BUG in question has to do with a flex_array_get() call returning
>>> NULL on an array that was preallocated via flex_array_prealloc(). So
>>> the only way for it to occur is if the provided index (tcontext->type -
>>> 1) is out of range, yet those values are validated via
>>> policydb_context_isvalid() before they are ever added to the sidtab. So
>>> you are looking at memory corruption of either the flex array or the
>>> context structure. And as we have never seen this BUG in a mainline
>>> kernel with ext[432] or any other mainline filesystem, I have to think
>>> that it has something to do with your specific kernel, either in ZFS or
>>> in some other change in your specific kernel.
>>>
>>
>> Well, it is empty :P as far as AVC denials go it was just for stuff
>> that wasn't relabled from the previous boot.
>>
>> I can't relabel this file because accessing it (even a dir listing)
>> causes BUG!
>>
>> I also tracked it down to the flex array get function, but that's the
>> limit of my C knowlege atm.
>>
>> I feel like this is a bug in both mainline and zfs; Mainline because it
>> can't handle the context and zfs because it generated the context. I'm
>> also not convinced about the memory corruption though.
>
> I was able to reproduce it w/o ZFS, so ZFS is clear on the BUG part, but
> unclear how you get an empty xattr value there.
>
> su
> setenforce 0
> touch foo
> setfattr -n security.selinux foo
>
> triggers the BUG.
>
> We'll have to investigate, as that obviously shouldn't be possible.
> Wouldn't be allowed in enforcing mode or for any non-root process.
>
>
You know that good feeling you get when someone else can reproduce a
bug? I have that now :D
Thanks. I'll likely keep on trying to fix though :D I'm not too sure
when that file was generated though. It was generated by a root process
both times (nfs and ipython run as root) and I was very likely to be in
permissive mode.
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 15:51 ` Matthew Thode
@ 2014-01-30 16:41 ` Stephen Smalley
2014-01-30 17:07 ` Matthew Thode
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Smalley @ 2014-01-30 16:41 UTC (permalink / raw)
To: mthode, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 10921 bytes --]
On 01/30/2014 10:51 AM, Matthew Thode wrote:
> On 01/30/2014 09:45 AM, Stephen Smalley wrote:
>> On 01/30/2014 10:38 AM, Matthew Thode wrote:
>>> On 01/30/2014 07:43 AM, Stephen Smalley wrote:
>>>> On 01/30/2014 03:20 AM, Matthew Thode wrote:
>>>>> On 01/29/2014 04:39 PM, Richard Yao wrote:
>>>>>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>>>>>
>>>>>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>>>>>
>>>>>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>>>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>>>>>> 07/29/10
>>>>>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>>>>>> 0000000000000100
>>>>>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>>>>>> 00000000000207f0
>>>>>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>>>>>> Segmentation fault
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>>>>>> etc.
>>>>>>>>>>>>
>>>>>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>>>>>
>>>>>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>>>>>
>>>>>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>>>>>
>>>>>>>>>> Also, what policy are you using and what is the security context on that
>>>>>>>>>> file?
>>>>>>>>>>
>>>>>>>>> Ok, one at a time :D
>>>>>>>>>
>>>>>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>>>>>
>>>>>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>>>>>> patches went in :D))
>>>>>>>>>
>>>>>>>>> using basepol 2.20130424
>>>>>>>>>
>>>>>>>>> No unusual config that I can think of. I've found multiple files that
>>>>>>>>> this happens with).
>>>>>>>>>
>>>>>>>>> Only on zfs that I can see
>>>>>>>>>
>>>>>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>>>>>> denials because restorecon -RF fails because of this.
>>>>>>>>>
>>>>>>>>> I can't see either the file name or the context of that file. As soon
>>>>>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>>>>>
>>>>>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>>>>>> without memory corruption in the kernel. Which could just as easily be
>>>>>>>> in ZFS as anything else...
>>>>>>>
>>>>>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brian
>>>>>>
>>>>> Ok, booted up without selinux, does this seem right to you (note the
>>>>> empty security.selinux field for
>>>>> '.config/ipython/profile_default/history.sqlite-journal').
>>>>>
>>>>> # getfattr -n security.selinux .config/ipython/profile_default/*
>>>>>
>>>>> # file: .config/ipython/profile_default/db
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> # file: .config/ipython/profile_default/history.sqlite
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> # file: .config/ipython/profile_default/history.sqlite-journal
>>>>> security.selinux
>>>>>
>>>>> # file: .config/ipython/profile_default/log
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> # file: .config/ipython/profile_default/pid
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> # file: .config/ipython/profile_default/security
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> # file: .config/ipython/profile_default/startup
>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>
>>>>> storage ~ # touch asdasdasdadasdasd
>>>>> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
>>>>> asdasdasdadasdasd: security.selinux: No such attribute
>>>>
>>>> No, should never be empty, although that shouldn't lead to this BUG
>>>> either, just a warning that the inode was found to have an invalid
>>>> context in your dmesg and remapping it to the unlabeled context. Full
>>>> dmesg or /var/log/messages output (or at least all lines with SELinux,
>>>> audit, or avc in them) when running the SE-enabled kernel would be of
>>>> interest.
>>>>
>>>> Files created while running a non-SE kernel will normally not have any
>>>> security.selinux attribute, so that isn't surprising. You have to
>>>> relabel when switching back and forth between non-SE and SE. But again,
>>>> that shouldn't produce this BUG, just an unlabeled file that could yield
>>>> some avc denials until it is relabeled.
>>>>
>>>> The BUG in question has to do with a flex_array_get() call returning
>>>> NULL on an array that was preallocated via flex_array_prealloc(). So
>>>> the only way for it to occur is if the provided index (tcontext->type -
>>>> 1) is out of range, yet those values are validated via
>>>> policydb_context_isvalid() before they are ever added to the sidtab. So
>>>> you are looking at memory corruption of either the flex array or the
>>>> context structure. And as we have never seen this BUG in a mainline
>>>> kernel with ext[432] or any other mainline filesystem, I have to think
>>>> that it has something to do with your specific kernel, either in ZFS or
>>>> in some other change in your specific kernel.
>>>>
>>>
>>> Well, it is empty :P as far as AVC denials go it was just for stuff
>>> that wasn't relabled from the previous boot.
>>>
>>> I can't relabel this file because accessing it (even a dir listing)
>>> causes BUG!
>>>
>>> I also tracked it down to the flex array get function, but that's the
>>> limit of my C knowlege atm.
>>>
>>> I feel like this is a bug in both mainline and zfs; Mainline because it
>>> can't handle the context and zfs because it generated the context. I'm
>>> also not convinced about the memory corruption though.
>>
>> I was able to reproduce it w/o ZFS, so ZFS is clear on the BUG part, but
>> unclear how you get an empty xattr value there.
>>
>> su
>> setenforce 0
>> touch foo
>> setfattr -n security.selinux foo
>>
>> triggers the BUG.
>>
>> We'll have to investigate, as that obviously shouldn't be possible.
>> Wouldn't be allowed in enforcing mode or for any non-root process.
>>
>>
> You know that good feeling you get when someone else can reproduce a
> bug? I have that now :D
>
> Thanks. I'll likely keep on trying to fix though :D I'm not too sure
> when that file was generated though. It was generated by a root process
> both times (nfs and ipython run as root) and I was very likely to be in
> permissive mode.
Try the attached patch.
[-- Attachment #2: 0001-SELinux-Fix-kernel-BUG-on-empty-security-contexts.patch --]
[-- Type: text/x-patch, Size: 4745 bytes --]
>From d3527011420271d29c8710882cc2a88b925a21ff Mon Sep 17 00:00:00 2001
From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Thu, 30 Jan 2014 11:26:59 -0500
Subject: [PATCH] SELinux: Fix kernel BUG on empty security contexts.
Setting an empty security context (length=0) on a file will
lead to incorrectly dereferencing the type and other fields
of the security context structure, yielding a kernel BUG.
As a zero-length security context is never valid, just reject
all such security contexts whether coming from userspace
via setxattr or coming from the filesystem upon a getxattr
request by SELinux.
Setting a security context value (empty or otherwise) unknown to
SELinux in the first place is only possible for a root process
(CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
if the corresponding SELinux mac_admin permission is also granted
to the domain by policy. In Fedora policies, this is only allowed for
specific domains such as livecd for setting down security contexts
that are not defined in the build host policy.
Reproducer:
su
setenforce 0
touch foo
setfattr -n security.selinux foo
Caveat:
Relabeling or removing foo after doing the above may not be possible
without booting with SELinux disabled. Any subsequent access to foo
after doing the above will also trigger the BUG.
BUG output from Matthew Thode:
[ 473.893141] ------------[ cut here ]------------
[ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
[ 473.995314] invalid opcode: 0000 [#6] SMP
[ 474.027196] Modules linked in:
[ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
3.13.0-grsec #1
[ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
[ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[ 474.556058] Stack:
[ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[ 474.690461] Call Trace:
[ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
[ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
[ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
[ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
[ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
[ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
[ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
[ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
[ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
[ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
[ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
[ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
[ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
[ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[ 475.255884] RIP [<ffffffff814681c7>]
context_struct_compute_av+0xce/0x308
[ 475.296120] RSP <ffff8805c0ac3c38>
[ 475.328734] ---[ end trace f076482e9d754adc ]---
Reported-by: Matthew Thode <mthode@mthode.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
---
security/selinux/ss/services.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index d106733..539aadd 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1232,6 +1232,10 @@ static int security_context_to_sid_core(const char *scontext, u32 scontext_len,
struct context context;
int rc = 0;
+ /* An empty security context is never valid. */
+ if (!scontext_len)
+ return -EINVAL;
+
if (!ss_initialized) {
int i;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 16:41 ` Stephen Smalley
@ 2014-01-30 17:07 ` Matthew Thode
2014-01-30 17:19 ` Paul Moore
2014-01-30 17:27 ` Richard Yao
0 siblings, 2 replies; 24+ messages in thread
From: Matthew Thode @ 2014-01-30 17:07 UTC (permalink / raw)
To: Stephen Smalley, Richard Yao, Brian Behlendorf; +Cc: behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 12232 bytes --]
On 01/30/2014 10:41 AM, Stephen Smalley wrote:
> On 01/30/2014 10:51 AM, Matthew Thode wrote:
>> On 01/30/2014 09:45 AM, Stephen Smalley wrote:
>>> On 01/30/2014 10:38 AM, Matthew Thode wrote:
>>>> On 01/30/2014 07:43 AM, Stephen Smalley wrote:
>>>>> On 01/30/2014 03:20 AM, Matthew Thode wrote:
>>>>>> On 01/29/2014 04:39 PM, Richard Yao wrote:
>>>>>>> Gentoo systems have custom kernels made by their users. I can run through Matthew’s kernel config with him to make sure that all of the right options are checked this evening. If any changes are necessary, he can recompile.
>>>>>>>
>>>>>>> On Jan 29, 2014, at 5:35 PM, Brian Behlendorf <behlendorf1@llnl.gov> wrote:
>>>>>>>
>>>>>>>> On 01/29/14 13:36, Stephen Smalley wrote:
>>>>>>>>> On 01/29/2014 11:58 AM, Matthew Thode wrote:
>>>>>>>>>> On 01/29/2014 08:17 AM, Stephen Smalley wrote:
>>>>>>>>>>> On 01/29/2014 09:07 AM, Stephen Smalley wrote:
>>>>>>>>>>>> On 01/29/2014 08:55 AM, Paul Moore wrote:
>>>>>>>>>>>>> On Wednesday, January 29, 2014 02:11:45 AM Matthew Thode wrote:
>>>>>>>>>>>>>> On 01/29/2014 02:04 AM, Matthew Thode wrote:
>>>>>>>>>>>>>>> This happens consistantly, just ls a particular dir and wheeeeee.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ 473.893141] ------------[ cut here ]------------
>>>>>>>>>>>>>>> [ 473.962110] kernel BUG at security/selinux/ss/services.c:654!
>>>>>>>>>>>>>>> [ 473.995314] invalid opcode: 0000 [#6] SMP
>>>>>>>>>>>>>>> [ 474.027196] Modules linked in:
>>>>>>>>>>>>>>> [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I
>>>>>>>>>>>>>>> 3.13.0-grsec #1
>>>>>>>>>>>>>>> [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
>>>>>>>>>>>>>>> 07/29/10
>>>>>>>>>>>>>>> [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
>>>>>>>>>>>>>>> ffff8805f50cd488
>>>>>>>>>>>>>>> [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>]
>>>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>>>> [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246
>>>>>>>>>>>>>>> [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
>>>>>>>>>>>>>>> 0000000000000100
>>>>>>>>>>>>>>> [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
>>>>>>>>>>>>>>> ffff8805e8aaa000
>>>>>>>>>>>>>>> [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
>>>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>>>> [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
>>>>>>>>>>>>>>> 0000000000000006
>>>>>>>>>>>>>>> [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
>>>>>>>>>>>>>>> 0000000000000000
>>>>>>>>>>>>>>> [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000)
>>>>>>>>>>>>>>> knlGS:0000000000000000
>>>>>>>>>>>>>>> [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>>>>>>>>>> [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
>>>>>>>>>>>>>>> 00000000000207f0
>>>>>>>>>>>>>>> [ 474.556058] Stack:
>>>>>>>>>>>>>>> [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
>>>>>>>>>>>>>>> ffff8805f1190a40
>>>>>>>>>>>>>>> [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
>>>>>>>>>>>>>>> ffff8805e8aac860
>>>>>>>>>>>>>>> [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060
>>>>>>>>>>>>>>> ffff8805c0ac3d94
>>>>>>>>>>>>>>> [ 474.690461] Call Trace:
>>>>>>>>>>>>>>> [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
>>>>>>>>>>>>>>> [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b
>>>>>>>>>>>>>>> [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
>>>>>>>>>>>>>>> [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
>>>>>>>>>>>>>>> [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
>>>>>>>>>>>>>>> [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
>>>>>>>>>>>>>>> [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
>>>>>>>>>>>>>>> [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
>>>>>>>>>>>>>>> [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
>>>>>>>>>>>>>>> [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
>>>>>>>>>>>>>>> [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
>>>>>>>>>>>>>>> [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
>>>>>>>>>>>>>>> [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
>>>>>>>>>>>>>>> [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
>>>>>>>>>>>>>>> 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
>>>>>>>>>>>>>>> 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
>>>>>>>>>>>>>>> [ 475.255884] RIP [<ffffffff814681c7>]
>>>>>>>>>>>>>>> context_struct_compute_av+0xce/0x308
>>>>>>>>>>>>>>> [ 475.296120] RSP <ffff8805c0ac3c38>
>>>>>>>>>>>>>>> [ 475.328734] ---[ end trace f076482e9d754adc ]---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> sorry, forgot to add, this is for 3.13.0 as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ls ./.config/ipython/profile_default/
>>>>>>>>>>>>>> Segmentation fault
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for passing this along, but can you elaborate a bit more on this?
>>>>>>>>>>>>> Distribution? Kernel package? SELinux policy? Any unusual configuration?
>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I ask because I'm not seeing this problem on my system and it seems like a
>>>>>>>>>>>>> fairly basic thing to be broken; if there was an issue with 'ls' on 3.13 I
>>>>>>>>>>>>> expect we would be flooded with angry users right now ...
>>>>>>>>>>>>
>>>>>>>>>>>> Does it happen on any filesystem other than ZFS?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have any prior SELinux output leading up to this bug?
>>>>>>>>>>>
>>>>>>>>>>> Also, what policy are you using and what is the security context on that
>>>>>>>>>>> file?
>>>>>>>>>>>
>>>>>>>>>> Ok, one at a time :D
>>>>>>>>>>
>>>>>>>>>> I'm on gentoo using the strict policy (in permissive for now...)
>>>>>>>>>>
>>>>>>>>>> Kernel is 3.13 (zfs is built from git head as of 2014-01-26 (selinux
>>>>>>>>>> patches went in :D))
>>>>>>>>>>
>>>>>>>>>> using basepol 2.20130424
>>>>>>>>>>
>>>>>>>>>> No unusual config that I can think of. I've found multiple files that
>>>>>>>>>> this happens with).
>>>>>>>>>>
>>>>>>>>>> Only on zfs that I can see
>>>>>>>>>>
>>>>>>>>>> Dunno what you mean by prior selinux output, just some random selinux
>>>>>>>>>> denials because restorecon -RF fails because of this.
>>>>>>>>>>
>>>>>>>>>> I can't see either the file name or the context of that file. As soon
>>>>>>>>>> as anything tries to access anything about the file I get that backtrace.
>>>>>>>>>
>>>>>>>>> Looking at the code in question, I don't see any way to reach that BUG
>>>>>>>>> without memory corruption in the kernel. Which could just as easily be
>>>>>>>>> in ZFS as anything else...
>>>>>>>>
>>>>>>>> Memory corruption is possible but we haven't seen any other evidence of that in ZFS. If Gentoo has a kernel-debug package similar to Fedora/RHELs that may be worth a try. The additional debugging may catch something non-obvious.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Brian
>>>>>>>
>>>>>> Ok, booted up without selinux, does this seem right to you (note the
>>>>>> empty security.selinux field for
>>>>>> '.config/ipython/profile_default/history.sqlite-journal').
>>>>>>
>>>>>> # getfattr -n security.selinux .config/ipython/profile_default/*
>>>>>>
>>>>>> # file: .config/ipython/profile_default/db
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> # file: .config/ipython/profile_default/history.sqlite
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> # file: .config/ipython/profile_default/history.sqlite-journal
>>>>>> security.selinux
>>>>>>
>>>>>> # file: .config/ipython/profile_default/log
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> # file: .config/ipython/profile_default/pid
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> # file: .config/ipython/profile_default/security
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> # file: .config/ipython/profile_default/startup
>>>>>> security.selinux="root:object_r:xdg_config_home_t"
>>>>>>
>>>>>> storage ~ # touch asdasdasdadasdasd
>>>>>> storage ~ # getfattr -n security.selinux asdasdasdadasdasd
>>>>>> asdasdasdadasdasd: security.selinux: No such attribute
>>>>>
>>>>> No, should never be empty, although that shouldn't lead to this BUG
>>>>> either, just a warning that the inode was found to have an invalid
>>>>> context in your dmesg and remapping it to the unlabeled context. Full
>>>>> dmesg or /var/log/messages output (or at least all lines with SELinux,
>>>>> audit, or avc in them) when running the SE-enabled kernel would be of
>>>>> interest.
>>>>>
>>>>> Files created while running a non-SE kernel will normally not have any
>>>>> security.selinux attribute, so that isn't surprising. You have to
>>>>> relabel when switching back and forth between non-SE and SE. But again,
>>>>> that shouldn't produce this BUG, just an unlabeled file that could yield
>>>>> some avc denials until it is relabeled.
>>>>>
>>>>> The BUG in question has to do with a flex_array_get() call returning
>>>>> NULL on an array that was preallocated via flex_array_prealloc(). So
>>>>> the only way for it to occur is if the provided index (tcontext->type -
>>>>> 1) is out of range, yet those values are validated via
>>>>> policydb_context_isvalid() before they are ever added to the sidtab. So
>>>>> you are looking at memory corruption of either the flex array or the
>>>>> context structure. And as we have never seen this BUG in a mainline
>>>>> kernel with ext[432] or any other mainline filesystem, I have to think
>>>>> that it has something to do with your specific kernel, either in ZFS or
>>>>> in some other change in your specific kernel.
>>>>>
>>>>
>>>> Well, it is empty :P as far as AVC denials go it was just for stuff
>>>> that wasn't relabled from the previous boot.
>>>>
>>>> I can't relabel this file because accessing it (even a dir listing)
>>>> causes BUG!
>>>>
>>>> I also tracked it down to the flex array get function, but that's the
>>>> limit of my C knowlege atm.
>>>>
>>>> I feel like this is a bug in both mainline and zfs; Mainline because it
>>>> can't handle the context and zfs because it generated the context. I'm
>>>> also not convinced about the memory corruption though.
>>>
>>> I was able to reproduce it w/o ZFS, so ZFS is clear on the BUG part, but
>>> unclear how you get an empty xattr value there.
>>>
>>> su
>>> setenforce 0
>>> touch foo
>>> setfattr -n security.selinux foo
>>>
>>> triggers the BUG.
>>>
>>> We'll have to investigate, as that obviously shouldn't be possible.
>>> Wouldn't be allowed in enforcing mode or for any non-root process.
>>>
>>>
>> You know that good feeling you get when someone else can reproduce a
>> bug? I have that now :D
>>
>> Thanks. I'll likely keep on trying to fix though :D I'm not too sure
>> when that file was generated though. It was generated by a root process
>> both times (nfs and ipython run as root) and I was very likely to be in
>> permissive mode.
>
> Try the attached patch.
>
>
Confirmed that this fixes it :D thanks a ton for this.
Here's some dmesg if you are curious (a bit much for email, so link)
http://bpaste.net/show/YcRsO0IhO8XvMVtKjMlv/
but here's the important bits.
ls .config/ipython/profile_default/
[ 324.461669] SELinux: inode=4148 on dev=zfs was found to have an
invalid context=root:object_r:xdg_config_home_t. This indicates you may
need to relabel the inode or the filesystem in question.
storage ~ # restorecon -RF ./.config/ipython/profile_default/ -vvvv
restorecon reset
/root/.config/ipython/profile_default/history.sqlite-journal context
system_u:object_r:unlabeled_t->root:object_r:xdg_config_home_t
#no more dmesg after restorecon, so confirmed that worked as well
storage ~ # ls .config/ipython/profile_default/
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:07 ` Matthew Thode
@ 2014-01-30 17:19 ` Paul Moore
2014-01-30 17:35 ` Matthew Thode
2014-02-05 17:15 ` Matthew Thode
2014-01-30 17:27 ` Richard Yao
1 sibling, 2 replies; 24+ messages in thread
From: Paul Moore @ 2014-01-30 17:19 UTC (permalink / raw)
To: mthode, Stephen Smalley
Cc: behlendorf, Richard Yao, Brian Behlendorf, selinux
On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
> > Try the attached patch.
>
> Confirmed that this fixes it :D thanks a ton for this.
Queued up in my stable branch, I'll send a pull request to James once -rc1 is
released.
Thanks guys.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:07 ` Matthew Thode
2014-01-30 17:19 ` Paul Moore
@ 2014-01-30 17:27 ` Richard Yao
2014-01-30 18:10 ` Stephen Smalley
1 sibling, 1 reply; 24+ messages in thread
From: Richard Yao @ 2014-01-30 17:27 UTC (permalink / raw)
To: mthode, Stephen Smalley, Brian Behlendorf; +Cc: behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On 01/30/2014 12:07 PM, Matthew Thode wrote:
> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
>> On 01/30/2014 10:51 AM, Matthew Thode wrote:
>>> On 01/30/2014 09:45 AM, Stephen Smalley wrote:
>>>> We'll have to investigate, as that obviously shouldn't be possible.
>>>> Wouldn't be allowed in enforcing mode or for any non-root process.
This is an untested conjecture, but I believe that a FUSE filesystem
could be used to trigger this in enforcing mode. If I am right, a custom
FUSE filesystem could trigger it with ease. However, I do not see what
that would accomplish beyond triggering the BUG_ON.
>> Try the attached patch.
>>
>>
> Confirmed that this fixes it :D thanks a ton for this.
This patch looks good to me. Feel free to append my Acked-by:
Acked-by: Richard Yao <ryao@gentoo.org>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:19 ` Paul Moore
@ 2014-01-30 17:35 ` Matthew Thode
2014-01-30 19:19 ` Paul Moore
2014-02-05 17:15 ` Matthew Thode
1 sibling, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-01-30 17:35 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley
Cc: behlendorf, Richard Yao, Brian Behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
On 01/30/2014 11:19 AM, Paul Moore wrote:
> On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
>> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
>>> Try the attached patch.
>>
>> Confirmed that this fixes it :D thanks a ton for this.
>
> Queued up in my stable branch, I'll send a pull request to James once -rc1 is
> released.
>
> Thanks guys.
>
Any chance for backport to 3.13?
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:27 ` Richard Yao
@ 2014-01-30 18:10 ` Stephen Smalley
0 siblings, 0 replies; 24+ messages in thread
From: Stephen Smalley @ 2014-01-30 18:10 UTC (permalink / raw)
To: Richard Yao, mthode, Brian Behlendorf; +Cc: behlendorf, selinux
On 01/30/2014 12:27 PM, Richard Yao wrote:
> On 01/30/2014 12:07 PM, Matthew Thode wrote:
>> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
>>> On 01/30/2014 10:51 AM, Matthew Thode wrote:
>>>> On 01/30/2014 09:45 AM, Stephen Smalley wrote:
>>>>> We'll have to investigate, as that obviously shouldn't be possible.
>>>>> Wouldn't be allowed in enforcing mode or for any non-root process.
>
> This is an untested conjecture, but I believe that a FUSE filesystem
> could be used to trigger this in enforcing mode. If I am right, a custom
> FUSE filesystem could trigger it with ease. However, I do not see what
> that would accomplish beyond triggering the BUG_ON.
SELinux does not presently request or use xattrs from FUSE filesystems,
so I don't believe this is presently an issue, but I understand.
>
>>> Try the attached patch.
>>>
>>>
>> Confirmed that this fixes it :D thanks a ton for this.
>
> This patch looks good to me. Feel free to append my Acked-by:
>
> Acked-by: Richard Yao <ryao@gentoo.org>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:35 ` Matthew Thode
@ 2014-01-30 19:19 ` Paul Moore
2014-02-04 3:41 ` Per Nystrom
0 siblings, 1 reply; 24+ messages in thread
From: Paul Moore @ 2014-01-30 19:19 UTC (permalink / raw)
To: mthode
Cc: Richard Yao, selinux, behlendorf, Brian Behlendorf, Stephen Smalley
On Thursday, January 30, 2014 11:35:09 AM Matthew Thode wrote:
> On 01/30/2014 11:19 AM, Paul Moore wrote:
> > On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
> >> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
> >>> Try the attached patch.
> >>
> >> Confirmed that this fixes it :D thanks a ton for this.
> >
> > Queued up in my stable branch, I'll send a pull request to James once -rc1
> > is released.
> >
> > Thanks guys.
>
> Any chance for backport to 3.13?
It will go off to the stable list and ultimately it will be up to the stable
kernel maintainers. However, considering the size and nature of the patch I
see no reason why it would not be applied to a 3.13.X release in the future.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 19:19 ` Paul Moore
@ 2014-02-04 3:41 ` Per Nystrom
0 siblings, 0 replies; 24+ messages in thread
From: Per Nystrom @ 2014-02-04 3:41 UTC (permalink / raw)
To: SELinux
Paul Moore <paul@...> writes:
>
> On Thursday, January 30, 2014 11:35:09 AM Matthew Thode wrote:
> > On 01/30/2014 11:19 AM, Paul Moore wrote:
> > > On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
> > >> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
> > >>> Try the attached patch.
> > >>
> > >> Confirmed that this fixes it :D thanks a ton for this.
> > >
> > > Queued up in my stable branch, I'll send a pull request to James once -rc1
> > > is released.
> > >
> > > Thanks guys.
> >
> > Any chance for backport to 3.13?
>
> It will go off to the stable list and ultimately it will be up to the stable
> kernel maintainers. However, considering the size and nature of the patch I
> see no reason why it would not be applied to a 3.13.X release in the future.
>
Confirming this patch works in kernel 3.12 on Fedora 20. And THANK YOU!
[root@localhost ~]# uname -a
Linux localhost.localdomain 3.12.8-300.local.fc20.x86_64 #1 SMP Sun Feb 2
09:39:43 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /etc/redhat-release
Fedora release 20 (Heisenbug)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-01-30 17:19 ` Paul Moore
2014-01-30 17:35 ` Matthew Thode
@ 2014-02-05 17:15 ` Matthew Thode
2014-02-05 17:18 ` Paul Moore
1 sibling, 1 reply; 24+ messages in thread
From: Matthew Thode @ 2014-02-05 17:15 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley
Cc: behlendorf, Richard Yao, Brian Behlendorf, selinux
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On 01/30/2014 11:19 AM, Paul Moore wrote:
> On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
>> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
>>> Try the attached patch.
>>
>> Confirmed that this fixes it :D thanks a ton for this.
>
> Queued up in my stable branch, I'll send a pull request to James once -rc1 is
> released.
>
> Thanks guys.
>
Mind letting me know when this has been upstreamed?
--
-- Matthew Thode
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: file access causes a kernel bug
2014-02-05 17:15 ` Matthew Thode
@ 2014-02-05 17:18 ` Paul Moore
0 siblings, 0 replies; 24+ messages in thread
From: Paul Moore @ 2014-02-05 17:18 UTC (permalink / raw)
To: mthode
Cc: Richard Yao, selinux, behlendorf, Brian Behlendorf, Stephen Smalley
On Wed, Feb 5, 2014 at 12:15 PM, Matthew Thode <mthode@mthode.org> wrote:
> On 01/30/2014 11:19 AM, Paul Moore wrote:
>> On Thursday, January 30, 2014 11:07:30 AM Matthew Thode wrote:
>>> On 01/30/2014 10:41 AM, Stephen Smalley wrote:
>>>> Try the attached patch.
>>>
>>> Confirmed that this fixes it :D thanks a ton for this.
>>
>> Queued up in my stable branch, I'll send a pull request to James once -rc1 is
>> released.
>>
>> Thanks guys.
>>
> Mind letting me know when this has been upstreamed?
I've been away for a bit and unable to push patches, but you should
see it this week.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-02-05 17:18 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-29 8:04 file access causes a kernel bug Matthew Thode
2014-01-29 8:11 ` Matthew Thode
2014-01-29 13:55 ` Paul Moore
2014-01-29 14:07 ` Stephen Smalley
2014-01-29 14:17 ` Stephen Smalley
2014-01-29 16:58 ` Matthew Thode
2014-01-29 21:36 ` Stephen Smalley
2014-01-29 22:35 ` Brian Behlendorf
2014-01-29 22:39 ` Richard Yao
2014-01-30 8:20 ` Matthew Thode
2014-01-30 13:43 ` Stephen Smalley
2014-01-30 15:38 ` Matthew Thode
2014-01-30 15:45 ` Stephen Smalley
2014-01-30 15:51 ` Matthew Thode
2014-01-30 16:41 ` Stephen Smalley
2014-01-30 17:07 ` Matthew Thode
2014-01-30 17:19 ` Paul Moore
2014-01-30 17:35 ` Matthew Thode
2014-01-30 19:19 ` Paul Moore
2014-02-04 3:41 ` Per Nystrom
2014-02-05 17:15 ` Matthew Thode
2014-02-05 17:18 ` Paul Moore
2014-01-30 17:27 ` Richard Yao
2014-01-30 18:10 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.