Announce: SELinux conditional policy extensions

Announce: SELinux conditional policy extensions

[Karl MacMillan]

A new release of the conditional policy extensions to SELinux is
available from our website:

http://www.tresys.com/selinux/index.html

The conditional policy extensions to SELinux allow runtime modification
of the security policy without having to load a new policy. Using
boolean variables and expressions, it is possible to define sections of
policy that are conditionally applied. Please see the website for more
information.

This release includes modifications to the linux kernel, checkpolicy,
and libselinux and allows the creation and loading of conditional
policies. We have done internal testing, but this release is not ready
for production use. In particular, the selinuxfs modifications are new
and have had only minimal testing.

There are several known deficiencies with this release that we will
address:

- The selinuxfs additions need review, cleanup, and testing.
- Fine-grained labeling of selinuxfs has not been implemented yet.
- The policy has not yet been modified to take advantage of the new
language features.

-- 
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: Announce: SELinux conditional policy extensions

[Joshua D. Guttman]

Karl --

I've just gotten round to reading through README-COND describing the
conditional policy mechanism.

The idea of dynamic changes to the policy makes me nervous.  It seems
to make the job of understanding the meaning and consequences of  a
policy -- already hard -- even more daunting.  And I don't really see
important security goals that cannot be achieved the old way.  

