Problems loading policy

Problems loading policy

[Stephen]

Hi
I'm getting the follwing error when I try and load my selinux policy
load_policy /etc/security/selinux/policy.15 (or policy.12 - whats the
diference?)
security_load_policy: Function not implemented

Im using the selinux-policy-default and selinux packages from cocker.com.au.
The packages installed fine and ran make relabel etc fine
Running checkpolicy
checkpolicy:  loading policy configuration from policy.conf
security:  5 users, 5 roles, 1049 types
security:  29 classes, 119120 rules
checkpolicy:  policy configuration loaded

I have compiled my kernel with ROMFS, capabilities and SELinux. Here is my
kernel dmesg
Security Scaffold v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security:  Registering secondary module capability
Capability LSM initialized


apt-get install cramfsprogs initrd-tools genromfs

Created a /etc/mkinitrd/mkinitrd.conf file with this in it
MKIMAGE='genromfs -d %s -f %s > /dev/null'

I have created a initrd file "cd /boot ; mkinitrd -o initrd.img-2.4.22
/lib/modules/2.4.22"
In /etc/lilo.conf I have added initrd=/boot/initrd.img-2.4.22 under the
relevant image section
"mkdir /selinux" and add line to /etc/fstab
none /selinux selinuxfs defaults 0 0

But when I try and load the policy it fails
root@anskiere:/etc/selinux# make load
/usr/sbin/load_policy /etc/security/selinux/policy.12
security_load_policy: Function not implemented
make: *** [reload] Error 2

Any ideas?

Thanks
Stephen

--
This message was distributed to subscribers of the selinux mailing 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: Problems loading policy

[Dale Amon]

On Sat, Dec 06, 2003 at 01:57:47AM +1100, Stephen wrote:
> I have compiled my kernel with ROMFS, capabilities and SELinux. Here is my
> kernel dmesg

You haven't actually given the info showing whether
the initrd loaded or not.

One item to be wary of though. Make sure cramfs is
deselected in the kernel build if you are using romfs.
For some reason initrd will try cramfs first and not
even look at romfs in that case.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

--
This message was distributed to subscribers of the selinux mailing 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.

Information flow models

[John D. Ramsdell]

Karl MacMillan of Tresys and I were having a discussion about
information flow models used for policy analysis, and thought the
people on this list might like to participate.

The Tresys Setools package and MITRE's SLAT analyze SELinux policy
configurations.  They both extract an abstraction of a policy that
models information flow within the system.  Both models can be
described in terms of graphs.  The nodes of the graph say something
about a security context.  Each edge in the graph is labeled with a
control requirement, i.e. a class-permission pair.  An edge is in the
graph if the policy allows information to flow from one node to
another.  If the edge corresponds to a write-like flow, the source of
the edge is the subject, and if the edge corresponds to a read-like
flow, the target of the edge is the subject.

The two tools differ in what constitutes a node in the model.  In
SLAT, a node is a security context--a triple consisting of a type, a
role, and a user.  In Setools, a node is a type.

Using a security context as a node gives a model that more accurately
reflects the policy being analyzed, however, the graphs are large.  As
a result, the SLAT implementors have had to resort to model checkers
to perform their analysis.

If one ignores role-allow, role-type, user-role, and constraint
statements in a policy configuration file, one is left with a model in
which nodes can simply be types.  The graphs in this model are
obviously much smaller and easier to analyze, however, it may allow
some flows that are not permitted by a more fine grained analysis.
The question is: from an engineering perspective, is a more detailed
analysis worth the overhead of using techniques that handle the large
graphs?  Most likely, there will be times when an analysis based only
on types is appropriate, and others when an analysis based on security
contexts is appropriate, but how does one decide which to use, and when?

John





--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Fri, 2003-12-05 at 15:32, John D. Ramsdell wrote:
> Karl MacMillan of Tresys and I were having a discussion about
> information flow models used for policy analysis, and thought the
> people on this list might like to participate.
> 

Thanks for sending this John. I think this is an interesting area and am
very glad to give it some public discussions.

> The Tresys Setools package and MITRE's SLAT analyze SELinux policy
> configurations.  They both extract an abstraction of a policy that
> models information flow within the system.  Both models can be
> described in terms of graphs.  The nodes of the graph say something
> about a security context.  Each edge in the graph is labeled with a
> control requirement, i.e. a class-permission pair.  An edge is in the
> graph if the policy allows information to flow from one node to
> another.  If the edge corresponds to a write-like flow, the source of
> the edge is the subject, and if the edge corresponds to a read-like
> flow, the target of the edge is the subject.
> 
> The two tools differ in what constitutes a node in the model.  In
> SLAT, a node is a security context--a triple consisting of a type, a
> role, and a user.  In Setools, a node is a type.
> 

