We got side tracked in this discussion slightly.
Going back to your original question: I would accept Android patches which
added a restorecon_recursive("/sbin") in init.cpp and the corresponding
SELinux policy changes. It's not the ideal solution, but it seems
reasonable and is a building block to something better.
-- Nick
On Tue, Jun 2, 2015 at 3:34 PM, Roberts, William C <
william.c.robe...@intel.com> wrote:
> 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:n...@google.com]
> *Sent:* Tuesday, June 2, 2015 3:13 PM
> *To:* Roberts, William C
> *Cc:* Seandroid-list@tycho.nsa.gov
> *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 <
> william.c.robe...@intel.com> 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
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to
> seandroid-list-requ...@tycho.nsa.gov.
>
>
>
>
>
> --
>
> Nick Kralevich | Android Security | n...@google.com | 650.214.4037
>
--
Nick Kralevich | Android Security | n...@google.com | 650.214.4037
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
