[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: solved: ueventd fixup_sys_perms restorecon_recursive taking a long time
From:       Nick Kralevich <nnk () google ! com>
Date:       2015-03-31 21:11:16
Message-ID: CAFJ0LnE-7SE4hrPzbXyGbPDzacRTXDpmEUPWtjPsP-HgOU-xMQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Reverting it feels like we'd be going the wrong direction. ueventd*rc
controls normal permissions, whereas /file_contexts controls file labeling.
It's non-intuitive to require editing both for the changes to take effect,
especially since init already does a restorecon_recursive("/sys") on boot
to get everything labeled correctly.

I'd love to see a warning, but like you, I can't figure out a generic way
to write it.

We don't need to take any action here. I just sent my e-mail for education
and because I thought it was an interesting bug.

-- Nick

On Tue, Mar 31, 2015 at 1:11 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> >> substantially improved boot times, as it allowed the
> >> restorecon_recursive optimizations to be effective and avoids visiting
> >> unnecessary directories.
> >
> > Hmm...wonder if we could/should test for such problematic regexes in the
> > label_file backend and at least warn on them.  Then when checkfc is run
> > as part of the policy build, they would get the warning (or error, if we
> > make it fatal).  We'd only really need to impose it on /sys entries
> > though; hard to generalize it.
>
> The other option would be to revert that change (i.e. only restorecon
> files listed in uevent*.rc) and require adding entries to uevent*.rc for
> any files that need specific sysfs contexts at the same time they are
> added to file_contexts.  Then we only use restorecon_recursive for the
> initial /sys restorecon, not on every fixup_sys_perms, although even
> there it would be better to avoid these kinds of regexes.
>
>
>
>


-- 
Nick Kralevich | Android Security | nnk@google.com | 650.214.4037

[Attachment #5 (text/html)]

<div dir="ltr">Reverting it feels like we&#39;d be going the wrong direction. \
ueventd*rc controls normal permissions, whereas /file_contexts controls file \
labeling. It&#39;s non-intuitive to require editing both for the changes to take \
effect, especially since init already does a restorecon_recursive(&quot;/sys&quot;) \
on boot to get everything labeled correctly.  <div><br></div><div>I&#39;d love to see \
a warning, but like you, I can&#39;t figure out a generic way to write \
it.</div><div><br></div><div>We don&#39;t need to take any action here. I just sent \
my e-mail for education and because I thought it was an interesting \
bug.</div><div><br></div><div>-- Nick<br><div class="gmail_extra"><br><div \
class="gmail_quote">On Tue, Mar 31, 2015 at 1:11 PM, Stephen Smalley <span \
dir="ltr">&lt;<a href="mailto:sds@tycho.nsa.gov" \
target="_blank">sds@tycho.nsa.gov</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">&gt;&gt; substantially \
improved boot times, as it allowed the<br> &gt;&gt; restorecon_recursive \
optimizations to be effective and avoids visiting<br> &gt;&gt; unnecessary \
directories.<br> &gt;<br>
&gt; Hmm...wonder if we could/should test for such problematic regexes in the<br>
&gt; label_file backend and at least warn on them.   Then when checkfc is run<br>
&gt; as part of the policy build, they would get the warning (or error, if we<br>
&gt; make it fatal).   We&#39;d only really need to impose it on /sys entries<br>
&gt; though; hard to generalize it.<br>
<br>
</div></div>The other option would be to revert that change (i.e. only restorecon<br>
files listed in uevent*.rc) and require adding entries to uevent*.rc for<br>
any files that need specific sysfs contexts at the same time they are<br>
added to file_contexts.   Then we only use restorecon_recursive for the<br>
initial /sys restorecon, not on every fixup_sys_perms, although even<br>
there it would be better to avoid these kinds of regexes.<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature"><div>Nick Kralevich | Android Security | <a \
href="mailto:nnk@google.com" target="_blank">nnk@google.com</a> | \
650.214.4037</div></div> </div></div></div>



_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.

[prev in list] [next in list] [prev in thread] [next in thread]