This description of setools information flow is no longer accurate (not
that you would know that since it does reflect the currently released
version). In the soon to be released version nodes represent either a
type used as a source or a type / object class pair used as a target. It
is necessary to use this representation so that there is a transitive
relation between nodes in the graph (i.e. so that if there is a flow
A->B and a flow B->C there is a flow A->C). If the nodes simply
represent types (or possible contexts) this transitive relation doesn't
hold. Some examples might help. Take this policy snippet (these are the
only rules in the policy):

allow a_t b_t : blk_file { read };
allow c_t b_t : tcp_socket { write };

If nodes represent types, then the graph might look like this:

[a_t]<-[b_t]<-[c_t]

Obviously the "<-" represents an edge. If you follow the edges it
appears there is a flow between a_t and c_t when in fact there isn't.
The new version would generate a graph that looks like this:

[a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]

Clearly no flow between a_t and c_t. This demonstrates why the object
class information must be present in the nodes. There are also problems
if you don't separate the types used as source from those used as
target. One more example:

allow b_t a_t : blk_file { read };
allow c_t b_t : blk_file { read };

If nodes represent types, then the graph might look like this:

[c_t]<-[b_t]<-[a_t]

Again, this implies a flow that doesn't exist (between c_t and a_t). The
new version generates a graph that looks like this:

[b_t]<-[a_t:blk_file] [c_t]<-[b_t:blk_file]

This correctly reflects that there are no flow between a_t and c_t.

I have no idea how slat handles these problems (or even if it does). I
tried to empirically test these examples with slat, but couldn't get
things working in the time I had to devote to this.

> Using a security context as a node gives a model that more accurately
> reflects the policy being analyzed,

I'm not convinced that the information gained is useful or important in
the context of information flow. I could definitely be wrong, but so far
I haven't come up with a situation where the full context is needed.
Could you elaborate? Do you have any examples of situations in real
policies where the full context prevented a false positive?

> however, the graphs are large.  As
> a result, the SLAT implementors have had to resort to model checkers
> to perform their analysis.
> 

First, how large are the graphs? I have large policies that create
graphs with over 8,000 nodes that our system handles easily (analysis
takes less than 5 seconds).

Model checkers might be a valid way to solve these problems, but I doubt
that the graphs are large enough that standard graph algorithms fail. It
seems to me if the graph representation is carefully constructed
checking for a flow is a simple test of connectivity that can be
accomplished with a standard search algorithm. Trusted types and paths
can be handled by removing nodes or edges in the graph. If the standard
searches are too slow it should be possible to use disjoint sets. I have
used disjoint sets to do connectivity testing on very large graphs in
the past (tens of thousands of nodes with millions of edges).

> If one ignores role-allow, role-type, user-role, and constraint
> statements in a policy configuration file, one is left with a model in
> which nodes can simply be types.  The graphs in this model are
> obviously much smaller and easier to analyze, however, it may allow
> some flows that are not permitted by a more fine grained analysis.
> The question is: from an engineering perspective, is a more detailed
> analysis worth the overhead of using techniques that handle the large
> graphs?  Most likely, there will be times when an analysis based only
> on types is appropriate, and others when an analysis based on security
> contexts is appropriate, but how does one decide which to use, and when?
> 

I definitely would like to explore these questions. Like I said above, I
can't come up with any compelling reasons to include the context, but I
haven't put much thought into the problem. Since it seems that you have
spent more time on this, could you give some more detail?

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[John D. Ramsdell]

Karl MacMillan <kmacmillan@tresys.com> writes:

> In the soon to be released version nodes represent either a
> type used as a source or a type / object class pair used as a
> target. 

...

> The new version would generate a graph that looks like this:
> 
> [a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]

I'm afraid I am unable to understand the model of information flow you
describe.  I expected a permission would be a part of what is used to
label either an edge or a node, but no such label appears.

The mls file I'm currently using states that system calls that must
meet the file getattr control requirement have read-like flow, and the
ones that meet the file setattr control requirement have write-like
flow.  System calls that must meet file relabelfrom have information
flow in both direction, and the ones that meet file lock have no flow
as a result of this requirement.

How does your representation handle information flow caused by system
calls that must meet the file setattr control requirement?

Additionally, please expand on the discussion on transitivity.  I
could not see why you changed away from nodes as types, and edges
labeled with a control requirement.  What was the motivation for the
change?

> I have no idea how slat handles these problems (or even if it does). I
> tried to empirically test these examples with slat, but couldn't get
> things working in the time I had to devote to this.

