Fedora Core 2 policy source

Fedora Core 2 policy source

[Kratzer, James R.]

Where are the source policy files for Fedora Core 2?  The source directory
"/etc/security/selinux/src/policy" appears to be missing from the install.
Thanks.

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

Fedora Core 2 setools RPM

[John D. Ramsdell]

I notice the RPM for setools fails to install libapol.a into /usr/lib,
and fails to install the header files needed to use the library into
/usr/include/libapol.  Is there is a setools-devel RPM I don't know
about?

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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Tue, 2004-06-15 at 19:26, John D. Ramsdell wrote:
> I notice the RPM for setools fails to install libapol.a into /usr/lib,
> and fails to install the header files needed to use the library into
> /usr/include/libapol.  Is there is a setools-devel RPM I don't know
> about?

Not AFAIK, but I agree it would be a good idea.  In fact, it would be
nice for there to be a libapol RPM with a shared apol library and a
libapol-devel RPM with a static library and headers for use by third
party tools separate from setools.
 
-- 
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: Fedora Core 2 setools RPM

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2004-06-15 at 19:26, John D. Ramsdell wrote:
>  
>
>>I notice the RPM for setools fails to install libapol.a into /usr/lib,
>>and fails to install the header files needed to use the library into
>>/usr/include/libapol.  Is there is a setools-devel RPM I don't know
>>about?
>>    
>>
>
>Not AFAIK, but I agree it would be a good idea.  In fact, it would be
>nice for there to be a libapol RPM with a shared apol library and a
>libapol-devel RPM with a static library and headers for use by third
>party tools separate from setools.
> 
>  
>
I attempted to do this a while ago but, it really needs to be separated 
out by tresys.

Dan

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

SE Linux enhanced strace for Fedora Core 2

[John D. Ramsdell]

I discovered the sources that make up the distribution of strace I
sent out earlier fail to compile in Fedora Core 2.  Recall that this
distribution builds a version of strace that optionally prints
the security context of some of a system call's arguments.  The
modified strace for Fedora Core 2 is available here:

http://simp.mitre.org/selinux

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: Fedora Core 2 setools RPM

[Karl MacMillan]

I am not aware of an setools-devel rpm that installs the include files and
libapol.a. I think at one point the setools rpms that Dan Walsh was making
for Redhat/Fedora installed these files, but the current rpms for Fedora do
not.

In general, we have not spent many resources addressing the use of libapol
outside of setools. Because of this, we haven't added a target to install
the headers and library. The simplest thing to do is to download our source
and work within the setools directory. Otherwise, it is easy to write an
install target if you want.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134 

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of John D. Ramsdell
> Sent: Tuesday, June 15, 2004 7:26 PM
> To: selinux@tycho.nsa.gov
> Subject: Fedora Core 2 setools RPM
> 
> I notice the RPM for setools fails to install libapol.a into /usr/lib,
> and fails to install the header files needed to use the library into
> /usr/include/libapol.  Is there is a setools-devel RPM I don't know
> about?
> 
> 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.


--
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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Thu, 2004-06-17 at 11:36, Karl MacMillan wrote:
> I am not aware of an setools-devel rpm that installs the include files and
> libapol.a. I think at one point the setools rpms that Dan Walsh was making
> for Redhat/Fedora installed these files, but the current rpms for Fedora do
> not.
> 
> In general, we have not spent many resources addressing the use of libapol
> outside of setools. Because of this, we haven't added a target to install
> the headers and library. The simplest thing to do is to download our source
> and work within the setools directory. Otherwise, it is easy to write an
> install target if you want.

I think it would be helpful for libapol to be available for third party
packages to encourage other people working on policy tools to re-use and
(if necessary) contribute extensions back to libapol rather than
reinventing the wheel each time.  I'd also think you would want both
shared and static libraries, and have most of the tools dynamically
linked against the shared library.

-- 
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: Fedora Core 2 setools RPM

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@epoch.ncsc.mil]
> 
> I think it would be helpful for libapol to be available for third party
> packages to encourage other people working on policy tools to re-use and
> (if necessary) contribute extensions back to libapol rather than
> reinventing the wheel each time.  I'd also think you would want both
> shared and static libraries, and have most of the tools dynamically
> linked against the shared library.
> 

Sure - like I said we just haven't put any energy into this. We would
certainly like to see people using our libraries as much as possible as they
provide a lot of functionality that has taken a long time to develop. We
will be putting an interim release out soon and will include the
installation of the include files and libraries (shared and static).

