Security policy analysis

Security policy analysis

[Frank Mayer]

We're looking at SE Linux as a building block upon which we can build
protected applications of various types.  One of the issues we are working
through include identifying a core "baseline" Linux configuration and
associated SE Linux policy for that baseline.  One means of doing this is to
examine sample policies (like the one distributed with the source).  If
anyone else is doing similar things, we'd like to like to hear more.  Also,
is anyone else working on alternative sample policies, especially for a core
Linux configuration?

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,
Frank Mayer
mayerf@tresys.com
Tresys Technology



--
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.

RE: Security policy analysis

[John Scroggins]

We're looking at SE Linux as a building block upon which we can build
protected applications of various types.  One of the issues we are working
through include identifying a core "baseline" Linux configuration and
associated SE Linux policy for that baseline.  One means of doing this is to
examine sample policies (like the one distributed with the source).  If
anyone else is doing similar things, we'd like to like to hear more.  Also,
is anyone else working on alternative sample policies, especially for a core
Linux configuration?

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,
Frank Mayer
mayerf@tresys.com
Tresys Technology



--
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.

Interested in Reserach work

[Ravi Prakash B.V.]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

Dear all,

I joined into this group today.
I am interested to do the research work in  security area. I want to
contribute my research work to this group.
I would like to know the current active work in the group so that i can
join and start work in  one of it.

Thanks & Regards,
Ravi Prakash B.V.

