When invoking utilities like rmdir from the init scripts it would still be useful to specify in what domain you want them to be executed. Alternatively one can wrap all such calls in scripts that are labeled, though that seems a bit awkward?
/Johan From: Seandroid-list [mailto:[email protected]] On Behalf Of Roberts, William C Sent: den 3 juni 2015 00:35 To: Nick Kralevich Cc: [email protected] Subject: RE: killing init seclabel That would be pretty great if that went forward, and is definitely the ideal implementation. I’m just seeing people throwing these seclabel statements into their init.rc without understanding why. Considering what’s already being restorecon’d a simple restore on /sbin would be unnoticeable, and self-contained and would allow for the drop of seclabel, and once proper support came about for rootfs labels at build time (which could be awhile considering the tooling impact) a simple one line delete in init.cpp would be all that is needed. This would also have the side effect of preventing the policy from being hardcoded and scattered outside of the sepolicy directory. Just my two cents. Bill From: Nick Kralevich [mailto:[email protected]] Sent: Tuesday, June 2, 2015 3:13 PM To: Roberts, William C Cc: [email protected]<mailto:[email protected]> Subject: Re: killing init seclabel I'd prefer if we work on getting proper kernel support for handling SELinux labels on the rootfs. http://marc.info/?l=initramfs&m=142178147926029&w=2 adds support for a rootfs with SELinux labels built in, but that patchset seems to have stalled. Once we have that, then we could do all the rootfs labeling at build time, and not have to tweak labels at runtime. -- Nick On Tue, Jun 2, 2015 at 11:18 AM, Roberts, William C <[email protected]<mailto:[email protected]>> wrote: Given that rootfs supports restorecon can we kill seclabel and just label things in sbin and set up transitions? Can we perhaps support genfscon path name labeling like in sysfs/procfs and thus avoid the need for a restorecon? Any objections to this or preference in approach? Thanks, Bill _______________________________________________ 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].