Doesn't it seem to create a "policy reachability" problem similar to
the old (undecidable) Harrison-Rizzo-Ullman problem?  Do you know
whether it's decidable in general whether there's a sequence of steps
by a particular set of users (let's say) that leads to a particular
user being able to access a particular file?  

Giving conditional access to a few specific services could
alternatively be arranged by having some (trusted, non-kernel) gateway
demons that either respond to requests when desired or don't, when the
flag is set the other way.

Is there a clearly defined minimum policy and maximum policy for every
conditional policy?  Is there a clearly defined set (e.g. a lattice)
of policies corresponding to the different possible dynamic
configurations?  Is this lattice constructible in some straightforward
way?  

And why should we incorporate a mechanism like this, if we haven't yet
understood the answers to a bunch of questions like these?  

May I ask you please to try to explain more precisely and in more
detail than README-COND does, how this mechanism works and why it's
really a good idea?  

Thanks --

        Joshua         

Karl MacMillan <kmacmillan@tresys.com> writes:

>   A new release of the conditional policy extensions to SELinux is
>   available from our website:
>   
>   http://www.tresys.com/selinux/index.html
>   
>   The conditional policy extensions to SELinux allow runtime modification
>   of the security policy without having to load a new policy. Using
>   boolean variables and expressions, it is possible to define sections of
>   policy that are conditionally applied. Please see the website for more
>   information.


-- 
	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: Announce: SELinux conditional policy extensions

[Colin Walters]

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

On Thu, 2004-02-12 at 20:22, Joshua D. Guttman wrote:

> The idea of dynamic changes to the policy makes me nervous.  It seems
> to make the job of understanding the meaning and consequences of  a
> policy -- already hard -- even more daunting.  And I don't really see
> important security goals that cannot be achieved the old way.  

I am interested in doing some policy analysis work too, and I share your
sentiment here.

> Giving conditional access to a few specific services could
> alternatively be arranged by having some (trusted, non-kernel) gateway
> demons that either respond to requests when desired or don't, when the
> flag is set the other way.

A different approach that comes to mind is binary policy "patches".  So
say you have a base policy which includes the unmodified ping.te.  But
as described in README-COND, you also want to sometimes allow users to
execute ping.  So you create a separate file ping-user.te, which
contains the necessary added permissions.  This would be compiled
specially by checkpolicy to a binary policy "patch" relative to the base
policy, which could be loaded and also unloaded at runtime by the
kernel.

Implementing unloading would require implementing negation, but that
seems useful enough on its own too that it would be worthwhile.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Announce: SELinux conditional policy extensions

[Stephen Smalley]

On Fri, 2004-02-13 at 00:19, Colin Walters wrote:
> A different approach that comes to mind is binary policy "patches".  So
> say you have a base policy which includes the unmodified ping.te.  But
> as described in README-COND, you also want to sometimes allow users to
> execute ping.  So you create a separate file ping-user.te, which
> contains the necessary added permissions.  This would be compiled
> specially by checkpolicy to a binary policy "patch" relative to the base
> policy, which could be loaded and also unloaded at runtime by the
> kernel.
> 
> Implementing unloading would require implementing negation, but that
> seems useful enough on its own too that it would be worthwhile.

Binary policy patching was implemented earlier by Tresys as a short term
solution to the same problem (see
http://marc.theaimsgroup.com/?l=selinux&m=105459714906101&w=2), but the
conditional policy extensions provide a better solution.  With binary
policy patching, you still have to authorize some domain to reload the
entire policy, and you have no guarantees (except what is provided by
userspace) as to the specific nature of the changes implemented by the
reload.  With the conditional policy extensions, you can define the set
of policy variations within the policy itself, and control the ability
to make a particular well-formed change to 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: Announce: SELinux conditional policy extensions

[Frank Mayer]

> A different approach that comes to mind is binary policy "patches". 
> So say you have a base policy which includes the unmodified ping.te. 
> But as described in README-COND, you also want to sometimes allow
> users to execute ping.  So you create a separate file ping-user.te,
> which contains the necessary added permissions.  This would be
> compiled specially by checkpolicy to a binary policy "patch" relative
> to the base policy, which could be loaded and also unloaded at
> runtime by the kernel. 

I think Steve already noted the reference to the precursor work that did
essentially this.  The conditional policy is the evolution of that work.
 
> Implementing unloading would require implementing negation, but that
> seems useful enough on its own too that it would be worthwhile.

We've aactually spent considerable time thinking about the problem of
"unloading" and you underestimate that complexity of the problem.  The primary
complicating factor is that multiple rules within a policy may (and very often
do) grant the same access, so you cannot simply remove access granted by a rule
to be unloaded as another (still loaded rule) might have already granted that
access.  In the simple case of policy patches that we previously released, the
only safe solution was to reconstruct the policy each time.  

Indeed, we are just beginning to more formally deal with the issue of loading
and unloading "policy modules" as part of our next step in our development
efforts aimed at improved policy management infrastructure (of which the
conditional policy extensions was a previous step).  We haven't advanced far
along this path, but right now we do not see the need to further change the
kernel mechanism in order to support policy modules that are loadable during
runtime (e.g., package install).  The real challenge is label management but
that's a different discussion.....

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: Announce: SELinux conditional policy extensions

[Frank Mayer]

> The idea of dynamic changes to the policy makes me nervous.  It seems
> to make the job of understanding the meaning and consequences of  a
> policy -- already hard -- even more daunting.  And I don't really see
> important security goals that cannot be achieved the old way.
>
> Doesn't it seem to create a "policy reachability" problem similar to
> the old (undecidable) Harrison-Rizzo-Ullman problem?  Do you know
> whether it's decidable in general whether there's a sequence of steps
> by a particular set of users (let's say) that leads to a particular
> user being able to access a particular file?
> 
> Giving conditional access to a few specific services could
> alternatively be arranged by having some (trusted, non-kernel) gateway
> demons that either respond to requests when desired or don't, when
> the flag is set the other way. 

You don't have to convince us that analyzing TE policies for desired security
properties is difficult.  We've probably spent more time than anyone analyzing
real systems' TE policies and understand the challenge. Indeed the genesis of
our setools package and its core apol tool/library is to support complex policy
analysis.  

I don't agree that conditional policies make the problem different as you seem
to imply.  Indeed I would argue that at worse a conditional policy just requires
you to analyze multiple policies that just happen to be packaged into a single
policy file.  In essence each combination of possible Boolean values is a
distinct policy which needs to be analyzed for desired security properties.
This is not conceptually different than the current situation without
conditionals.  [We're evolving our apol tool to handle these conditionals in the
future to be able to help analyze these permutations.]  The problem remain
essentially the same. {NOTE:  Fraiser-Badger actually investigated the issue of
dynamic type enforcement, albeit in a more constrained manner, in their
"Ensuring Continuity During Dynamic Security Policy Reconfiguration in DTE"
paper some years ago.]

As with the current TE mechanism, the policy writer can make policy analysis and
certification more or less difficult, and the conditional mechanism doesn't
change the fact.  Some proposed example uses would have no TE policy impact
(e.g., means to control packages of auditallow statements.  If you don't want
the complexity of analyzing policy permutations as a result of conditionals,
don't use conditionals in your policy...that seems to be a simple enough
solution to your concern without taking the capability away from those who want
the flexibility.
 
> Is there a clearly defined minimum policy and maximum policy for every
> conditional policy?  Is there a clearly defined set (e.g. a lattice)
> of policies corresponding to the different possible dynamic
> configurations?  Is this lattice constructible in some
> straightforward way? 
> 
> And why should we incorporate a mechanism like this, if we haven't yet
> understood the answers to a bunch of questions like these?

Two answers: 1) I assert this mechanisms does not change the nature of the
analysis so your question is aimed at the SE Linux TE mechanism in general, not
the conditional policy extensions.  But even if it did...

2) Because SE Linux introduced "pragmatic" mandatory security to the world, and
it seems to be having success after our decades of failure of finding a means to
introduce strong mandatory security to the "mainstream."  My observations to
date are very few are concerned (rightly or wrongly) with rigorous policy
analysis, and are more concerned with a practical mechanism to provide greater
least privilege and system hardening.  Those that are more concerned with the
MLS-like and other traditional mandatory access control problem domains have
long misused BLP/Biba mandatory mechanism on low assurance solutions.  SE
Linux's TE is just starting to penetrate that problem domain in a positive way
(IMHO).  So we all get the collective challenge of supporting the
"mainstreaming" of a pragmatic TE mandatory mechanism, having to deal with the
larger pragmatic market pressing the mechanism into a flexible direction, while
being able to retain the key mandatory access control traits we desire and
expanding our analysis capability to support those traditional concerns.

In any case, the broader market will make or break the success of TE in Linux,
and we from the more traditional background have to find ways to adapt and
support this effort to make it successful.  

> May I ask you please to try to explain more precisely and in more
> detail than README-COND does, how this mechanism works and why it's
> really a good idea? 

The above is applicable small community of interest within SE Selinux and not
appropriate in a README file aimed at understanding use of the mechanism.  



--
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: Announce: SELinux conditional policy extensions

[Russell Coker]

On Sat, 14 Feb 2004 06:14, "Frank Mayer" <mayerf@tresys.com> wrote:
> 2) Because SE Linux introduced "pragmatic" mandatory security to the world,
> and it seems to be having success after our decades of failure of finding a
> means to introduce strong mandatory security to the "mainstream."  My
> observations to date are very few are concerned (rightly or wrongly) with
> rigorous policy analysis, and are more concerned with a practical mechanism
> to provide greater least privilege and system hardening.

Yes, this is an issue that can not be under-estimated.

Currently my work is tending towards providing less protection so that it is 
more acceptable to the majority of users.  My personal preference of the 
trade-off between security and usability is to have more security than most 
people will be prepared to accept.  But we have to do what's necessary to get 
the user-base.

When we get SE Linux in wide-spread use with a less restrictive policy it will 
be much easier for everyone who is interested in security.  Taking a system 
that's running SE Linux in a less restrictive manner and reconfiguring it to 
be more restrictive is easy, installing SE Linux on a server that has not run 
it before is much more difficult.

I would like to see at least 30% of university students who are enthusiastic 
about Linux using SE Linux!  Then in a few years time there will be a good 
user-base of people who know how SE Linux works and have a good general 
knowledge of security.

-- 
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: Announce: SELinux conditional policy extensions

[John D. Ramsdell]

Russell Coker <russell@coker.com.au> writes:

> On Sat, 14 Feb 2004 06:14, "Frank Mayer" <mayerf@tresys.com> wrote:

> > 2) Because SE Linux introduced "pragmatic" mandatory security to
> > the world, and it seems to be having success after our decades of
> > failure of finding a means to introduce strong mandatory security
> > to the "mainstream."  My observations to date are very few are
> > concerned (rightly or wrongly) with rigorous policy analysis, and
> > are more concerned with a practical mechanism to provide greater
> > least privilege and system hardening.
> 
> Yes, this is an issue that can not be under-estimated.
> 
> Currently my work is tending towards providing less protection so
> that it is more acceptable to the majority of users.  My personal
> preference of the trade-off between security and usability is to
> have more security than most people will be prepared to accept.  But
> we have to do what's necessary to get the user-base.