Karl

> --
> 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: Fedora Core 2 setools RPM

[John D. Ramsdell]

"Karl MacMillan" <kmacmillan@tresys.com> writes:

> ...  We will be putting an interim release out soon and will include
> the installation of the include files and libraries (shared and
> static).

Great news.  I would greatly appreciate it if the libapol API includes
access to CONSTRAIN statements in a policy file.  I strongly suspect
the API could then be used to provide slat all the information it
needs to analyze a policy.

I also noticed that it appears that none of the setools documentation
tells users that your flow analysis ignores CONSTRAIN statements in a
policy.  I think users should know this fact.

$ grep -i constrain */*.in
docs-src/apol_help_text.in:	You can use any regular expression to constrain the search. So 
$ 

--
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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Fri, 2004-06-18 at 09:00, John D. Ramsdell wrote:
> Great news.  I would greatly appreciate it if the libapol API includes
> access to CONSTRAIN statements in a policy file.  I strongly suspect
> the API could then be used to provide slat all the information it
> needs to analyze a policy.

I would think that this would be something you (John) could contribute
to libapol, as slat would be the first user of such information.

> I also noticed that it appears that none of the setools documentation
> tells users that your flow analysis ignores CONSTRAIN statements in a
> policy.  I think users should know this fact.

The apol information flow analysis is for flow among types; hence, it is
only natural for it to only consider the TE configuration.  As a flow
can only exist if allowed by the TE configuration, analysis of the TE
configuration is sufficient to identify all flows.  We've discussed that
issue previously.

-- 
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: Fedora Core 2 setools RPM

[Joshua D. Guttman]

Stephen Smalley <sds@epoch.ncsc.mil> writes:

>   > I also noticed that it appears that none of the setools documentation
>   > tells users that your flow analysis ignores CONSTRAIN statements in a
>   > policy.  I think users should know this fact.
>   
>   The apol information flow analysis is for flow among types; hence,
>   it is only natural for it to only consider the TE configuration.
>   As a flow can only exist if allowed by the TE configuration,
>   analysis of the TE configuration is sufficient to identify all
>   flows.

May I raise a small question here?  

I can see that analysis of the TE configuration is sufficient to
identify a set of flows that includes all the possible flows among
security contexts.  But if one wants more exact information about the
set of flows among security contexts that are permitted by a
particular configuration, wouldn't one need to consider any
constraints?  

I take it that "flow among types" is a bit less precise than "flow
among security contexts".  Presumably there's flow from t_1 to t_2 if
there exist any u_1,r_1 and u_2,r_2 such that there's flow 

        u_1:r_1:t_1 --> u_2:r_2:t_2.  

Is this an accurate interpretation?

I think it would be great if libapol became a common access point for
many analysis methods to get information about the facts of the
configuration.  This should be easier if we have an agreement on all
the info that could be relevant.  

        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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Fri, 2004-06-18 at 13:26, Joshua D. Guttman wrote:
> I can see that analysis of the TE configuration is sufficient to
> identify a set of flows that includes all the possible flows among
> security contexts.  But if one wants more exact information about the
> set of flows among security contexts that are permitted by a
> particular configuration, wouldn't one need to consider any
> constraints?  

User identity and role seem largely irrelevant when it comes to
analyzing information flow in the system; that is essentially controlled
by the TE policy (and if MLS were enabled, by their combination).  At
most, I would incorporate constraints and other factors (e.g. role allow
rules) as a refinement _after_ determining the set of flows based on
types; constructing a complete graph among entire security contexts
seems costly and unnecessary.  And I don't think you want user identity
in the picture at all, as it just adds noise.

> I take it that "flow among types" is a bit less precise than "flow
> among security contexts".  Presumably there's flow from t_1 to t_2 if
> there exist any u_1,r_1 and u_2,r_2 such that there's flow 
> 
>         u_1:r_1:t_1 --> u_2:r_2:t_2.  
> 
> Is this an accurate interpretation?

If there is a flow from t_1 to t_2 in the TE policy, but no
corresponding flow among contexts that include t_1 and t_2 in the
policy, then that is likely a bug in the policy.

-- 
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: Fedora Core 2 setools RPM

[Joshua D. Guttman]

Stephen Smalley <sds@epoch.ncsc.mil> writes:

>   
>   > I take it that "flow among types" is a bit less precise than
>   > "flow among security contexts".  Presumably there's flow from
>   > t_1 to t_2 if there exist any u_1,r_1 and u_2,r_2 such that
>   > there's flow
>   > 
>   >         u_1:r_1:t_1 --> u_2:r_2:t_2.  
>   > 
>   > Is this an accurate interpretation?
>   
>   If there is a flow from t_1 to t_2 in the TE policy, but no
>   corresponding flow among contexts that include t_1 and t_2 in the
>   policy, then that is likely a bug in the policy.

Really?  Consider the case r_1=r_2, where the role-type relation
permits r_1 to execute with type t_1 but not with type t_2.  If the
arrow is created by an execve_secure, then isn't it important for the
policy to prevent this event?  

Whereas with some powerful role r_3, permitted to execute with types
t_1 and t_2, the event should be permitted.

Are you saying that you don't think policy analysis should be
sensitive to these questions?  (Ever?)

Or are you saying that you don't usually think of these events as
"information flow" relations?  If the latter, well OK, but maybe
that's mainly a verbal point.  There's certainly some causal
interaction here, and presumably policy analysis needs to be able to
talk about it using some terminology or other.

>   constructing a complete graph among entire security contexts seems
>   costly and unnecessary.

Well, yes, if you do it the obvious way by enumerating all the
(tupled) nodes and the arrows between them.  However, lots of model
checking work has invented representations under which conceptually
you're working with that big graph, although the representation is
vastly more compact because it's sensitive to uniformities in how the
components of the nodes are related.

I'm just trying to check that all the conceptually relevant info is
available somehow, if we get our data via libapol.

        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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Fri, 2004-06-18 at 14:18, Joshua D. Guttman wrote:
> Really?  Consider the case r_1=r_2, where the role-type relation
> permits r_1 to execute with type t_1 but not with type t_2.  If the
> arrow is created by an execve_secure, then isn't it important for the
> policy to prevent this event?  
> 
> Whereas with some powerful role r_3, permitted to execute with types
> t_1 and t_2, the event should be permitted.

A dangerous game, as I've noted previously.  If the TE configuration
allows a transition from t_1 to t_2, then even if r_1 is not allowed to
enter t_2 by the role-type relation, a r_1:t_1 process may be able to
influence a r_3:t_2 process due to the set of permissions granted
between t_1 and t_2 to support the r_3:t_1 -> r_3:t_2 transition and
subsequent operation.

A more realistic case is newrole.  user_t -> newrole_t -> sysadm_t is an
allowed series of domain transitions, and the only thing preventing
jdoe:user_r:user_t from using newrole to get to sysadm_t is the fact
that jdoe is restricted to user_r and user_r is restricted to user_t by
the kernel policy.  But from an information flow perspective, you simply
want to prove that user_t can only reach sysadm_t through specific gate
domains like newrole_t.

> Are you saying that you don't think policy analysis should be
> sensitive to these questions?  (Ever?)

At most, as a refinement of a basic analysis of the TE configuration. 

-- 
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: Fedora Core 2 setools RPM

[Joshua D. Guttman]

Steve --

So in some sense the bottom line is that you think the type relations
give the essential core of the policy info, and to a first
approximation one can focus on that.

Of course, it's still desirable to have access to the supplementary
information (and an idea how to interpret it) so that the further
refinement will eventually work out.  

A different point is that the main value added of slat is much more
expressive security goals (even when restricted to the types info).
You're not just talking about accessibility of a type to information
flow from another, but also whether all the possible flows go through
a desired gate type.  And the key fact you mentioned at the end of
your last message

Stephen Smalley <sds@epoch.ncsc.mil> writes:

>   But from an information flow perspective, you simply want to prove
>   that user_t can only reach sysadm_t through specific gate domains
>   like newrole_t.

is of this form:  It's apparently not expressible as a simple
information flow accessibility assertion.

Cheers --

        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: Fedora Core 2 setools RPM

[Stephen Smalley]

On Fri, 2004-06-18 at 15:31, Joshua D. Guttman wrote:
> So in some sense the bottom line is that you think the type relations
> give the essential core of the policy info, and to a first
> approximation one can focus on that.

I'd put it a bit more strongly, but close enough.

> Of course, it's still desirable to have access to the supplementary
> information (and an idea how to interpret it) so that the further
> refinement will eventually work out.  

Fair.

> A different point is that the main value added of slat is much more
> expressive security goals (even when restricted to the types info).
> You're not just talking about accessibility of a type to information
> flow from another, but also whether all the possible flows go through
> a desired gate type.  And the key fact you mentioned at the end of
> your last message

I may be wrong, but I think that you can determine this information via
libapol as well.

-- 
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: Fedora Core 2 setools RPM

[Frank Mayer]

>> A different point is that the main value added of slat is much more
>> expressive security goals (even when restricted to the types info).
>> You're not just talking about accessibility of a type to information
>> flow from another, but also whether all the possible flows go through
>> a desired gate type.  And the key fact you mentioned at the end of
>> your last message
> 
> I may be wrong, but I think that you can determine this information
> via libapol as well.

Yes a transitive information flow analysis is what makes this difficult, both to
do and for a human to understand.  Libapol has supported a form of transitive
information flow analysis from the beginning of its information flow support.
It has evolved somewhat, and now has significant filtering capabilities as
discussed in the tool help.

Frank



--
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: Fedora Core 2 setools RPM

[Frank Mayer]

> So in some sense the bottom line is that you think the type relations
> give the essential core of the policy info, and to a first
> approximation one can focus on that.
> 
> Of course, it's still desirable to have access to the supplementary
> information (and an idea how to interpret it) so that the further
> refinement will eventually work out.

I will assert rather strongly that a transitive analysis of flows between given
types is the nearly the entire concern.  Filters on that analysis make the
analysis practical, and the most important filters we have learned are interim
types (i.e., "trusted" types), object classes, and permissions and permissions
weights.  Libapol supports all of this.  

Constraints IMHO are like other orthogonal security mechanisms (such as
protection modes); they can add further restrictions but are not part of the
fundamental TE policy.  Role context restrictions are the same.  Some day we may
get to them (as well as checking for access modes and indeed if types are even
applied to real objects), but these issues are not critical to the goal.  Our
thrust, now that we have implemented most of the critical filters that we have
identified through analysis experience, is to provide a batching capability to
allow re-analysis and modeling of security properties.

Frank



--
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: Fedora Core 2 setools RPM

[Joshua D. Guttman]

"Frank Mayer" <mayerf@tresys.com> writes:

>   Filters on that analysis make the analysis practical, and the most
>   important filters we have learned are interim types (i.e.,
>   "trusted" types), object classes, and permissions and permissions
>   weights.

Could I ask you please to explain what you mean by these terms?

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: Fedora Core 2 setools RPM

[Frank Mayer]

guttman@malabar.mitre.org wrote:
>>   Filters on that analysis make the analysis practical, and the most
>>   important filters we have learned are interim types (i.e.,
>>   "trusted" types), object classes, and permissions and permissions
>>   weights.
> 
> Could I ask you please to explain what you mean by these terms?

As a starting point, you need to look at the GUI and help file for apol's
information flow analysis.  I'm sure our help files are not the best, but
performing the analysis should make these terms meaningful in the context of our
analysis capability.  The "trusted" types (I think the GUI calls them
"excluded") is by far the most important filter, as it allows you to exclude
certain intermediate types from the analysis of a given flow.

Frank



--
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: Fedora Core 2 setools RPM

[Frank Mayer]

guttman@malabar.mitre.org wrote:
>>   Filters on that analysis make the analysis practical, and the most
>>   important filters we have learned are interim types (i.e.,
>>   "trusted" types), object classes, and permissions and permissions
>>   weights.
> 
> Could I ask you please to explain what you mean by these terms?

As a starting point, look at the GUI and help file for apol's information flow
analysis.  I'm sure our help files are not the best, but performing the analysis
should make these terms meaningful in the context of our tool.  The "trusted"
types (I think the GUI calls them "excluded") is by far the most important
filter, as it allows you to exclude certain intermediate types from the analysis
of a given flow.

Frank



--
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: Fedora Core 2 setools RPM

[Russell Coker]

On Sat, 19 Jun 2004 04:43, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> A more realistic case is newrole.  user_t -> newrole_t -> sysadm_t is an
> allowed series of domain transitions, and the only thing preventing
> jdoe:user_r:user_t from using newrole to get to sysadm_t is the fact
> that jdoe is restricted to user_r and user_r is restricted to user_t by
> the kernel policy.  But from an information flow perspective, you simply
> want to prove that user_t can only reach sysadm_t through specific gate
> domains like newrole_t.

One feature I have suggested for policy analysis tools is a method of 
specifying policy analysis hints in the policy source.

This would allow specifying newrole_t as a gate domain as well as providing 
high level assertions about data flow.

If we are going to move to binary policy analysis then we would need some 
other mechanism for managing policy analysis information.  I think it would 
provide a significant benefit to allow policy authors to specify what the 
goals of their policy should be and then allow other people to analyse 
whether the policy meets it's goals in the context of a complete system.  
Maybe the next time we change the policy binary format we could add a field 
that the kernel would treat as a comment which could be used for checkpolicy 
to store data that can later be used by policy analysis tools.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: Fedora Core 2 setools RPM

[Serge E. Hallyn]

> On Sat, 19 Jun 2004 04:43, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > A more realistic case is newrole.  user_t -> newrole_t -> sysadm_t is an
> > allowed series of domain transitions, and the only thing preventing
> > jdoe:user_r:user_t from using newrole to get to sysadm_t is the fact
> > that jdoe is restricted to user_r and user_r is restricted to user_t by
> > the kernel policy.  But from an information flow perspective, you simply
> > want to prove that user_t can only reach sysadm_t through specific gate
> > domains like newrole_t.
> 
> One feature I have suggested for policy analysis tools is a method of 
> specifying policy analysis hints in the policy source.
> 
> This would allow specifying newrole_t as a gate domain as well as providing 
> high level assertions about data flow.

In my graphical DTE policy analysis tools, I supported precisely this,
annotating things like "entry program has been verified, so concentrate
on other paths".

With DTE modules, types and domains can be annotated with "assert"
statements, which relay information to arbitrary policy consistency
classes.  For instance, "assert blp trusted" would tell a class checking
for maintenance of BLP type relations across a module application that
this domain or type is trusted.  Of course a class which was checking for
domain transitions could be listening for something like "assert xition
ignore".

The code is just about there to compile DTE modules into SELinux policies.
My SELinux partition decided to throw a hissy before I was able to finish
testing, but I plan to get back to this after this coming week or the next.

I will be talking about DTE (== selinux?) modules on thursday at Usenix Tech.
I would love to chat afterward with anyone who has ideas about how the
module language would need to be changed to actually be of interest to
selinux people, or about why the module language simply sucks.

-serge

--
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: Fedora Core 2 setools RPM

[John D. Ramsdell]

Stephen Smalley <sds@epoch.ncsc.mil> writes:

> ...  I'd also think you would want both shared and static libraries,
> and have most of the tools dynamically linked against the shared
> library.

If Tresys is not completely sure that the libapol API is stable, they
may want to only release a static library for now.  Changing the API
used by a static library means that compilations may fail, but
existing binaries will be not be effected by the change.  Changing the
API used by a shared library means that existing binaries may fail.
Tresys should commit itself to an API provided by a shared library
only after careful thought.

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: Fedora Core 2 setools RPM

[Frank Mayer]

> If Tresys is not completely sure that the libapol API is stable, they
> may want to only release a static library for now.  Changing the API
> used by a static library means that compilations may fail, but
> existing binaries will be not be effected by the change.  Changing the
> API used by a shared library means that existing binaries may fail.
> Tresys should commit itself to an API provided by a shared library
> only after careful thought. 
> 
> John

We are positive that the API is not stable, and guarantee that it will change a
lot between releases.  We're still in a highly exploratory development cycle; so
feel free to use the libraries but understand they are evolving based upon our
needs.  For example, significant work is proceeding now to enhance the library
to support a semantic policy diff tool we're building, as well as a means to
model and batch information flow analyses. 

With that said, we have 2.5 years invested in this code, and for our own sanity
we try to keep old interfaces syntactically the same between versions, and add
new ones as necessary.  The headers are not structured well for strong modular
isolation of the libraries, so be careful.

Frank



--
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: Fedora Core 2 setools RPM

[John D. Ramsdell]

"Frank Mayer" <mayerf@tresys.com> writes:

> We are positive that the API is not stable, and guarantee that it
> will change a lot between releases.

Yeah, I suspected as such.  I fully understand why Tresys wouldn't
want to install a shared library version of libapol at this stage of
its development.

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: Fedora Core 2 setools RPM

[John D. Ramsdell]

"Karl MacMillan" <kmacmillan@tresys.com> writes:

> In general, we have not spent many resources addressing the use of
> libapol outside of setools.

>From my perspective, the application programmer's interface provided
by libapol seems to provide an attractive platform on top of which I
should be able to build a version of slat that can analyze binary
policy configuration files.  The alternative for me is to cobble
something together from the sources in the checkpolicy directory.  My
guess is that I would have to duplicate functionality already present
in libapol.

My greatest concern with using libapol for slat is that it seems to
provide no routines that expose CONSTRAIN statements in a policy.
When I did a grep on the sources, I notice the word "constrain" is not
in any header file but one, and libapol/binpol/borrowed.h contains the
following comment.

/* needed for constraints (which apol currently ignores */