If you send me specific questions with transcripts, I'll help you get
slat running.  Be sure to include a description of the platform on
which you are running slat.  As a first pass, I recommend running on a
version of Linux that does not have SELinux enabled so you don't have
to worry about policy violations.  Model checking goes faster if you
have a machine with muscle.

> > Using a security context as a node gives a model that more accurately
> > reflects the policy being analyzed,
> 
> I'm not convinced that the information gained is useful or important in
> the context of information flow.

We need to agree on what is meant by information flow before this
discussion is useful, so I'll get back to you on this one.

> First, how large are the graphs? I have large policies that create
> graphs with over 8,000 nodes that our system handles easily
> (analysis takes less than 5 seconds).
>
> Model checkers might be a valid way to solve these problems, but I
> doubt that the graphs are large enough that standard graph
> algorithms fail.

We use a model checker because our security goals make assertions
about all possible paths through the information flow graph.  Using
graph traversal algorithms to perform the same checks would require the
enumeration of every path in the flow graph.  Furthermore, many paths
are infinite, so one would have to handle loops.

John

--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Wed, 2003-12-10 at 08:18, John D. Ramsdell wrote:

> I'm afraid I am unable to understand the model of information flow you
> describe.  I expected a permission would be a part of what is used to
> label either an edge or a node, but no such label appears.
> 

Permissions determine whether an edge exists. 

> How does your representation handle information flow caused by system
> calls that must meet the file setattr control requirement?
> 

All of this is explained in our documentation and can be explored by
using the tool. The quick answer is that we provide an editor that
allows you to map permissions on object classes to read, write, or no
flows. The MLS file is a good starting point, but our experience with
information flow analysis has shown that more flexibility is needed.

> Additionally, please expand on the discussion on transitivity.  I
> could not see why you changed away from nodes as types, and edges
> labeled with a control requirement.  What was the motivation for the
> change?
> 

To make it possible to perform transitive closure or other types of
reachability analysis efficiently.

> We need to agree on what is meant by information flow before this
> discussion is useful, so I'll get back to you on this one.
> 

Our documentation has an extensive discussion on how we define
information flow in terms of SELinux policies.

> We use a model checker because our security goals make assertions
> about all possible paths through the information flow graph.  Using
> graph traversal algorithms to perform the same checks would require the
> enumeration of every path in the flow graph.  Furthermore, many paths
> are infinite, so one would have to handle loops.
> 

This is not the case - there is no reason to examine all paths in a
graph to determine whether a flow exists if the graph is carefully
constructed. The bottom line is that none of this is any different from
what network routers do every day and they certainly aren't examining
all paths through a network. Instead, they use algorithms very similar
to the ones that I am using.

Karl

> John
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[John D. Ramsdell]

Karl MacMillan <kmacmillan@tresys.com> writes:

> All of this is explained in our documentation and can be explored by
> using the tool.

Your previous note started by saying you've changed your
representation of flow information.  Didn't you say the change is not
reflected in the current version of the software?

John

--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Wed, 2003-12-10 at 10:29, John D. Ramsdell wrote:
> Karl MacMillan <kmacmillan@tresys.com> writes:
> 
> > All of this is explained in our documentation and can be explored by
> > using the tool.
> 
> Your previous note started by saying you've changed your
> representation of flow information.  Didn't you say the change is not
> reflected in the current version of the software?
> 

All of the documentation and implementation of the permission maps
(which is what you are asking about) is the same. What nodes represent
doesn't change how we interpret object class permissions in terms of
read and write. Additionally, all of the high level descriptions about
information flow in our documentation is still accurate - all of our
discussion is just implementation details.

Karl

> John
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Joshua D. Guttman]

Hi Karl --

John showed me the email exchange, but I didn't understand what your
arrows actually mean.  Since I don't have a machine with a copy of
your software installed, could I possibly ask you please to post the
relevant part of the documentation to this list, preferably cc:ing me?

Thanks so much --

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org>
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Fax:	+1 781 271 8953
	Bedford, MA 01730-1420 USA	Cell:	+1 781 526 5713



--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Wed, 2003-12-10 at 14:06, Joshua D. Guttman wrote:
> Hi Karl --
> 
> John showed me the email exchange, but I didn't understand what your
> arrows actually mean.  

The arrows are directed edges (arcs if you prefer). They mean that there
was 1 or more allow rules that defined an information flow between the
nodes.

> Since I don't have a machine with a copy of
> your software installed, could I possibly ask you please to post the
> relevant part of the documentation to this list, preferably cc:ing me?
> 

Here is the documentation - it is user level documentation and doesn't
discuss the implementation at all.

Karl

