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 >>> <(650)%20214-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.