John

$ grep -i constrain libapol/*.* libapol/*/*.*
libapol/apolicy_parse.y:/* from originial constraint.h */
libapol/apolicy_parse.y:typedef struct constraint_expr {
libapol/apolicy_parse.y:	struct constraint_expr *left;
libapol/apolicy_parse.y:	struct constraint_expr *right;
libapol/apolicy_parse.y:} constraint_expr_t;
libapol/apolicy_parse.y:/* end from constraint.h */
libapol/apolicy_parse.y:static int define_constraint(void);
libapol/apolicy_parse.y:static constraint_expr_t *define_cexpr(__u32 expr_type, __u32 arg1, __u32 arg2);
libapol/apolicy_parse.y:%token CONSTRAIN
libapol/apolicy_parse.y:			  opt_mls te_rbac users opt_constraints 
libapol/apolicy_parse.y:/* added July 2002; made constraints optional */
libapol/apolicy_parse.y:opt_constraints         : constraints
libapol/apolicy_parse.y:constraints		: constraint_def
libapol/apolicy_parse.y:			| constraints constraint_def
libapol/apolicy_parse.y:constraint_def		: CONSTRAIN names names cexpr ';'
libapol/apolicy_parse.y:			{ if (define_constraint()) return -1; }
libapol/apolicy_parse.y:static int define_constraint(void)
libapol/apolicy_parse.y:static constraint_expr_t *
libapol/apolicy_parse.y:	return (constraint_expr_t *)1; /* any non-NULL value */
libapol/apolicy_scan.l:CONSTRAIN |
libapol/apolicy_scan.l:constrain			{ return(CONSTRAIN); }
libapol/binpol/binpol.c:	 * buf[5] num constraints (ignore constraints) */	
libapol/binpol/binpol.c:	/* ignore constraints */
libapol/binpol/borrowed.h:/* needed for constraints (which apol currently ignores */