AN OVERVIEW OF INFORMATION FLOW ANALYSIS
apol, version 1.0
September 22, 2003
selinux@tresys.com


Apol now supports a limited and highly experimental ability to automate 
the search for overt information flows between two types.  The purpose 
of this analysis is to identify undesirable or unexpected flows of 
information allowed by a type enforcement (TE) policy.  For example, 
imagine that the type shadow_t is assigned to the shadow password file 
/etc/shadow. You might be interested to know all the types to which 
information can flow from the shadow_t type (e.g, indicating possible 
paths for encrypted passwords to be unintentionally leaked). In this 
case you would do a "flow from" analysis on the shadow_t type. Another 
example might be a firewall application where your intent is to
understand 
all flows allowed between two network interfaces.

Information flow analysis in SELinux is challenging for several reasons,
including:

  + The TE policy mechanism is extremely flexible, allowing for good and
    bad flows to be easily specified, not necessarily as part of the 
    policy writer's intent.
    
  + TE policies tend to be complex, with possibly tens of thousands of 
    rules and hundreds of types, making it difficult for a policy
    writer to know all that is allowed.
  
  + SELinux currently supports 30 object classes and 122 object 
    permissions, each of which must be examined with their ability to 
    allow information flow from/to its associated object class.
    
In the remainder of this file we provide an overview on how apol 
performs information flow analysis.


WHAT IS OVERT INFORMATION FLOW IN SELINUX?

Information flow is defined in terms of access allowed (not necessarily 
whether that access is actually used).  In SELinux, all objects and 
subjects have an associated type.  Generally speaking, subjects can read
or write objects, and thereby cause information to flow into and out of 
objects, and into and out of themselves.  For example, suppose you had
two 
types (say subject_t and object_t), and you had a subject (with 
subject_t type) able to read, but not write an object (with object_t 
type), then a rule that would allow this access might look like the 
following:

	allow subject_t object_t : {file link_file} read;

In this case, you would have the following direct information flows for 
the types subject_t and object_t:

	subject_t: FROM object_t
	
	object_t:  TO subject_t
	
If this were the only rule relating to these two types, then there would
be no other direct information flows from or to either.

Notice that an information flow can only occur when a subject is 
involved; you cannot have a flow directly between two objects since a 
subject is required to cause action.  In SELinux, processes are 
generally the subject.  There are currently 30 object classes (including
processes, which are both subjects and objects).

In apol, the subject is easy to recognize; any type that is used in the 
'source' field of an allow rule is presumed to be associated with a 
subject (usually as the domain type of some process).  The object type 
is the type used in the 'target' field of an allow rule.  

In the case of objects, the allow rule also explicitly identifies the 
object classes for which the rule applies.  This fact results in a 
complication for analyzing information flows; specifically that flows 
between types are restricted by object classes.  A flow between types 
is typically not allowed for all object classes, but for only those 
classes identified.  So to be more precise, the direct information flows
allowed by the object rules for object_t in the example above are:

	object_t [file, link_file]:  TO subject_t 
	
   NOTE: Apol currently assumes that 'source' types are associated with 
   process objects and reports flows for source types with the process 
   object class.  So again with the above rule, the more precise 
   statement of flows for subject_t and object_t are:

	subject_t [process]:  FROM object_t [file, link_file]
	object_t [file, link_file]:   TO subject_t [process]
	
Currently in apol, the implicit subject-process relationship is not
reported, and all places where the results show an object class, the 
class refers to the target object class.  
	
Finally, notice the perspective difference between source (subject) 
types and target (object) types.  A read permission between a source 
type and a target type is a flow out of the target (which is being read)
and flow into the source (which, being a process, is receiving the data 
being read into its memory).


OBJECT PERMISSION MAPPINGS

Notice in the above examples we used 'read' permission, but described 
flows as 'in' or 'out' or 'from' and 'to'.  In general for information 
flow analysis, the only access between subjects and objects that are of 
interest, are read and write.  Remembering the perspective difference 
mentioned above, read and write access results in the following flow for
subjects (sources) and objects (targets):

	SUBJECT: READ:  IN flow
	         WRITE: OUT flow
	          
	OBJECT:  READ:  OUT flow
	         WRITE: IN flow
	        
   NOTE: Remember that a process can be either a subject or an object.
So 
   when the process object class is specified in the allow rule, then 
   the target type is associated with process object class and the 
   object flow rules apply.
	
While read and write access are the only access rights of interest for 
an information flow analysis, that does not mean that 'read' and 'write'
permissions are the only SELinux permissions of interest.  The name of a
permission does not necessarily imply whether it allows read or write 
access.  Indeed we need to map all defined permissions for all object 
classes to read and write access in order to perform an information flow
analysis.

