Stephen Smalley wrote:
On 08/20/2013 11:22 AM, William Roberts wrote:
Yeah I have ran into this before. In Samsung we just sent an OTA, as it was no
big deal. We either need something like relabeld or a way for the kernel to set
the security attribute at file open based on the policy, rather than needing to
label.... I'm not a huge fan of labeling.
<snip>
I think we need to decide whether labeling changes for /system are legal
via the /data/security policy or whether that level of change requires a
new boot image policy and thus a custom load.
Even if we support a restorecon -R /system as part of policy reload, the
system partition will be mounted before the /data/security policy gets
loaded so those files will all be treated as unlabeled up to that point.
Depending on what the new policy is doing may not be wrong, i.e., if my
intention is to remove access to some files having them unlabeled at
boot isn't a big deal.
The larger problem is type splitting. If I want to kill off access to a
set of apk's I can't do that without relabeling, period.
If we decide that it isn't supported then it has a fairly large impact
on the utility of policy reloading, I think. Right now switching from
e.g., a Samsung policy to an AOSP policy is difficult because of the
divergence of types. They'll either be unlabeled during boot or the new
policy will have to alias every type that is different in the new policy.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
