B2G

B2G

[lkcl luke]

allo again: it's been a while since i've been actively been involved
with selinux.

i just wanted to alert people to the proposal that i put forward to
the mozilla B2G team that they consider deploying the FLASK security
model (specifically SE/Linux).
https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
(that's a publicly-editable wiki if anyone wants to comment/edit)

the concept behind B2G is that the xulrunner (gecko) engine is bashed
about and hacked into submission to do double-duty of being *both* a
window manager *and* a web browser, and then applications are defined
as being "a bit of HTML and Javascript".  yeah it's WebOS in disguise,
but they're beginning from the android codebase, ripping out webkit
and all the java (hurraaay!) and dropping in gecko instead.

so they've got quite a big - and cool - task ahead of them, and they
need a replacement for the android security model.  that's where i
went "eyy, i know something that would cope, that would be up to the
job and would mean no linux kernel coding required, it's called
SE/Linux" :)

so i had a couple of questions which would help me to assess the
viability of my own recommendation.

firstly: allo to steven, are you still around? :)

second: did that idea of dynamically allowing bits of binary-compiled
se-linux permissions ever get implemented?  last time i was on this
list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
one huge humungous gelatinous blob that you couldn't mess with, not
without doing a tooootal recompile using the m4 macros.

third: are them happy m4 macros still about? :)  did anyone invent
anything more... oo.. user-friendly shall we say?  i quite liked them
once i got used to it but i'm a bit concerned about the m4 macro
language's obtuseness, if people in the B2G group were to be expected
to cope with them.  or, more to the point, if application developers
were expected to be able to cope.


the reason i ask about 2) above is because the suggestion has come up
that an application may provide a wide and comprehensive set of
functionality (access to the GSM/3G modem as well as access to the
GPS), and users may not wish the application to have both.

so what i figured was that if the selinux permissions were actually
broken down into *three* binary blobs (or as many as are required) it
would save CPU cycles on the device (which is going to be
resource-limited) as well as improving the response time.

so, in the example given, blob 1 would cover most of the app; blob 2
would cover that app's access to the GSM/3G modem and blob 3 would
cover access to the GPS.

what's the story?

warm regards,

l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[Patrick K., ITF]

On 3/16/2012 1:46 AM, lkcl luke wrote:
 > allo again: it's been a while since i've been actively been involved
 > with selinux.
 >
 > i just wanted to alert people to the proposal that i put forward to
 > the mozilla B2G team that they consider deploying the FLASK security
 > model (specifically SE/Linux).
 > https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
 > (that's a publicly-editable wiki if anyone wants to comment/edit)
 >

Sounds great, but wouldn't it be more proper to call Flask a Security 
Architecture rather than a Security model?

Since Flask (Flux Advances Security Kernel) tends to be a security 
architecture,  Making it possible to implement various security models 
(Schemes and plans for deploying and enforcing security policies)  such 
as Mandatory Access Control (MAC), RBAC (Role Based Access Control), MLS 
(Multi Level Security), it is even possible to implement Biba (although 
SElinux permits exemptions), Bell-LaPadula Models and so on so forth

anyway SELinux is technically an implementation of Mandatory access 
control based on Flask Architecture.

 > the concept behind B2G is that the xulrunner (gecko) engine is bashed
 > about and hacked into submission to do double-duty of being *both* a
 > window manager *and* a web browser, and then applications are defined
 > as being "a bit of HTML and Javascript".  yeah it's WebOS in disguise,
 > but they're beginning from the android codebase, ripping out webkit
 > and all the java (hurraaay!) and dropping in gecko instead.
 >
 > so they've got quite a big - and cool - task ahead of them, and they
 > need a replacement for the android security model.  that's where i
 > went "eyy, i know something that would cope, that would be up to the
 > job and would mean no linux kernel coding required, it's called
 > SE/Linux" :)

Have you seen this page?  SEAndroid

http://selinuxproject.org/page/SEAndroid



 >
 > so i had a couple of questions which would help me to assess the
 > viability of my own recommendation.
 >
 > firstly: allo to steven, are you still around? :)
 >
 > second: did that idea of dynamically allowing bits of binary-compiled
 > se-linux permissions ever get implemented?  last time i was on this
 > list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
 > one huge humungous gelatinous blob that you couldn't mess with, not
 > without doing a tooootal recompile using the m4 macros.
 >