This mapping can be a difficult chore, and certainly requires extensive 
understanding of the access allowed by each of the 122 permissions 
currently defined.  For example, the file object class has the 'getattr'
permission defined which allows the ability to determine information 
about a file (such as date created and size).  One could consider this a
read access since the subject is reading information about the file. 
Then again this begins to feel like COVERT information flow analysis, 
where one is concerned about illicit signaling of information through 
non-traditional means (e.g., signaling the critical data by varying the 
size of file is a covert flow, writing the data directly in the file so 
it can be read is an overt flow). This type of decision must be made for
each defined object permission for each defined object class.  

The permission mapping mechanism in apol allows each permission to be 
mapped to read, write, both, or none.  In addition, the tool attempts to
'fix' a permission map to fit the needs of the currently opened policy. 
So for example, if a permission map file does not map a set of 
permissions, or skips an entire object class, apol will label the 
missing permissions to "unmapped" and treat them as if they were mapped 
to 'none.'  Likewise if a map has permissions that are undefined in the 
current policy, it will ignore those mappings.  In this way apol 
continues its tradition of supporting old and new versions of policies 
(see below for more on managing permission maps).

The default SELinux policy provides an existing mapping for each 
permission used for the optional MLS access control feature (which 
enforces a strict, non-flexible form of overt information flow 
controls).  Most people do not use the MLS access control feature (nor 
does apol provide support to analyze the associated optional policy 
features).  However, you can use the policy 'mls' file to get at least a
starting permission map.  Under the Advanced menu, there is a tool that 
will allow you to take a policy mls file and convert it into the 
permission mapping file format required by apol.

As distributed, apol provides two default permission mappings (one based
on a sample policy for policy version 12, and one based on policy 
version 15).  These files are directly converted from the policy mls 
files.

   NOTE: It has often been noted on the mail list that the mls file is 
   not necessarily a perfect, or even good permission map.  In addition,
   a permission mapping good for MLS security may not necessarily be 
   good for type enforcement information flow analysis.  We leave it up 
   to others to create better permission maps. 
   
Apol provides mechanisms to allow you to manage and customize permission
mappings that best suit your needs.  These tools, including a 
permission map editor, are all available under the Advanced menu (see 
more on this topic below).


TYPES OF INFORMATION FLOW ANALYSIS

In the examples so far, we've only looked at 'direct' information flows.
Apol currently implements at least some aspects of both 'direct' and 
'transitive' information flow analyses.  While both analyses are 
experimental and likely have existing logic errors, the transitive 
analysis is much more complex and has many known limitations (that we 
note below).  Both analyses will improve in future versions.

As its name implies, direct information flow analysis examines a policy 
for information flows that are directly permitted by one or more allow 
rules.  In essence, every allow rule defines a direct information flow 
between the source and target types (for those allowed permissions that 
map to read, write, or both).  The direct information flow analysis 
automates the search for these direct flows.

Transitive information flow analysis attempts to link together a series 
of direct information flows to find an indirect path in which
information 
can flow between two types.  The results for a transitive closure will 
show one or more steps in the chain required for information to flow 
between the start and end types.  Currently, the results will only show 
one such path for each end type; specifically the shortest path.

As an example, examine the following rules:

	allow one_t two_t : file write;
	allow three_t two_t: file read;
	
If you were doing a direct flow analysis between one_t and three_t, you 
would not find any flows since no rule explicitly allows access between 
them.  However, there is a two-step flow that would allow flow between 
these two types, namely one_t writing information into a file type 
(two_t) that three_t can read.  These are the types of flows that the 
transitive analysis attempts to find.

For both analyses, the results are presented in a less-than-desirable 
tree form (a more natural form might be a graph presentation; presently 
we are not prepared for that type of investment into the GUI).   Each 
node in the tree represents a flow (in the direction selected) between 
the type of the parent node and the type of the node. The results window
will show details about the flow, including links to the rule(s) that 
allow the flow.

MANAGING PERMISSION MAPPINGS

The ability to directly manage permission maps is important for the 
following reasons: 

  + Permission maps are central to analyzing information flows, and the 
    correctness of the map has a direct influence on the value of the 
    results;
   
  + The mapping for individual permissions and object classes are 
    subjective, and changing permissions to alter the analysis might be 
    necessary (e.g., by unmapping certain object classes to remove them 
    from the analysis); and 
    
  + You might be trying to work with several different policies each 
    with different definitions of object classes and permissions.
    
    