In my opinion, adding more complexity to the policy enforcement
mechanism is likely to drive away new users.  Why should people be
interested in an operating system that provides mandatory access
control if they find its access control policy incomprehensible?

SE Linux policies are difficult to understand even with policies that
make no use of the conditional policy extension.  Consider the
situation surrounding information flow analysis.  Both MITRE and
Tresys have produced tools that perform an information flow analysis.
In a comprehensible system, it would be obvious how the two flow
analyses relate.  I have yet to see a plausible account of the two
flow analyses in a common framework.

I have one suggestion for making SE Linux policies more
comprehensible.  Suppose the semantics of a class is defined by
binding it to one or more LSM hook functions that perform access
control.  In this way, the author of a policy file would know that an
allow statement that refers to, say, the file class is making a
statement about permissions associated with the LSM file access
control hooks, and statements that refer to the inode class is making
a statement about permissions associated with the LSM inode access
control hooks.

Of course, the SE Linux Security Module implements a binding of
classes to access control hooks, but documentation available to policy
writers I've seen does not encourage the writers to rely on any
particular binding.

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: Announce: SELinux conditional policy extensions

[Stephen Smalley]

On Fri, 2004-02-20 at 08:05, John D. Ramsdell wrote:
> I have one suggestion for making SE Linux policies more
> comprehensible.  Suppose the semantics of a class is defined by
> binding it to one or more LSM hook functions that perform access
> control.  In this way, the author of a policy file would know that an
> allow statement that refers to, say, the file class is making a
> statement about permissions associated with the LSM file access
> control hooks, and statements that refer to the inode class is making
> a statement about permissions associated with the LSM inode access
> control hooks.
> 
> Of course, the SE Linux Security Module implements a binding of
> classes to access control hooks, but documentation available to policy
> writers I've seen does not encourage the writers to rely on any
> particular binding.

