I think you misunderstand the threat. As we found from boot loader and firmware update attacks, the ways to subvert policy are manifold. How can I tell who the “manufacturer” of my android phone that sets the policy really is and do I trust Android to maintain that trust.
thx ..tom From: William Roberts Sent: Friday, April 7, 2017 11:59 AM To: Tom Jones Cc: seandroid-list@tycho.nsa.gov; seli...@tycho.nsa.gov; Nick Kralevich Subject: Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE On Apr 7, 2017 11:44, "Tom Jones" <thomasclinganjo...@gmail.com> wrote: I am highly skeptical of policy setting and the supply chain. In the threat models I create, the supply chain is always the weak, open threat. I could not begin to guess who the manufacturer of a device is. Android, Samsung, Verizon or the US Gov't. Is there a threat model for SE Android, or whatever it is called now? Well SE Android is fully integrated into Android. Vendors create the policy that ends up the boot image, which is typically signature verified at boot. If your supply chain is compromised, the selinux policy is your least concern. Under treble it ends up in different DM verity protected images. I looked at the other site and decided it was looking at the technical problem and not the policy problem at all. On Fri, Apr 7, 2017 at 11:23 AM, William Roberts <bill.c.robe...@gmail.com> wrote: On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjo...@gmail.com> wrote: I like that, but I wonder at its scope. Would an update to the OS be allowed to update the policy? For example, Microsoft ships updates to the Windows O/S 2 times (at least) per month. Would that type of update to Android allow policy updates? Part of Android's updates include the policy that is loaded, so the update mechanism is in place. Another question involves the list of authoritative CSPs. That can now be updated in most O/S available on the market. Is that still allowed to be updated, or is that already allowed by policy? ..tom The policy is updated, currently, as part of the root file system. In a feature in progress, TREBLE (FULL_PRODUCT_TREBLE == true), two files, one from vendor and one from google are used to generate the policy. essentially, the policy only comes from those making the device, theirs no random folks adding/removing policy. On Fri, Apr 7, 2017 at 10:34 AM, Nick Kralevich <n...@google.com> wrote: I wanted to draw people's attention to the following proposed change: https://android-review.googlesource.com/367695 In the case of Android, it's common for security policy to be loaded once, and never reloaded again. In that case, the locking / unlocking surrounding the in-kernel policy is unnecessary and can be avoided. The patch above turns the locks into no-ops and ensures that the kernel cannot load a policy more than once. End result is that locking and preemption overhead is avoided and there's less attack surface / code compiled into the kernel. I would appreciate comments on the change. This feels like a worthwhile change for the entire SELinux community. -- Nick -- Nick Kralevich | Android Security | n...@google.com | 650.214.4037 _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov. -- ..tom _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov. -- Respectfully, William C Roberts -- ..tom
_______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