Because of these reasons, apol was designed to provide great latitude in
managing permission mappings using the Advanced->Permission Mappings 
menus.  A user need not manage permission maps directly.  Apol is 
equipped with default permission maps (in /usr/lib/apol/) that 
will be loaded automatically when an information flow analysis is 
performed. 

With The Advanced menus, you can manually load a permission map from any
file location.  In this way you can keep several versions of permission 
map files around, and then load the one you want for the analysis you're
currently doing.  You can also take a 'mls' file and generate a 
permission map file.  In addition, you can manually load the default 
permission map (see below).

There are two ways to edit the mappings in a permission map : 1) edit a 
map file directly, or 2) use the permission map editor under the 
Advanced menu.  The editor will display all the object classes and 
permissions currently mapped (or unmapped) in the currently loaded 
policy.  Since apol will adapt a permission map file to meet the needs 
of a loaded policy, the loaded map may be different than the file on 
disk.  If you save the loaded map, the on-disk file will be changed to 
match the loaded map.

If you make changes to the default permission map, a copy will be made 
for you in $HOME/.apol_perm_mapping.  If .apol_perm_mapping exists, 
it will be used as your default.  Otherwise the system default from 
/usr/lib/apol will be used as the default.

   NOTE: Only one permission map may be loaded at a time, and only if a 
   policy.conf file is opened.  If you have performed an information 
   flow analysis, the default permission map will be loaded 
   automatically unless you previously manually loaded a permission map.
   Loading a new permission map will unload the current map. Closing the
   policy will also unload the map.

We expect permission map management to be a central part of complex 
information flow analysis.
		
		



> Thanks so much --
> 
>         Joshua 
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[John D. Ramsdell]

Karl MacMillan <kmacmillan@tresys.com> writes:

> The arrows are directed edges (arcs if you prefer). They mean that
> there was 1 or more allow rules that defined an information flow
> between the nodes.

and from a previous note:

> Obviously the "<-" represents an edge. If you follow the edges it
> appears there is a flow between a_t and c_t when in fact there isn't.
> The new version would generate a graph that looks like this:
>
> [a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]

You documentation states that flows occur between types, but your
graph has type class pairs as nodes, sometimes as a source and
sometimes as a destination.  What does it mean for information to
originate from b_t:blk_file?  What does it mean for information to get
to b_t:tcp_socket?

John

--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Thu, 2003-12-11 at 08:10, John D. Ramsdell wrote:
> Karl MacMillan <kmacmillan@tresys.com> writes:
> 
> > The arrows are directed edges (arcs if you prefer). They mean that
> > there was 1 or more allow rules that defined an information flow
> > between the nodes.
> 
> and from a previous note:
> 
> > Obviously the "<-" represents an edge. If you follow the edges it
> > appears there is a flow between a_t and c_t when in fact there isn't.
> > The new version would generate a graph that looks like this:
> >
> > [a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]
> 
> You documentation states that flows occur between types, but your
> graph has type class pairs as nodes, sometimes as a source and
> sometimes as a destination.  What does it mean for information to
> originate from b_t:blk_file?  What does it mean for information to get
> to b_t:tcp_socket?
> 

The nodes are simply more specific - if information flows between a_t
(as a source) and b_t (as a target associated with blk_file) it means
that there was a flow between a_t and b_t. My graph simply records more
of the specifics: that a_t was the source in the allow rule and b_t was
associated with a blk_file object class in the allow rule (the specific
permission is recored in the edge). There are a lot of details required
for a flow to be valid: i.e. one of the types must be in the source
field of the rule, one of the types must be in the target field, there
must be an associated object class, and the permission on the object
class must map to a read and/or write. My graph representation simply
reflects this. If you have nodes with only types (or type plus role and
user) you lose a lot of information that is required to determine if a
multi-step path is valid.

Karl 

> John
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Joshua D. Guttman]

Karl MacMillan <kmacmillan@tresys.com> writes:

>   There are a lot of details required
>   for a flow to be valid: i.e. one of the types must be in the source
>   field of the rule, one of the types must be in the target field, there
>   must be an associated object class, and the permission on the object
>   class must map to a read and/or write. My graph representation simply
>   reflects this. If you have nodes with only types (or type plus role and
>   user) you lose a lot of information that is required to determine if a
>   multi-step path is valid.

Valid?  Could you explain what you mean by valid?  

Thanks.

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org>
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Fax:	+1 781 271 8953
	Bedford, MA 01730-1420 USA	Cell:	+1 781 526 5713



--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Stephen Smalley]