The set of security classes and permissions were originally defined long
before LSM was even considered, and were based on an analysis of the set
of kernel abstractions and logical operations.  Changing them to conform
to the LSM hooks would be pointless, and likely lead to greater
confusion, as multiple LSM hooks map to a single permission (or set of
permissions) in the SELinux model.

-- 
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: Announce: SELinux conditional policy extensions

[Frank Mayer]

ramsdell@linus.mitre.org wrote:
> In my opinion, adding more complexity to the policy enforcement
> mechanism is likely to drive away new users.  Why should people be
> interested in an operating system that provides mandatory access
> control if they find its access control policy incomprehensible?
> 
> SE Linux policies are difficult to understand even with policies that
> make no use of the conditional policy extension.  Consider the
> situation surrounding information flow analysis.  Both MITRE and
> Tresys have produced tools that perform an information flow analysis.
> In a comprehensible system, it would be obvious how the two flow
> analyses relate.  I have yet to see a plausible account of the two
> flow analyses in a common framework.

All true.  We here have spent a huge amount of energy analyzing policies, and
building tools to support analysis.  But...The complexity is not because NSA
decided to make Linux more complex and then add type enforcement.  The
complexity is because Linux *is* a complex OS, with notions and mechanisms that
evolved over decades.  Any comprehensive attempt to encapsulate all access in
such a system, where the semantics of "access" is loosely defined with numerous
exceptions and special cases is bound to be complex.  The OS is complex and
there is no way around it...we're not dealing with nice security kernels here
that have simple task and segments abstractions upon which we can define clean
and simple access control constructs.

Several years ago when I first started to get involved with SE Linux I had much
the same reaction as above.  I've concluded that SE Linux is (from a security
assurance perspective) most analogous to the long ago Trusted XENIX from
IBM/TIS, where we evolved a mainstream Unix system to a B2 (middle-high?)
assurance level.  It was not easy and the Unix architecture is by no means clean
as compared to what a security kernel would contemplate.  

Nonetheless, what excites me is the economic potential of SE Linux to be
successful and widely adapted with a strong and flexible mandatory security
mechanism (TE rather than BLP or Biba).  So we all have challenge of finding
ways to analyze these policies and evolving abstractions to make the mechanisms
more accessible to developers if we want to stay in the Linux arena.   Far from
driving people away, it is my observation that SE Linux is making mandatory
security more accessible.

If one's goal is a simple, mathematically verifiable access control
architecture, then Linux is not the OS for you.  But if we're looking for widely
acceptable access control that can be rigorously informally analyzed, then I'm
pleasantly surprised with SE Linux. 

 



--
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: Announce: SELinux conditional policy extensions

[John D. Ramsdell]

I think Stephen's comments sink my proposal.  In any event, I hope
people will find poldecond is a useful general purpose tool so that
analysis tools can be used with policies that use the conditional
extension before they are upgraded to understand the new syntax.

John

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