[-- Attachment #2: Card for Ravi Prakash B.V. --]
[-- Type: text/x-vcard, Size: 446 bytes --]

begin:vcard 
n:Venkata Ravi Prakash;Burlagadda
tel;cell:98490 30284
tel;home:08644 26681
tel;work:040 6328079(direct) 040 7814515/17/19 extn:387
x-mozilla-html:FALSE
org:Tata Consultancy Services;Advanced Technology Centre
version:2.1
email;internet:ravi@atc.tcs.co.in
title:ASE
adr;quoted-printable:;;1-2-10, Coramandel House,=0D=0ASardar Patel Road;Secunderabad;AP;500003;India
x-mozilla-cpt:;28992
fn:Burlagadda Venkata Ravi Prakash
end:vcard

Re: Security policy analysis

[Stephen Smalley]

On Tue, 9 Oct 2001, Frank Mayer wrote:

> 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.

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.

Re: Security policy analysis

[ipv6]

>
> On Tue, 9 Oct 2001, Frank Mayer wrote:
>
> > 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.

> We're interested in the capabilities that you've developed.  Can we
> acquire a copy?

We would also like to get a copy if that is possible?

Joop Cousteau
CTO
ImageSave Corp



--
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.

RE: Security policy analysis

[Frank Mayer]

I will post a site where the current source can be downloaded within a day
or two.

However, I still encourage folks who are looking at developing or analyzing
security policies to share any insights you might have.  Thanks

Frank Mayer
mayerf@tresys.com
Tresys Technology


--
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.

Re: Security policy analysis

[Julien Palardy]

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 E234


> I will post a site where the current source can be downloaded within a day
> or two.
>
> However, I still encourage folks who are looking at developing or
analyzing
> security policies to share any insights you might have.  Thanks
>
> Frank Mayer
> mayerf@tresys.com
> Tresys Technology
>



--
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.

Re: Security policy analysis

[EZ]

Same here...a copy would be great!

Edmund Zynda II

----- Original Message -----
From: "ipv6" <ipv6@311c.com>
To: "Stephen Smalley" <sds@tislabs.com>; "Frank Mayer" <mayerf@tresys.com>
Cc: <SELinux@tycho.nsa.gov>
Sent: Wednesday, October 10, 2001 10:23 AM
Subject: Re: Security policy analysis


>
>
>
> >
> > On Tue, 9 Oct 2001, Frank Mayer wrote:
> >
> > > 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.
>
> > We're interested in the capabilities that you've developed.  Can we
> > acquire a copy?
>
> We would also like to get a copy if that is possible?
>
> Joop Cousteau
> CTO
> ImageSave Corp
>
>
>
> --
> 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.

Re: Security policy analysis

[ipv6]

OK !!!! We all agree - please send a copy !
This is a Great Group of people !



----- Original Message -----
From: "EZ" <papaz@md.prestige.net>
To: "ipv6" <ipv6@311c.com>; "Stephen Smalley" <sds@tislabs.com>; "Frank
Mayer" <mayerf@tresys.com>
Cc: <SELinux@tycho.nsa.gov>
Sent: Wednesday, October 10, 2001 11:52
Subject: Re: Security policy analysis


> Same here...a copy would be great!
>
> Edmund Zynda II
>
> ----- Original Message -----
> From: "ipv6" <ipv6@311c.com>
> To: "Stephen Smalley" <sds@tislabs.com>; "Frank Mayer" <mayerf@tresys.com>
> Cc: <SELinux@tycho.nsa.gov>
> Sent: Wednesday, October 10, 2001 10:23 AM
> Subject: Re: Security policy analysis
>
>
> >
> >
> >
> > >
> > > On Tue, 9 Oct 2001, Frank Mayer wrote:
> > >
> > > > 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.
> >
> > > We're interested in the capabilities that you've developed.  Can we
> > > acquire a copy?
> >
> > We would also like to get a copy if that is possible?
> >
> > Joop Cousteau
> > CTO
> > ImageSave Corp
> >
> >
> >
> > --
> > 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.
>



--
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.

Re: Security policy analysis

[Jon Crowley]

> 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:

1. List the process transitions for type "T"
2. List the file transitions for type "T"
3. List the type enforcement entries for type "T"
4. List all roles for type "T"
5. List all roles to which role "R" can transition
6. List all roles that can transition to role "R"
7. List all types with permission "P" in class "C" to type "T"
8. List all types with attribute "A".
9. List contexts with attribute "A".  
10. Which policy rule is blocking a particular permission "P" between
two contexts "C1" and "C2"?
11. Trace how a process in context C1 gains access (as a set of one or
more permissions) to an object with context C2.
12. Which file does rule "R" come from? (And where in that file is it?) 
13. List all equivalent types in the policy. Already done in
checkpolicy.c, but may need refinement.
14. Show the difference(s) between type "T1" and "T2" in the policy.
15. Identify types that are within some "delta" of each other in the
policy.  Useful for identifying possibly redundant types.
16. List all process types reachable from type "T" and show the path to
them.
17. List all object types to which data of type "T" can flow and show
the path to them.
18. Graph (or describe) all paths by which data might flow from type
"T1" to type "T2"

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.

RE: Security policy analysis

[Frank Mayer]

> From: root@smtpsrv1.mitre.org [mailto:root@smtpsrv1.mitre.org]On Behalf
> Of Jon Crowley
> Sent: Wednesday, October 10, 2001 1:02 PM
>
> We intend on developing functions to do the following first:
>
> <list deleted>

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
> 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?

We looked quickly at checkpolicy and came to the same conclusion, i.e., that
it
compiles policies for a different reason and has a policy DB not suited for
our purpose.  That's not a strong opinion.  We're also just incrementally
building quick tools and creating our own database format was simpler.  The
only code we're currently using from checkpolicy is the lex code, the yacc
framework and parser (though all the semantic logic is new), and the
associated queue.c. However, it is conceptually simple to integrate our
logic into checkpolicy
if we wanted to.  Essentially we would just add our logic to the functions
already in policy_parse.y, with changes to the main() function in
checkpolicy.c
for our menu items plus a few other housekeeping items.

I will also say that our analysis policy structure is quick and dirty
without
much effort spent on performance issues like sorted insertions and searches.
It
hasn't been any issue since once we digest the policy and build the policy
DB,
everything else is fast enough (we don't have the burden of building a
kernel
database like checkpolicy does!)



--
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.

RE: Security policy analysis

[Stephen Smalley]

On Wed, 10 Oct 2001, Frank Mayer wrote:

>We looked quickly at checkpolicy and came to the same conclusion, i.e., that
>it compiles policies for a different reason and has a policy DB not
>suited for our purpose.  That's not a strong opinion.

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.

RE: Security policy analysis

[Frank Mayer]

Ok, we've made our source available.  First let me lower expectations.  This
is a small, quickly built tool with limited and evolving capabilities that I
wrote only as a by-product of our real effort.  From the messages I've read
today, too many people seem to be reading too much into all of this.  Also,
someone asked about license.  We just quickly put this under a GNU GPL and
added the appropriate (C) statements, primarily to give us the liability
protection.

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.

RE: Security policy analysis

[Frank Mayer]

> You can download the tar file at http://www.tresys.com/selinux.html

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.

RE: Security policy analysis

[Frank Mayer]

> 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?

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.

Re: Security policy analysis

[Stephen Smalley]

On Wed, 10 Oct 2001, Jon Crowley wrote:

> 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 -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
> 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.

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.