[Sorry, to any who have received twice]
Hi,
We at IBM are also interested in LInux security policies and tools to analyze them. At present, we have a start on the latter, and are getting oriented to work more specifically on the former.
In particular, we are interested in the managing the safety of an access control policy and hoping that better safety management will lead to simpler policies.
Basically, we use the current access control configuration to partition the authorization space into: (1) that is known to be authorized; (2) that is known to be precluded (e.g., by constraints or DTE assertions); and (3) the remainder which is unknown with respect to safety. While the system will only permit accesses in the authorized space at any time, configuration changes could alter this space and require more assertions to maintain safety. Eliminating the unknown space and keeping the number and complexity of assertions small is key to keeping access control configurations simple in our opinion. Ideas like determining which rules prevent a particular authorization would also we useful for us to identify overlapping or subsumed assertions, as well as identiying the impact of removing an assertion.
I realize that this description is a bit abstract, but I would appreciate any comments.
Because we have a model for analysis that is different than the SELinux/DTE environment, we are working on conversion between DTE and our analysis model. I guess that I would agree with Jon that another model for analysis is likely to be different. A library for reading DTE specs with hooks for conversion into analysis models would be useful to us.
We are still in the process of such a conversion before we can actually start to do analysis on DTE policies.
Regards,
Trent.
Jon Crowley <jonathan@mitre.org>@tycho.nsa.gov on 10/10/2001 01:02:20 PM
Sent by: owner-selinux@tycho.nsa.gov
To: Stephen Smalley <sds@tislabs.com>
cc: Frank Mayer <mayerf@tresys.com>, SELinux@tycho.nsa.gov,
slinux@scotty.mitre.org
Subject: Re: Security policy analysis
> Some people at MITRE have been working on similar policy analysis tools.
Yes, MITRE is developing tools for policy analysis.
We intend on developing functions to do the following first:
For testing purposes, we implemented some of these functions (1-6, 7 under construction) as small, individual programs borrowing code from checkpolicy sources. Eventually we would like to combine these programs into one tool that provides policy analysis capabilities. Because we see the above list as growing and want it to be as flexible as possible to be able to handle tailored requests from the policy administrator, we plan on implementing an interactive query language front-end to this tool, as Steve suggested.
Steve also suggested incorporating these functions into checkpolicy. With the interactive query front-end, this would become the policy analysis tool. However, our take on checkpolicy is that it is intended to compile policies and to assist in debugging specific to security identifiers. We are thinking it might be cleaner to keep policy analysis tools separate from a policy compiling/debugging tool. Though perhaps we have the wrong take on checkpolicy. More thoughts on this?
The problem with building a separate tool is that both tools will share some of the same code. Does it makes sense to pull out commonly-used code in checkpolicy, specifically the code that reads in the binary and text versions of the policy into data structures, and put this code into some sort of library? It seems this code may be useful to future applications, and it would be easier to maintain and more accessible if it was in a library.
Jon Crowley
MITRE Corporation
-- You have received this message because you are subscribed to the selinux list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. -- You have received this message because you are subscribed to the selinux list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT