Who will actually do the relabeling? By daemon I really meant some code somewhere. It could be a one-shot service. So on reload, we call this one shot service, it does an "sediff" applies the proper label changes, and moves onto the reload. So then what happens if the load fails, it would need to revert back, and undo all the labels. Is their a way to check that a policy will load properly before attempting to load it. If it fails, can we just label back and reload? Will the device be stable or will something freak and cause a reboot?
On Fri, Aug 23, 2013 at 1:12 PM, Joshua Brindle <[email protected]>wrote: > 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 >> >> > -- Respectfully, William C Roberts
