Re: [Apparmor-dev] New security system FBAC-LSM announcement and call for collaborators
From: Lincoln Yeoh
Date: Fri Dec 11 2009 - 13:24:09 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/