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 <[email protected]> wrote: > > > On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <[email protected]> > 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 <[email protected]> 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 | [email protected] | 650.214.4037 >>> <(650)%20214-4037> >>> >>> _______________________________________________ >>> Seandroid-list mailing list >>> [email protected] >>> To unsubscribe, send email to [email protected]. >>> To get help, send an email containing "help" to >>> [email protected]. >>> >> >> >> >> -- >> ..tom >> >> _______________________________________________ >> Seandroid-list mailing list >> [email protected] >> To unsubscribe, send email to [email protected]. >> To get help, send an email containing "help" to >> [email protected]. >> > > > > -- > Respectfully, > > William C Roberts > > -- ..tom
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