On Mon, 2003-12-08 at 12:57, Karl MacMillan wrote:
> allow a_t b_t : blk_file { read };
> allow c_t b_t : tcp_socket { write };
> 
> If nodes represent types, then the graph might look like this:
> 
> [a_t]<-[b_t]<-[c_t]
> 
> Obviously the "<-" represents an edge. If you follow the edges it
> appears there is a flow between a_t and c_t when in fact there isn't.
> The new version would generate a graph that looks like this:
> 
> [a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]
> 
> Clearly no flow between a_t and c_t. This demonstrates why the object
> class information must be present in the nodes.

True in that example, although I wouldn't expect the same type to ever
be applied to both a blk_file and a tcp_socket.  But this approach
breaks down in the case where there is an implicit relationship between
objects of different classes, e.g. the labeling of /proc/pid files with
the domain of the corresponding process.  That yields a situation where:
	allow a_t b_t : file read;
	allow c_t b_t : process signal; # i.e. write
does produce an actual flow between a_t and c_t, because the b_t:file
can be the /proc/pid entries of a b_t process and contain information
about its signal state.

Note that the /proc/pid files should be the only files that are labeled
with domains.  At times, we have discussed the possibility of using a
derived type for each domain's /proc/pid entries, as we already do for
each domain's devpts entries, which would eliminate this overlap
completely.  Not clear if doing that is worthwhile.

> There are also problems
> if you don't separate the types used as source from those used as
> target. 
> One more example:
> 
> allow b_t a_t : blk_file { read };
> allow c_t b_t : blk_file { read };
> 
> If nodes represent types, then the graph might look like this:
> 
> [c_t]<-[b_t]<-[a_t]

As with the above, I wouldn't expect a process and a blk file to ever
have the same type.   A process and a /proc/pid file might have the same
type, but in that case, the above rules would create a flow.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Stephen Smalley]

On Thu, 2003-12-11 at 15:23, Stephen Smalley wrote:
> As with the above, I wouldn't expect a process and a blk file to ever
> have the same type.   A process and a /proc/pid file might have the same
> type, but in that case, the above rules would create a flow.

More generally, a type should identify a single equivalence class in the
security policy, so foo_t:process, foo_t:file, and foo_t:tcp_socket are
all part of the same equivalence class.  /proc/pid entries and sockets
fit this pattern, as they inherit the type of the associated process.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Karl MacMillan]

On Thu, 2003-12-11 at 15:23, Stephen Smalley wrote:

> > [a_t]<-[b_t:blk_file] [b_t:tcp_socket]<-[c_t]
> > 
> > Clearly no flow between a_t and c_t. This demonstrates why the object
> > class information must be present in the nodes.
> 
> True in that example, although I wouldn't expect the same type to ever
> be applied to both a blk_file and a tcp_socket.
>   But this approach
> breaks down in the case where there is an implicit relationship between
> objects of different classes, e.g. the labeling of /proc/pid files with
> the domain of the corresponding process.  That yields a situation where:
> 	allow a_t b_t : file read;
> 	allow c_t b_t : process signal; # i.e. write
> does produce an actual flow between a_t and c_t, because the b_t:file
> can be the /proc/pid entries of a b_t process and contain information
> about its signal state.
> 

Interesting. This seems like a special case to me - "implicit
relationship" seems to mean that the information is flowing to that proc
file outside of the control of the policy. Just to make certain that I
understand, am I correct that information can only flow to proc files in
this example? In other words, if there was a plain text file labeled b_t
no information could flow through it from c_t to a_t without another
rule:

allow b_t b_t : file write;

Are there any implicit relationships like this?

> Note that the /proc/pid files should be the only files that are labeled
> with domains.  At times, we have discussed the possibility of using a
> derived type for each domain's /proc/pid entries, as we already do for
> each domain's devpts entries, which would eliminate this overlap
> completely.  Not clear if doing that is worthwhile.
> 

I'm not certain if it is worth it either - we are looking for overt
flows and much of the information in proc would seem to be covert.

> > There are also problems
> > if you don't separate the types used as source from those used as
> > target. 
> > One more example:
> > 
> > allow b_t a_t : blk_file { read };
> > allow c_t b_t : blk_file { read };
> > 
> > If nodes represent types, then the graph might look like this:
> > 
> > [c_t]<-[b_t]<-[a_t]
> 
> As with the above, I wouldn't expect a process and a blk file to ever
> have the same type.   A process and a /proc/pid file might have the same
> type, but in that case, the above rules would create a flow.

I agree that this isn't a likely situation (we have yet to see this
false positive in a real policy), but one of the goals of automated
tools is to detect poorly written policies. However, both of these
strategies help prevent a false positive where it can appear that
information flows between 2 objects without a subject, which is a likely
situation.

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com
(410) 290-1411 x134


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Stephen Smalley]

