lkml.org 
[lkml]   [2009]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Apparmor-dev] New security system FBAC-LSM announcement and call for collaborators
At 04:30 PM 12/11/2009, Cliffe wrote:

>I developed FBAC-LSM for my PhD research. FBAC-LSM restricts
>programs based on the features each application provides. Reusable
>policy abstractions, known as functionalities, can be used to grant
>the authority to perform high level features (for example using the
>Web_Browser functionality) or lower level features (such as using
>the HTTP_Client functionality) or to grant privileges to access any
>specified resources. Functionalities are parameterised, which allows
>them to be adapted to the needs of specific applications.
>Functionalities are also hierarchical; that is, functionalities can
>contain other functionalities.

Looks good!

Been trying to get distros to implement something like this too, glad
there's some progress :).

https://bugzilla.novell.com/show_bug.cgi?id=308760#c1

https://bugs.launchpad.net/ubuntu/+bug/156693

I think the slight difference is, with my proposal a program might
actually request the "functionality" (I called it "sandbox template")
it wants to be run with. This is not as crazy as it seems, since it
means the program declares its limits upfront before the user or the
OS says "that looks OK".

And these sandboxes (functionalities and custom functionalities) can
be digitally signed (along with the programs).

Thus, a distro might sign sandboxes for certain apps - this way a
desktop user will not need to be bothered or prompted for those apps.

A paranoid administrator can prevent the execution of programs that
do not have acceptable sandboxes (only programs with very safe
sandboxes and programs with "not so safe" sandboxes but are signed).

Also, a trusted 3rd party (security auditor etc) could audit a
program and its sandbox, and if it looks ok, certify/sign it. Or
maybe only certify it with a modified sandbox.

It should be easier to verify that a proposed sandbox is OK, than it
is to verify that a program will be OK to run before running it
(which is like solving a halting problem without the source code and
full knowledge of the inputs ;) ).

The problem is we'd have to prevent the wrong programs from being run
with the wrong custom sandboxes - the signature should take care of
it - change the app and the signature + template + app should no
longer be valid. However the problem is if the application is
updated/patched, the signature won't be valid, but this might be a
necessary tradeoff for custom sandboxes (or "full privilege" sandboxes).

Best regards,

Link.













\
 
 \ /
  Last update: 2009-12-11 19:27    [W:0.029 / U:2.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site