If Bin is using our N tree, then all the stuff for debugfs are exact matches:
/sys/kernel/debug/sync u:object_r:debugfs_graphics_sync:s0 /sys/kernel/debug/dri/0/i915_frequency_info u:object_r:debugfs_graphics:s0 /sys/kernel/debug/pstate_snb/setpoint u:object_r:debugfs_pstate:s0 Bin, can you confirm the state of your tree? You can run this command to find the entries: find . -name file_contexts | xargs grep 'kernel/debug' Thanks, Bill From: Nick Kralevich [mailto:[email protected]] Sent: Wednesday, October 12, 2016 11:42 AM To: Roberts, William C <[email protected]> Cc: Stephen Smalley <[email protected]>; [email protected]; Yang, Bin Y <[email protected]> Subject: Re: labelling /sys/kernel/debug aka debugfs Can you attach the file_contexts file you're using? Or at least all the entries starting with /sys? In the past, when I've seen this kind of slow restorecon on boot, it's been due to a regex which defeats the restorecon directory tree walking optimizations. -- Nick On Wed, Oct 12, 2016 at 6:42 AM, Roberts, William C <[email protected]<mailto:[email protected]>> wrote: > -----Original Message----- > From: Stephen Smalley [mailto:[email protected]<mailto:[email protected]>] > Sent: Wednesday, October 12, 2016 9:37 AM > To: Roberts, William C > <[email protected]<mailto:[email protected]>>; 'seandroid- > [email protected]<mailto:[email protected]>' > <[email protected]<mailto:[email protected]>> > Cc: Yang, Bin Y <[email protected]<mailto:[email protected]>> > Subject: Re: labelling /sys/kernel/debug aka debugfs > > On 10/12/2016 09:24 AM, Roberts, William C wrote: > > It’s been reported that labelling via restorecon_recursive > > /sys/kernel/debug is taking 0.25s on a device. I wanted to verify a > > thought: > > > > > > > > It looks like genfscon per file labeling is supported by selinux (like > > procfs), on linux master branch, I see: > > > > > > > > selinux_set_mnt_opts(): > > > > <snip> > > > > 815 if (!strcmp(sb->s_type->name, "debugfs") || > > > > 816 !strcmp(sb->s_type->name, "sysfs") || > > > > 817 !strcmp(sb->s_type->name, "pstore")) > > > > 818 sbsec->flags |= SE_SBGENFS; > > > > <snip> > > > > > > > > Would using genfscon statements and removing the restorecon_recursive > > be faster since it avoids the tree walk? Any caveats, issues one can think > > of? > > First, I'd be interested in understanding why that is taking so long, and > compare > with time on restorecon_recursive /sys (performed directly by init). > > The SE for Android todo list does suggest investigating this for replacing the > restorecon_recursive /sys, so it would make sense to investigate it for both. > It > does require that the device kernel include the necessary support. As noted in > https://android-review.googlesource.com/#/c/151776/, you are also limited in > that genfscon only supports pathname prefix matching, not regexes. I don't see any uses where the lack of regex support would be a problem. I'll see if Bin, the reporter, can collect more stats for us, Yang could you collect those? _______________________________________________ Seandroid-list mailing list [email protected]<mailto:[email protected]> To unsubscribe, send email to [email protected]<mailto:[email protected]>. To get help, send an email containing "help" to [email protected]<mailto:[email protected]>. -- Nick Kralevich | Android Security | [email protected]<mailto:[email protected]> | 650.214.4037
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