On Thu, 2003-12-11 at 15:46, Karl MacMillan wrote:
> Interesting. This seems like a special case to me - "implicit
> relationship" seems to mean that the information is flowing to that proc
> file outside of the control of the policy. Just to make certain that I
> understand, am I correct that information can only flow to proc files in
> this example? In other words, if there was a plain text file labeled b_t
> no information could flow through it from c_t to a_t without another
> rule:
> 
> allow b_t b_t : file write;

Correct.

> Are there any implicit relationships like this?

Offhand, no, although I may be forgetting something.  Sockets
and System V IPC objects do inherit the type of the creating
process by default, but there are explicit allow rules authorizing the
creation and subsequent access.  devpts nodes are dynamically created by
the kernel in response to access to /dev/ptmx, so you never see an
explicit allow rule for the creation, but they do require explicit allow
rules for accessing them.

> I agree that this isn't a likely situation (we have yet to see this
> false positive in a real policy), but one of the goals of automated
> tools is to detect poorly written policies. However, both of these
> strategies help prevent a false positive where it can appear that
> information flows between 2 objects without a subject, which is a likely
> situation.

I'd view it as a bug in the policy if someone is trying to separate
based on the class (vs. using separate types).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing 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: Information flow models

[Trent Jaeger]

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

Hi,

Been meaning to discuss this for a while (although it may be stale now). 

The Gokyo tool we are working on at IBM Research for analyzing SELinux 
policies (see paper) uses only the type information.  I have not had a 
chance to read the Tresys docs yet, but I expect that the interpretation 
is similar. 

We do not do information flow analyses at this point, although it would be 
straighforward.  We test for the more conservative Biba integrity 
violations (find all low integrity flows into read/execute permissions of 
high integrity subject types) to find individual integrity issues.  We 
have then focused on supporting the resolution/management of these cases 
as our paper describes.  We have some more recent, more formal analyses 
that I am writing up. 
My intuition is that describing and managing policy at the information 
flow level will be too complex (although certainly worth examination -- 
and I may be proven incorrect).  Thus, we are focusing on simpler 
properties (Biba) and trying to determine how to resolve/manage conflicts. 
 This is similar in spirit to Clark-Wilson, but I don't expect that 
assurance will be practical, so we are examining other approaches.

In general, I expect we will always have a conflict between security goals 
and functionality goals that will need to be balanced.  The SELinux policy 
model provides the flexibility to make these 'balancing' decisions, but we 
have a ways to go to find acceptable approaches for the admins. 

Trent.

PS -- I am finally getting around to open source approval for Gokyo, so 
hopefully this will be available in the late winter, early spring.
----------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
jaegert@us.ibm.com
(914) 784-7225, FAX (914) 784-7595




ramsdell@mitre.org (John D. Ramsdell)
Sent by: owner-selinux@tycho.nsa.gov
12/05/2003 03:32 PM
 
        To:     "SE Linux" <selinux@tycho.nsa.gov>
        cc:     ramsdell@mitre.org
        Subject:        Information flow models


Karl MacMillan of Tresys and I were having a discussion about
information flow models used for policy analysis, and thought the
people on this list might like to participate.

The Tresys Setools package and MITRE's SLAT analyze SELinux policy
configurations.  They both extract an abstraction of a policy that
models information flow within the system.  Both models can be
described in terms of graphs.  The nodes of the graph say something
about a security context.  Each edge in the graph is labeled with a
control requirement, i.e. a class-permission pair.  An edge is in the
graph if the policy allows information to flow from one node to
another.  If the edge corresponds to a write-like flow, the source of
the edge is the subject, and if the edge corresponds to a read-like
flow, the target of the edge is the subject.

The two tools differ in what constitutes a node in the model.  In
SLAT, a node is a security context--a triple consisting of a type, a
role, and a user.  In Setools, a node is a type.

Using a security context as a node gives a model that more accurately
reflects the policy being analyzed, however, the graphs are large.  As
a result, the SLAT implementors have had to resort to model checkers
to perform their analysis.

If one ignores role-allow, role-type, user-role, and constraint
statements in a policy configuration file, one is left with a model in
which nodes can simply be types.  The graphs in this model are
obviously much smaller and easier to analyze, however, it may allow
some flows that are not permitted by a more fine grained analysis.
The question is: from an engineering perspective, is a more detailed
analysis worth the overhead of using techniques that handle the large
graphs?  Most likely, there will be times when an analysis based only
on types is appropriate, and others when an analysis based on security
contexts is appropriate, but how does one decide which to use, and when?

John





--
This message was distributed to subscribers of the selinux mailing 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.

[-- Attachment #2: Type: text/html, Size: 5837 bytes --]