William Roberts wrote:
Another issue exists with reloadable policy support that I avoided at
Samsung by relying on their willingness to apply system updates via OTA.
Right now, relabeling anything is impossible on anything except an OTA,
else you need to explicitly restorecon the file. Even then, userdata
typically cannot be relabled (typically writing to userdata on an OTA is
a not so good thing using an update script to run restorecons on your
behalf). So the question is, how can make policy updates more capable,
notably the userdata relabeling for both userdata OTA and update
scenarios as well as updating system from a userdata update.
Do we simply say certain things cannot happen?
From my time commercializing it, I can say the only time I ever had to
relabel existing userdata was when I switch MLS cats. However, we were
not in production, so a wipe was reluctantly tolerated.
Thoughts:
relabeld -- smart enough for userdata, and quick. Being able to generate
the delta between polices and smartly applying the update.
I think (hope?) that policy updates, especially ones affecting labels,
would be infrequent enough that having a daemon dedicated to this is
overkill. If it could behave like encryption where you shut down
everything, relabel and restart from class main. It is a little
inconvenient but should be fast enough to not cause too much frustration.
allowing relabeld write access to system (unshare remount system) --
very concerning
--
Respectfully,
William C Roberts
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
