add CONFIG_SECURITY_SELINUX_LOAD_ONCE

add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Nick Kralevich]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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 | nnk@google.com | 650.214.4037

[-- Attachment #2: Type: text/html, Size: 1078 bytes --]

RE: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

Nack… use Booleans

Allow Android to have 1 boolean that init trips, once innit trips it, the allow to load policy is removed and also the rule to allow toggling that Boolean is removed


From: Seandroid-list [mailto:seandroid-list-bounces@tycho.nsa.gov] On Behalf Of Nick Kralevich
Sent: Friday, April 7, 2017 10:34 AM
To: SELinux <Selinux@tycho.nsa.gov>; seandroid-list@tycho.nsa.gov
Subject: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

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 | nnk@google.com<mailto:nnk@google.com> | 650.214.4037

[-- Attachment #2: Type: text/html, Size: 4801 bytes --]

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Nick Kralevich]

In the interests of avoiding duplicate conversation in multiple
places, let's continue this discussion at
https://android-review.googlesource.com/367695

-- Nick

On Fri, Apr 7, 2017 at 10:43 AM, Roberts, William C
<william.c.roberts@intel.com> wrote:
> Nack… use Booleans
>
> Allow Android to have 1 boolean that init trips, once innit trips it, the
> allow to load policy is removed and also the rule to allow toggling that
> Boolean is removed
>

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Tom Jones]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

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?

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

On Fri, Apr 7, 2017 at 10:34 AM, Nick Kralevich <nnk@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 | nnk@google.com | 650.214.4037
> <(650)%20214-4037>
>
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Seandroid-list-request@tycho.nsa.gov.
>



-- 
..tom

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@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 <nnk@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 | nnk@google.com | 650.214.4037
>> <(650)%20214-4037>
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Seandroid-list-request@tycho.nsa.gov.
>>
>
>
>
> --
> ..tom
>
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Seandroid-list-request@tycho.nsa.gov.
>



-- 
Respectfully,

William C Roberts

[-- Attachment #2: Type: text/html, Size: 4737 bytes --]

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Tom Jones]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

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.roberts@gmail.com>
wrote:

>
>
> On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@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 <nnk@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 | nnk@google.com | 650.214.4037
>>> <(650)%20214-4037>
>>>
>>> _______________________________________________
>>> Seandroid-list mailing list
>>> Seandroid-list@tycho.nsa.gov
>>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>>> To get help, send an email containing "help" to
>>> Seandroid-list-request@tycho.nsa.gov.
>>>
>>
>>
>>
>> --
>> ..tom
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Seandroid-list-request@tycho.nsa.gov.
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>


-- 
..tom

[-- Attachment #2: Type: text/html, Size: 5986 bytes --]

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 3503 bytes --]

On Apr 7, 2017 11:44, "Tom Jones" <thomasclinganjones@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.roberts@gmail.com>
wrote:

>
>
> On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@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 <nnk@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 | nnk@google.com | 650.214.4037
>>> <(650)%20214-4037>
>>>
>>> _______________________________________________
>>> Seandroid-list mailing list
>>> Seandroid-list@tycho.nsa.gov
>>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>>> To get help, send an email containing "help" to
>>> Seandroid-list-request@tycho.nsa.gov.
>>>
>>
>>
>>
>> --
>> ..tom
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Seandroid-list-request@tycho.nsa.gov.
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>


-- 
..tom

[-- Attachment #2: Type: text/html, Size: 7213 bytes --]

RE: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[thomasclinganjones]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

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; selinux@tycho.nsa.gov; Nick Kralevich
Subject: Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE



On Apr 7, 2017 11:44, "Tom Jones" <thomasclinganjones@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.roberts@gmail.com> wrote:


On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@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 <nnk@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 | nnk@google.com | 650.214.4037

_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.



-- 
..tom

_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.




-- 
Respectfully,

William C Roberts



-- 
..tom



[-- Attachment #2: Type: text/html, Size: 10884 bytes --]

RE: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 4392 bytes --]

On Apr 7, 2017 12:03, <thomasclinganjones@gmail.com> wrote:

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.

It's part of a signed  image, but it's tied to the trust of that image. An
attacked bootloader or compromise to the kernel subverts the policy. But
we've seen attacks on boot loaders, etc. none of this has anything to do
with the patch nnk submitted.



thx ..tom



*From: *William Roberts <bill.c.roberts@gmail.com>
*Sent: *Friday, April 7, 2017 11:59 AM
*To: *Tom Jones <thomasclinganjones@gmail.com>
*Cc: *seandroid-list@tycho.nsa.gov; selinux@tycho.nsa.gov; Nick Kralevich
<nnk@google.com>
*Subject: *Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE







On Apr 7, 2017 11:44, "Tom Jones" <thomasclinganjones@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.roberts@gmail.com>
wrote:





On Fri, Apr 7, 2017 at 11:02 AM, Tom Jones <thomasclinganjones@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 <nnk@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 | nnk@google.com | 650.214.4037
<(650)%20214-4037>



_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to
Seandroid-list-request@tycho.nsa.gov.




-- 

..tom


_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to
Seandroid-list-request@tycho.nsa.gov.





-- 

Respectfully,

William C Roberts



-- 

..tom

[-- Attachment #2: Type: text/html, Size: 10766 bytes --]

Re: add CONFIG_SECURITY_SELINUX_LOAD_ONCE

[Paul Moore]

On Fri, Apr 7, 2017 at 1:34 PM, Nick Kralevich <nnk@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.

Without looking at any of the proposed code (see my comment at the end
of this mail), my initial reaction is that isn't something we want to
have to support in the mainline kernel.  For the majority (all?) of
the general purpose and enterprise Linux distributions, the ability to
reload SELinux policy is critical (run time customization, policy
module installs/updates, etc.), and I'm not convinced that this
facility would ever be enabled outside of some embedded/appliance
scenarios.  Even then, I question the usefulness since the policy
itself should be able to prevent policy reloads.

If you are seeing measurable, and problematic, overhead with the
policy locks I'm open to new locking approaches.  From an attack
surface reduction point of view, I have no objection to looking at
removing some of the interfaces from the selinuxfs mount if the loaded
SELinux policy completely removes that privilege from all domains ...
although the code here might be more trouble than it is worth.

On Fri, Apr 7, 2017 at 1:57 PM, Nick Kralevich <nnk@google.com> wrote:
> In the interests of avoiding duplicate conversation in multiple
> places, let's continue this discussion at
> https://android-review.googlesource.com/367695

Posting links to discussions about Android specific changes is fine as
a FYI, and welcome as far as I'm concerned.  However, SELinux patches
which you wish to submit for review and possible inclusion into the
mainline Linux Kernel need to be posted and discussed on the SELinux
mailing list.

-- 
paul moore
www.paul-moore.com