In preparation for my LCA talk ?A New Paradigm for Restricting
Applications and Protecting Yourself from Your Processes?, today I have
released the code for FBAC-LSM. This initial development version of
FBAC-LSM is functional, but is unstable and slow. It is developed
against an older version of the LSM interface (using the AppArmor
path-based hooks), and will be updated to work with the new interface in
the future. There is quite a bit of work to be done before it is ready
for production systems or formal code review.
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.
Over one hundred applications were analysed, and functionalities and
policies were developed. A number of techniques for automating aspects
of policy specification were also developed. A usability study comparing
FBAC-LSM with SELinux and AppArmor found that the new approach provided
significant benefits including higher levels of user satisfaction and of
successful policy creation. In the near future I will share the results
of the usability study, including suggestions for improving the
usability of SELinux and AppArmor.
Currently I am planning on expanding the FBAC-LSM tools to export to and
manage AppArmor and SEEdit policies.
I am looking for anyone interested in collaborating on the project.
Please contact me. There are a number of problems with the
synchronisation in the LSM code, which I hope someone on one of these
mailinglists can help with.
Programmed in C and C++, using the LSM and Qt frameworks. Policy
abstractions in FBAC-LSM-PL policy language. Licensed GPL.
Check out the FBAC-LSM homepage which has lots more information and videos:
http://schreuders.org/FBAC-LSM
Pull the sourceforge Git repo (which includes the Linux Security Module
(LSM), graphical policy manager, and policies) to your computer with the
command:
git clone git://fbac-lsm.git.sourceforge.net/gitroot/fbac-lsm/fbac-lsm
If you are attending the 2010 linux.conf.au conference, I hope to see
you at my talk in room Renouf 2 at 16:45 on Wednesday 20/01/10:
http://www.lca2010.org.nz/programme/schedule/view_talk/50029?day=wednesday
Thanks,
Z. Cliffe Schreuders
http://schreuders.org
PhD Candidate
Murdoch University
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.
Lincoln Yeoh wrote:
> 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.
This can be divided into a few separate ideas.
-FBAC-LSM can currently have multiple policies which apply
simultaneously. Sets of policies are called ?confinements? and each
confinement can apply to a list of users, a separate list says which
users are authorised to maintain (configure) each confinement. One
possible scenario would be to have one confinement which has all the
developer-specified policies. This is not enough security on its own
though, because the security goals of developers is different to that of
users and administrators. Developers may only care about software
vulnerabilities, and would be inclined to specify rather liberal rules.
Then the user or administrator can use also other confinements to
enforce their own goals. An administrator may want to ensure that the
user can only use the program to edit files in their own home directory.
The user may only want the web browser to download files to particular
directories (within their home directory) to protect the user?s
resources from the web browser (a security goal which the developer
would not care about).
The end result is that each ?stakeholder? can enforce their own security
goals. If a user is happy enough with the policies created by third
parties, then they can benefit without doing anything.
It is currently possible for the system admin to configure a confinement
to require a policy to be present for every application in a particular
confinement, otherwise the process wont start.
-I started developing a signature-based application identification
approach, although that idea got put far back on the back burner.
FBAC-LSM currently identifies applications by their pathnames. I think
there may be benefits of using signatures, to further confine versions
of programs, but a fallback pathname based approach ensures that the
program can run and is confined. It could be handy to also allow
programs with certain signatures to be terminated. This is an area for
further development.
-Most of the code is in place for functionalities to be dropped
dynamically for processes. This could allow processes to say ?I only
need functionalities x, y and z, drop the rest". This feature is
currently incomplete.
>
> 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).
This is currently possible.
>
> 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.
This is a very interesting idea which should be investigated further.
Ways for community members and trusted third parties to share and review
policies is definitely an area for future research.
>
> 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 ;) ).
Yeah, FBAC-LSM does a pretty good job of creating a working policy
without first running the program. This makes it possible to say "this
is a game" (in fact FBAC-LSM Policy Manager will say "this looks like a
game"), FBAC-LSM Policy Manager then does some analysis and discovers
the application specific details, and asks the user where the game
stores saved games.
So a policy has been created without running the program. So if the
program is malicious the user is protected. In most cases the user
shouldn't have to use the learning mode, although it is available if it
is needed.
>
> 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).
Yeah. Signatures could differentiate between different versions of the
same program. In most cases it would be safest to have a policy which
applies to a program regardless of the version.
It sounds like you have some good ideas. Please consider contributing to
the project. The signature approach, dynamic policy control, and policy
sharing and reviewing are all ideas which can be developed further. Also
more functionalities need to be developed (I will publish the
methodology used). Alternatively please check out the TODO file to see
if anything there looks like something you would like to do!
(http://fbac-lsm.git.sourceforge.net/git/gitweb.cgi?p=fbac-lsm/fbac-lsm;a=blob;f=TODO)
Thanks for your interest in the project and your thoughts. Please
subscribe to the fbac-lsm mailing list
(https://lists.sourceforge.net/lists/listinfo/fbac-lsm-general)
Cheers,
Z. Cliffe Schreuders