[prev in list] [next in list] [prev in thread] [next in thread]
List: seandroid-list
Subject: Re: eCryptfs, namespaces, and mounting
From: Clifford Liem <clifford.liem () graphitesoftware ! com>
Date: 2015-05-02 2:37:09
Message-ID: CAJDMqhM58qU=YUEyGabw6TyvEZo0eMMrYArj5HHTDM91YCPw0A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
We've addressed this concern with a simple translation of pids per
namespace.
Thanks,
Cliff
On May 1, 2015 9:42 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> On 04/30/2015 11:23 AM, Stephen Smalley wrote:
> > On 04/29/2015 10:37 PM, Clifford Liem wrote:
> >>
> >>
> >> On Apr 29, 2015, at 11:22 AM, Stephen Smalley <sds@tycho.nsa.gov
> >> <mailto:sds@tycho.nsa.gov>> wrote:
> >>
> >>> On 04/29/2015 10:53 AM, Stephen Smalley wrote:
> >>>> On 04/29/2015 10:10 AM, Clifford Liem wrote:
> >>>>> Background:
> >>>>>
> >>>>> We are using eCryptfs as a way to encrypt directories as well as PID
> >>>>> namespaces as a way to isolate processes.
> >>>>
> >>>> I believe Samsung has been using ecryptfs as well, not sure how they
> are
> >>>> addressing it, but perhaps they can do all of the mounting from vold
> or
> >>>> zygote.
> >>>>
> >>>> Wondering how use of PID namespaces might affect binder services that
> >>>> rely on the sender PID information provided by the kernel binder
> driver
> >>>> and those that rely on getpidcon(), e.g. servicemanager and keystore.
> >>>
> >>> BTW, what do you see as the security benefit of PID namespaces? They
> >>> are primarily advertised as a way to support process
> >>> suspend/resume/migration, not a security feature.
> >>>
> >>
> >> I think that suspend/resume/migration is just an example, but the
> >> collection of different types of namespaces as a whole is for security
> >> purposes. With PID namespaces we can isolate visibility of processes, as
> >> well as restrict signals (e.g. kill) along different namespace
> hierarchies.
> >> https://lwn.net/Articles/531114/
> >
> > I really don't believe there is anything you can do via PID namespaces
> > that you can't already do via SELinux, e.g. it can already isolate
> > /proc/pid directories, signals, etc. And for signals and a subset of
> > the /proc/pid files, you already get isolation by virtue of the per-app
> > UIDs. Just not sure it is worth using PID namespaces for this purpose...
>
> Also, have you checked whether the use of PID namespaces in Android
> might break use of Binder.getCallingPid() throughout the Android
> frameworks as a way to reliably and uniquely identify callers?
>
>
[Attachment #5 (text/html)]
<p dir="ltr">We've addressed this concern with a simple translation of pids per \
namespace.</p> <p dir="ltr">Thanks,</p>
<p dir="ltr">Cliff</p>
<div class="gmail_quote">On May 1, 2015 9:42 AM, "Stephen Smalley" <<a \
href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/30/2015 11:23 AM, Stephen \
Smalley wrote:<br> > On 04/29/2015 10:37 PM, Clifford Liem wrote:<br>
>><br>
>><br>
>> On Apr 29, 2015, at 11:22 AM, Stephen Smalley <<a \
href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a><br> >> <mailto:<a \
href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a>>> wrote:<br> >><br>
>>> On 04/29/2015 10:53 AM, Stephen Smalley wrote:<br>
>>>> On 04/29/2015 10:10 AM, Clifford Liem wrote:<br>
>>>>> Background:<br>
>>>>><br>
>>>>> We are using eCryptfs as a way to encrypt directories as well as \
PID<br> >>>>> namespaces as a way to isolate processes.<br>
>>>><br>
>>>> I believe Samsung has been using ecryptfs as well, not sure how they \
are<br> >>>> addressing it, but perhaps they can do all of the mounting \
from vold or<br> >>>> zygote.<br>
>>>><br>
>>>> Wondering how use of PID namespaces might affect binder services \
that<br> >>>> rely on the sender PID information provided by the kernel \
binder driver<br> >>>> and those that rely on getpidcon(), e.g. \
servicemanager and keystore.<br> >>><br>
>>> BTW, what do you see as the security benefit of PID namespaces? \
They<br> >>> are primarily advertised as a way to support process<br>
>>> suspend/resume/migration, not a security feature.<br>
>>><br>
>><br>
>> I think that suspend/resume/migration is just an example, but the<br>
>> collection of different types of namespaces as a whole is for security<br>
>> purposes. With PID namespaces we can isolate visibility of processes, as<br>
>> well as restrict signals (e.g. kill) along different namespace \
hierarchies.<br> >> <a href="https://lwn.net/Articles/531114/" \
target="_blank">https://lwn.net/Articles/531114/</a><br> ><br>
> I really don't believe there is anything you can do via PID namespaces<br>
> that you can't already do via SELinux, e.g. it can already isolate<br>
> /proc/pid directories, signals, etc. And for signals and a subset of<br>
> the /proc/pid files, you already get isolation by virtue of the per-app<br>
> UIDs. Just not sure it is worth using PID namespaces for this purpose...<br>
<br>
Also, have you checked whether the use of PID namespaces in Android<br>
might break use of Binder.getCallingPid() throughout the Android<br>
frameworks as a way to reliably and uniquely identify callers?<br>
<br>
</blockquote></div>
_______________________________________________
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic