New security system FBAC-LSM announcement and call for collaborators

New security system FBAC-LSM announcement and call for collaborators

[Cliffe]

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

Re: [Apparmor-dev] New security system FBAC-LSM announcement and call for collaborators

[Lincoln Yeoh]

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.

Re: [Apparmor-dev] New security system FBAC-LSM announcement and call for collaborators

[Cliffe]

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