Excuse me do you mean changing roles or policies on the fly in userland? 
Wouldn't that violate Security models and policies in example MAC, RBAC, 
MLS and anything mandatory?

anyway semanage permits changing some aspects of the policies without 
recompiling them,

# man semanage

"semanage  is used to configure certain elements of SELinux policy 
without requiring modification to or recompilation from policy sources."


 > third: are them happy m4 macros still about? :)  did anyone invent
 > anything more... oo.. user-friendly shall we say?  i quite liked them
 > once i got used to it but i'm a bit concerned about the m4 macro
 > language's obtuseness, if people in the B2G group were to be expected
 > to cope with them.  or, more to the point, if application developers
 > were expected to be able to cope.
 >

I'm afraid it is there, M4 I meant,

SELinux policies have been turned into click and click  GUI ?!,

NO,

at least not to what I think that you think :-) but there are policy 
editors out there, such as:

http://magazine.redhat.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/

or

http://seedit.sourceforge.net/



 >
 > the reason i ask about 2) above is because the suggestion has come up
 > that an application may provide a wide and comprehensive set of
 > functionality (access to the GSM/3G modem as well as access to the
 > GPS), and users may not wish the application to have both.
 >
 > so what i figured was that if the selinux permissions were actually
 > broken down into *three* binary blobs (or as many as are required) it
 > would save CPU cycles on the device (which is going to be
 > resource-limited) as well as improving the response time.
 >
 > so, in the example given, blob 1 would cover most of the app; blob 2
 > would cover that app's access to the GSM/3G modem and blob 3 would
 > cover access to the GPS.
 >

I suppose you are proposing Role Based Access Control, assigning 
different roles to their appropriate modules.

May be you want to take a look here:

http://selinuxproject.org/page/SEAndroid

and here:

http://www.selinuxproject.org/page/Main_Page

 > what's the story?
 >
 > warm regards,
 >
 > l.
 >
 > --
 > This message was distributed to subscribers of the selinux mailing list.
 > If you no longer wish to subscribe, send mail to 
majordomo@tycho.nsa.gov with
 > the words "unsubscribe selinux" without quotes as the message.


Patrick K.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[Stephen Smalley]

On Fri, 2012-03-16 at 05:46 +0000, lkcl luke wrote:
> allo again: it's been a while since i've been actively been involved
> with selinux.
> 
> i just wanted to alert people to the proposal that i put forward to
> the mozilla B2G team that they consider deploying the FLASK security
> model (specifically SE/Linux).
> https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
> (that's a publicly-editable wiki if anyone wants to comment/edit)

See http://www.nsa.gov/research/selinux/related.shtml for some links to
work done to apply Flask to various other applications like PostgreSQL,
Xorg, and D-BUS.

> the concept behind B2G is that the xulrunner (gecko) engine is bashed
> about and hacked into submission to do double-duty of being *both* a
> window manager *and* a web browser, and then applications are defined
> as being "a bit of HTML and Javascript".  yeah it's WebOS in disguise,
> but they're beginning from the android codebase, ripping out webkit
> and all the java (hurraaay!) and dropping in gecko instead.
> 
> so they've got quite a big - and cool - task ahead of them, and they
> need a replacement for the android security model.  that's where i
> went "eyy, i know something that would cope, that would be up to the
> job and would mean no linux kernel coding required, it's called
> SE/Linux" :)
> 
> so i had a couple of questions which would help me to assess the
> viability of my own recommendation.
> 
> firstly: allo to steven, are you still around? :)

Yes.

