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@xxxxxxxx> 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. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
