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
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