> second: did that idea of dynamically allowing bits of binary-compiled
> se-linux permissions ever get implemented?  last time i was on this
> list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
> one huge humungous gelatinous blob that you couldn't mess with, not
> without doing a tooootal recompile using the m4 macros.

At the userspace level, there has long been support for binary policy
modules (Fedora >= 5, RHEL >= 5, Debian >= 4.0). The policy modules are
still ultimately linked into a single blob for the kernel before
loading, but you can manage it at the userspace level via semodule and
semanage.

> third: are them happy m4 macros still about? :)  did anyone invent
> anything more... oo.. user-friendly shall we say?  i quite liked them
> once i got used to it but i'm a bit concerned about the m4 macro
> language's obtuseness, if people in the B2G group were to be expected
> to cope with them.  or, more to the point, if application developers
> were expected to be able to cope.

m4 macros are still widely used in the source policy.  There has been
some experimentation with a newer policy language with a first-class
notion of interfaces to supplant the use of a preprocessor, but that's
experimental, e.g. see:
http://userspace.selinuxproject.org/trac/wiki/CilDesign

There is a SELinux Policy IDE, http://oss.tresys.com/projects/slide,
packaged as "eclipse-slide" in modern Fedora and RHEL.

In the case of SEAndroid [http://selinuxproject.org/page/SEAndroid], we
have carefully avoided the need for Android app developers to ever see
or write SELinux policy rules.

> the reason i ask about 2) above is because the suggestion has come up
> that an application may provide a wide and comprehensive set of
> functionality (access to the GSM/3G modem as well as access to the
> GPS), and users may not wish the application to have both.
> 
> so what i figured was that if the selinux permissions were actually
> broken down into *three* binary blobs (or as many as are required) it
> would save CPU cycles on the device (which is going to be
> resource-limited) as well as improving the response time.

I think you are better off just building the policy on a centralized
server and shipping the final policy to the device rather than trying to
manage it as modules on the device.  Linking the binary policy module
together to form the kernel policy is still fairly memory and CPU
intensive unfortunately.

> so, in the example given, blob 1 would cover most of the app; blob 2
> would cover that app's access to the GSM/3G modem and blob 3 would
> cover access to the GPS.
> 
> what's the story?

Who provides the policy?  For a mobile device, you typically don't trust
the application package (contrast with Linux packages) and thus do not
want to simply take policy provided by the packager for that app.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[lkcl luke]

On Fri, Mar 16, 2012 at 7:39 AM, Patrick K., ITF <cto@itechfrontiers.com> wrote:
> On 3/16/2012 1:46 AM, lkcl luke wrote:
>> allo again: it's been a while since i've been actively been involved
>> with selinux.
>>
>> i just wanted to alert people to the proposal that i put forward to
>> the mozilla B2G team that they consider deploying the FLASK security
>> model (specifically SE/Linux).
>> https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
>> (that's a publicly-editable wiki if anyone wants to comment/edit)
>>
>
> Sounds great, but wouldn't it be more proper to call Flask a Security
> Architecture rather than a Security model?

 ah thank you for the corrections, patrick.  i've updated the wiki
page for them, accordingly.

>> so they've got quite a big - and cool - task ahead of them, and they
>> need a replacement for the android security model.  that's where i
>> went "eyy, i know something that would cope, that would be up to the
>> job and would mean no linux kernel coding required, it's called
>> SE/Linux" :)
>
> Have you seen this page?  SEAndroid
>
> http://selinuxproject.org/page/SEAndroid

 have now - thank you :)


>> second: did that idea of dynamically allowing bits of binary-compiled
>> se-linux permissions ever get implemented?  last time i was on this
>> list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
>> one huge humungous gelatinous blob that you couldn't mess with, not
>> without doing a tooootal recompile using the m4 macros.
>>
>
>
> Excuse me do you mean changing roles or policies on the fly in userland?
> Wouldn't that violate Security models and policies in example MAC, RBAC, MLS
> and anything mandatory?

 ah it's ok - stephen knows what i'm referring to.  apologies patrick,
there's some context i may not have correctly explained, which stephen
remembers.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[lkcl luke]