--
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: Fedora Core 2 policy source

[John D. Ramsdell]

"Kratzer, James R." <JamesK@xetron.com> writes:

> Where are the source policy files for Fedora Core 2?  The source directory
> "/etc/security/selinux/src/policy" appears to be missing from the install.
> Thanks.

In the RPM directory of Disk three of FC2, search for *selinux*, *policy*, 
and *setools*, and I think you'll find the SE Linux relevant RPMs.

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: Fedora Core 2 policy source

[John D. Ramsdell]

I meant to say:

In the RPM directory of Disk three of FC2, search for file names that
contain the strings, "selinux", "policy", and "setools", and I think
you'll find the SE Linux relevant RPMs.

Actually, in my original message, I typed in file name patterns that
both started and ended with an asterisk.  Of course, the asterisks
cause the text in between to be displayed in bold--not what I wanted.

John

ramsdell@mitre.org (John D. Ramsdell) writes:

> "Kratzer, James R." <JamesK@xetron.com> writes:
> 
> > Where are the source policy files for Fedora Core 2?  The source directory
> > "/etc/security/selinux/src/policy" appears to be missing from the install.
> > Thanks.
> 
> In the RPM directory of Disk three of FC2, search for *selinux*, *policy*, 
> and *setools*, and I think you'll find the SE Linux relevant RPMs.
> 
> 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.

--
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: Fedora Core 2 policy source

[Kratzer, James R.]

Ed,

Thanks a lot. I will look on the source RPMS discs.  I'm hoping I can just
install a single source RPM to obtain the policy source files.

James

-----Original Message-----
From: Ed Street [mailto:edstreet@street-tek.com]
Sent: Tuesday, June 15, 2004 8:04 PM
To: 'Kratzer, James R.'
Subject: RE: Fedora Core 2 policy source


Hello,

You need to install the source rpm's first :)  then the path will be valid.

Ed

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
Behalf Of Kratzer, James R.
Sent: Tuesday, June 15, 2004 5:08 PM
To: SE Linux Mail List (E-mail)
Subject: Fedora Core 2 policy source


Where are the source policy files for Fedora Core 2?  The source directory
"/etc/security/selinux/src/policy" appears to be missing from the install.
Thanks.

 

---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004
 

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