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?
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.