On Fri, Mar 16, 2012 at 1:22 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2012-03-16 at 05:46 +0000, lkcl luke wrote:
>> allo again: it's been a while since i've been actively been involved
>> with selinux.
>>
>> i just wanted to alert people to the proposal that i put forward to
>> the mozilla B2G team that they consider deploying the FLASK security
>> model (specifically SE/Linux).
>> https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
>> (that's a publicly-editable wiki if anyone wants to comment/edit)
>
> See http://www.nsa.gov/research/selinux/related.shtml for some links to
> work done to apply Flask to various other applications like PostgreSQL,
> Xorg, and D-BUS.

 ta stephen.  put a link on the wiki to that.

>> the concept behind B2G is that the xulrunner (gecko) engine is bashed
>> about and hacked into submission to do double-duty of being *both* a
>> window manager *and* a web browser, and then applications are defined
>> as being "a bit of HTML and Javascript".  yeah it's WebOS in disguise,
>> but they're beginning from the android codebase, ripping out webkit
>> and all the java (hurraaay!) and dropping in gecko instead.
>>
>> so they've got quite a big - and cool - task ahead of them, and they
>> need a replacement for the android security model.  that's where i
>> went "eyy, i know something that would cope, that would be up to the
>> job and would mean no linux kernel coding required, it's called
>> SE/Linux" :)
>>
>> so i had a couple of questions which would help me to assess the
>> viability of my own recommendation.
>>
>> firstly: allo to steven, are you still around? :)
>
> Yes.

 eyyy, that's good to hear.

>> second: did that idea of dynamically allowing bits of binary-compiled
>> se-linux permissions ever get implemented?  last time i was on this
>> list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
>> one huge humungous gelatinous blob that you couldn't mess with, not
>> without doing a tooootal recompile using the m4 macros.
>
> At the userspace level, there has long been support for binary policy
> modules (Fedora >= 5, RHEL >= 5, Debian >= 4.0).

 ha good stuff.  shows you how long it is since i've tackled SE/Linux...

> The policy modules are
> still ultimately linked into a single blob for the kernel before
> loading, but you can manage it at the userspace level via semodule and
> semanage.

 ok.

>> third: are them happy m4 macros still about? :)  did anyone invent
>> anything more... oo.. user-friendly shall we say?  i quite liked them
>> once i got used to it but i'm a bit concerned about the m4 macro
>> language's obtuseness, if people in the B2G group were to be expected
>> to cope with them.  or, more to the point, if application developers
>> were expected to be able to cope.
>
> m4 macros are still widely used in the source policy.  There has been
> some experimentation with a newer policy language with a first-class
> notion of interfaces to supplant the use of a preprocessor, but that's
> experimental, e.g. see:
> http://userspace.selinuxproject.org/trac/wiki/CilDesign
>
> There is a SELinux Policy IDE, http://oss.tresys.com/projects/slide,
> packaged as "eclipse-slide" in modern Fedora and RHEL.
>
> In the case of SEAndroid [http://selinuxproject.org/page/SEAndroid], we
> have carefully avoided the need for Android app developers to ever see
> or write SELinux policy rules.

 interesting.  that might help here.

>> the reason i ask about 2) above is because the suggestion has come up
>> that an application may provide a wide and comprehensive set of
>> functionality (access to the GSM/3G modem as well as access to the
>> GPS), and users may not wish the application to have both.
>>
>> so what i figured was that if the selinux permissions were actually
>> broken down into *three* binary blobs (or as many as are required) it
>> would save CPU cycles on the device (which is going to be
>> resource-limited) as well as improving the response time.
>
> I think you are better off just building the policy on a centralized
> server and shipping the final policy to the device rather than trying to
> manage it as modules on the device.  Linking the binary policy module
> together to form the kernel policy is still fairly memory and CPU
> intensive unfortunately.

 mmm.... hmm... that really can't happen unfortunately.  this could