> ramsdell@linus.mitre.org wrote:
> > In my opinion, adding more complexity to the policy enforcement
> > mechanism is likely to drive away new users.  Why should people be
> > interested in an operating system that provides mandatory access
> > control if they find its access control policy incomprehensible?
> > 
> > SE Linux policies are difficult to understand even with policies that
> > make no use of the conditional policy extension.  Consider the
> > situation surrounding information flow analysis.  Both MITRE and
> > Tresys have produced tools that perform an information flow analysis.
> > In a comprehensible system, it would be obvious how the two flow
> > analyses relate.  I have yet to see a plausible account of the two
> > flow analyses in a common framework.
> 
> All true.  We here have spent a huge amount of energy analyzing policies, and
> building tools to support analysis.  But...The complexity is not because NSA
> decided to make Linux more complex and then add type enforcement.  The
> complexity is because Linux *is* a complex OS, with notions and mechanisms that
> evolved over decades.  Any comprehensive attempt to encapsulate all access in
> such a system, where the semantics of "access" is loosely defined with numerous
> exceptions and special cases is bound to be complex.  The OS is complex and
> there is no way around it...we're not dealing with nice security kernels here
> that have simple task and segments abstractions upon which we can define clean
> and simple access control constructs.
> 
> Several years ago when I first started to get involved with SE Linux I had much
> the same reaction as above.  I've concluded that SE Linux is (from a security
> assurance perspective) most analogous to the long ago Trusted XENIX from
> IBM/TIS, where we evolved a mainstream Unix system to a B2 (middle-high?)
> assurance level.  It was not easy and the Unix architecture is by no means clean
> as compared to what a security kernel would contemplate.  
> 
> Nonetheless, what excites me is the economic potential of SE Linux to be
> successful and widely adapted with a strong and flexible mandatory security
> mechanism (TE rather than BLP or Biba).  So we all have challenge of finding
> ways to analyze these policies and evolving abstractions to make the mechanisms
> more accessible to developers if we want to stay in the Linux arena.   Far from
> driving people away, it is my observation that SE Linux is making mandatory
> security more accessible.
> 
> If one's goal is a simple, mathematically verifiable access control
> architecture, then Linux is not the OS for you.  But if we're looking for widely
> acceptable access control that can be rigorously informally analyzed, then I'm
> pleasantly surprised with SE Linux. 
> 
>  

--
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: Announce: SELinux conditional policy extensions

[Joshua D. Guttman]

When you refer to conflicting rules, what do you mean?  

Thanks --

        Joshua 

>From README-COND:

>      - Policy conflicts with policy
>    
>          Non-conditional policy rules take preference over conditional 
>          rules.  In most cases, a conflicting conditional rule is 
>          discarded. In some cases, the policy compiler will exit with an 
>          error. The list below describes the conflicts and the results:
>    
>          - A conditional type rule conflicts with a non-conditional type 
>            rule
>    
>    	  The conditional type rule is discarded and the compiler issues
>    	a warning.
>    
>          - A conditional type rule in one conditional policy block 
>    	conflicts with 	a conditional type rule in a different 
>    	conditional policy block.
>    
>    	  The previously processed rule is kept, the second is discarded.
>    

-- 
	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: Announce: SELinux conditional policy extensions

[Frank Mayer]

> When you refer to conflicting rules, what do you mean?
> 

The readme file certainly could do a better job here.  From memory, I believe
there is a potential to have conflicts for the type_* rules.  For example, the
semantics of type_transition is that for each key (i.e., each
source-target-class triple), only one "default type" may be specified.  Thus we
must ensure that only on type_transition rule is in effect at any one time for
each policy.  That is the de-conflicting that the parsers does as described by
the readme file.

There is no such conflict in the AVC rules such as allow.

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.

Announce: Slat 1.1.0 with policy deconditionalizer

[John D. Ramsdell]

Slat version 1.1.0 has been committed into the nsa module of the
selinux project on SourceForge.  This version reimplements some old
fixes that somehow were left out of the repository at NSA, and
provides a new program called poldecond.

The poldecond program accepts policy configuration files that use the
conditional policy extension.  The program extracts the
conditional-less policy defined by using the default value for each
boolean in the input.  For example, suppose ping.te contains the
following boolean declaration:

  bool user_ping false;

The command

  $ poldecond ping.te ping_false.te

will produce a te file with user_ping = true branches elided.

The value for the first boolean declaration overrides all others, so
one can derive other policies by adding boolean declarations with
different defaults at the beginning of the input.  For example, to
produce a te file with user_ping = false branches elided, use the
command:

  $ echo 'bool user_ping true;' | cat - ping.te | poldecond - ping_true.te

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.