<snip>
Yes I would say this is low on my end. Especially if we can kill off
Reloadable policy support on Android, my need for this goes away 100%.
I'm not sure who "we" is as you are the only person I've heard advocating for removing that support.
Code support exists, but the ability to reload off of /data is on a per-device basis. OEMs as of now
can override this. However, this shows a direction that may or may not be taken on reload from /data.
The fact that there are so many userspace specific parts of the policy that never
make it into the kernel precludes any meaningful verification anyway.
Yes and no. On Android, if I was able to load a policy I could grant myself capabilities that
We're not possible via the userspace portions, i.e. relabeling, etc. Granted, not checking the
userspace portions Is not great. In an ideal world, everything is checked. However, the main
reason to doing it in the kernel is where you want your trust to be. For instance, If I trust that
userspace Loader, then I need to trust that + the kernel. In the case of verifying the policy signature
In the kernel, I need to trust only the kernel.
Especially on Android, userspace files are very important. Changing seapp_contexts or property_contexts can easily get you a privilege escalation to let you do whatever. Checking only the kernel binary is a half-solution and should not even be considered.
I disagree, we can leave it at that.
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