potentially be millions of units out there, in just as uncontrolled a
fashion as android.

 worst case a phone vendor tries to put this OS onto a 700mhz ARM11
with only 256mb of RAM.  the user experience would be absolutely
dreadful but i'm sure they'll try it on, just to get the price down.
under such circumstances they'll probably have on-board DSPs for
base-band processing (with arbitrary code execution downloadable over
the GSM/3G/CDMA network) in which case it makes a whole mockery of the
idea of "security" anyway.

 so... they'd most likely end up switching off the entire security
model anyway, and just run it as a ghost shell.

>> so, in the example given, blob 1 would cover most of the app; blob 2
>> would cover that app's access to the GSM/3G modem and blob 3 would
>> cover access to the GPS.
>>
>> what's the story?
>
> Who provides the policy?  For a mobile device, you typically don't trust
> the application package (contrast with Linux packages) and thus do not
> want to simply take policy provided by the packager for that app.

 ah, right... :)  i'm actually proposing to them that they treat the
JS/HTML/CSS *as* a "package" - with a complete .deb that gets
digitally-signed etc. etc. all the implications thereof, including
archive management, FTP masters etc. etc.

 so there will be an opportunity to have the usual debconf postinst
triggers to apply/build the SE-Linux policy.

 thank you to both of you,

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[Christopher J. PeBenito]

On 03/16/12 01:46, lkcl luke wrote:
> second: did that idea of dynamically allowing bits of binary-compiled
> se-linux permissions ever get implemented?  last time i was on this
> list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
> one huge humungous gelatinous blob that you couldn't mess with, not
> without doing a tooootal recompile using the m4 macros.

Yes, we do have modular policy now.  Right now they are compiled, but hopefully we'll eventually be able to set to text modules.  You compile .pp files that have some compiled policy and optional a .fc, and link them together into the policy.2x
 
> third: are them happy m4 macros still about? :)  did anyone invent
> anything more... oo.. user-friendly shall we say?  i quite liked them
> once i got used to it but i'm a bit concerned about the m4 macro
> language's obtuseness, if people in the B2G group were to be expected
> to cope with them.  or, more to the point, if application developers
> were expected to be able to cope.

Yes.  In a very different form than the NSA example policy: http://oss.tresys.com/projects/refpolicy

Hopefully CIL will be completed, as that will make it possible to make Reference Policy a proper language and most if not all of the M4 will be dropped. http://userspace.selinuxproject.org/trac/wiki/CilDesign

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: B2G

[lkcl luke]

On Fri, Mar 16, 2012 at 2:21 PM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On 03/16/12 01:46, lkcl luke wrote:
>> second: did that idea of dynamically allowing bits of binary-compiled
>> se-linux permissions ever get implemented?  last time i was on this
>> list (eek, 2004?), the whole SE/Linux precompiled blob was just that:
>> one huge humungous gelatinous blob that you couldn't mess with, not
>> without doing a tooootal recompile using the m4 macros.
>
> Yes, we do have modular policy now.  Right now they are compiled, but hopefully we'll eventually be able to set to text modules.  You compile .pp files that have some compiled policy and optional a .fc, and link them together into the policy.2x

 thanks christopher, this is really useful and valuable stuff which
will help in the evaluation process.

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: B2G

[Radzykewycz, T (Radzy)]

> From: owner-selinux@tycho.nsa.gov [owner-selinux@tycho.nsa.gov] on behalf of Stephen Smalley [sds@tycho.nsa.gov]
> Sent: Friday, March 16, 2012 6:22 AM
> To: lkcl luke
> Cc: selinux@tycho.nsa.gov
> Subject: Re: B2G
>
> <snip>
>
> Who provides the policy?  For a mobile device, you typically don't trust
> the application package (contrast with Linux packages) and thus do not
> want to simply take policy provided by the packager for that app.
>
> --
> Stephen Smalley
> National Security Agency

Hi Stephen

I see two options to trust a downloaded policy: when it is 
downloaded from a Device Administrator application, or as part 
of a system update.

Enjoy!

                                -- radzy


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.