Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Security policy analysis Date: Tue, 9 Oct 2001 15:49:31 -0400
We also find ourselves incrementally building tools to analyze policy.conf files (e.g., show all types with a given attribute, show all rules that involve a given type/attribute). Essentially to help reverse engineer and analyze the intent of a given policy. We have some capabilities built, and are writing additional ones as time and need allow (essentially by borrowing the lex/yacc source from checkpolicy, and building our own policy database and analysis logic). Is anyone else building similar tools? We'd be happy to share our source incrementally with members of the list as we build new capabilities if anyone is interested. PS- Please reply to the mail list; we'd like to start open discussions of policy analysis and development.
Regards,
-- 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.From: John Scroggins <dataefx_at_earthlink.net> subject: RE: Security policy analysis Date: Tue, 9 Oct 2001 16:32:38 -0700
I am not sure if anyone is doing so at the present time, but the direction you are heading is interesting.. As it would help to broaden the use of the kernel in general by supplying those "sample policies". I think one of the hindrances in a large deployment scenario is understanding the policy structure(s) and how they apply to processes (that require protection). A more extensive set of elements which would help guide the potential user,(admin or engineer) in defining environment specific variables, may be a welcome addition. We also find ourselves incrementally building tools to analyze policy.conf files (e.g., show all types with a given attribute, show all rules that involve a given type/attribute). Essentially to help reverse engineer and analyze the intent of a given policy. We have some capabilities built, and are writing additional ones as time and need allow (essentially by borrowing the lex/yacc source from checkpolicy, and building our own policy database and analysis logic). I see this as potentially valuable. I too, would also like to see an extended discussion regarding this resource. Is anyone else building similar tools? We'd be happy to share our source incrementally with members of the list as we build new capabilities if anyone is interested. Integrating this into a kernel-building utility sounds interesting. :) PS- Please reply to the mail list; we'd like to start open discussions of policy analysis and development.
Regards,
--
-- subject: Interested in Reserach work Date: Wed, 10 Oct 2001 11:35:34 +0530
I joined into this group today.
Thanks & Regards,
-- 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 08:26:09 -0400 (EDT)
On Tue, 9 Oct 2001, Frank Mayer wrote:
> We also find ourselves incrementally building tools to analyze policy.conf Some people at MITRE have been working on similar policy analysis tools. Originally, they were creating these tools separately from checkpolicy but drawing from the checkpolicy sources. However, I recommended that they instead look into merging the support for new kinds of queries directly into the existing checkpolicy debugging facility (the -d option) and possibly replacing the checkpolicy debugging interface with an interactive query interface. I'm not sure how far along they are, but you should certainly coordinate. We're interested in the capabilities that you've developed. Can we acquire a copy? -- Stephen D. Smalley, NAI Labs ssmalley@nai.com -- 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.From: ipv6 <ipv6_at_311c.com> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 08:23:07 -0600
>
> We're interested in the capabilities that you've developed. Can we We would also like to get a copy if that is possible?
Joop Cousteau
-- 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.From: Frank Mayer <mayerf_at_tresys.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 10:39:42 -0400
However, I still encourage folks who are looking at developing or analyzing security policies to share any insights you might have. Thanks
Frank Mayer
-- 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.From: Julien Palardy <palj_at_praefect-sys.com> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 14:50:58 +0200
You have any detail on the licensing form of the code? I am highly interested in any policy reverse-engineering mechanism, and even more in policy engineering itself, which can probably be much more useful at this stage of SELinux's developement. --- Julien Palardy <palj@praefect-sys.com> 1AC7 1DB0 FEA6 93C2 6731 0AB1 07BA B3C7 458E E234From: EZ <papaz_at_md.prestige.net> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 13:52:24 -0400
Edmund Zynda II
> -- 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.From: ipv6 <ipv6_at_311c.com> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 13:40:45 -0600
> Same here...a copy would be great! -- 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.From: Jon Crowley <jonathan_at_mitre.org> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 13:02:20 -0400
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
-- 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.From: Frank Mayer <mayerf_at_tresys.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 14:09:14 -0400
We have very similar thoughts, though our goal is to define a building block policy configuration for SE Linux and then methods for building upon that building block for a variety of applications. The analysis tool is a by-product.
> However, our take on checkpolicy is that it is intended
We looked quickly at checkpolicy and came to the same conclusion, i.e., that
it
I will also say that our analysis policy structure is quick and dirty
without
-- 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.From: Stephen Smalley <sds_at_tislabs.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 15:32:25 -0400 (EDT)
On Wed, 10 Oct 2001, Frank Mayer wrote:
>We looked quickly at checkpolicy and came to the same conclusion, i.e., that So perhaps checkpolicy needs to be revised to generate an intermediate set of data structures that are more suitable for policy analysis tools prior to generating the final set of data structures for the kernel security server? -- Stephen D. Smalley, NAI Labs ssmalley@nai.com -- 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.From: Frank Mayer <mayerf_at_tresys.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 16:11:31 -0400
You can download the tar file at http://www.tresys.com/selinux.html Frank -- 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.From: Frank Mayer <mayerf_at_tresys.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 17:11:02 -0400
My apologies, the file that was posted recently was not the correct file. The one at the site now has been update. There really isn't much difference, just some minor changes that removed some (not all!) warnings when -Wall is used. Frank -- 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.From: Frank Mayer <mayerf_at_tresys.com> subject: RE: Security policy analysis Date: Wed, 10 Oct 2001 16:11:32 -0400
I think what Steve says is all reasonable and like I mentioned before, it wouldn't be hard to put what we have into checkpolicy even with two different policy DBs. Like I said, we really didn't set out to build a tool, but to analyze policies and so what we have can be viewed as a rapid prototype that we will likely continue to add to. Frank -- 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: Security policy analysis Date: Wed, 10 Oct 2001 15:04:53 -0400 (EDT)
On Wed, 10 Oct 2001, Jon Crowley wrote:
> Steve also suggested incorporating these functions into checkpolicy. The -d option to the checkpolicy progam can be used to determine how the security server would respond if it were using the policy without actually loading the policy into the kernel security server. Currently, it simply allows you to exercise the security server functions, which are essentially primitive queries on the policy. I don't see why you wouldn't want to add additional support for more complex queries to it. Creating separate tools (with their own code and data structures) will make maintenance harder and increase the likelihood that the policy analysis tools will have a different interpretation of the policy than the security server.
> The problem with building a separate tool is that both tools will share This could be done, but it isn't necessary if you merge your tools into checkpolicy. -- Stephen D. Smalley, NAI Labs ssmalley@nai.com -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |