On Apr 7, 2017 11:44, "Tom Jones" <thomasclinganjones@xxxxxxxxx> 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.roberts@xxxxxxxxx> wrote:On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@xxxxxxxxx> 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?..tomThe 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 <nnk@xxxxxxxxxx> wrote:______________________________I wanted to draw people's attention to the following proposed change: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 | nnk@xxxxxxxxxx | 650.214.4037_________________
Seandroid-list mailing list
Seandroid-list@xxxxxxxxxxxxx
To unsubscribe, send email to Seandroid-list-leave@xxxxxxxxx.gov .
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov .
--..tom
_______________________________________________
Seandroid-list mailing list
Seandroid-list@xxxxxxxxxxxxx
To unsubscribe, send email to Seandroid-list-leave@xxxxxxxxx.gov .
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov .--Respectfully,
William C Roberts..tom
_______________________________________________ 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.
