RE: Policy Language

RE: Policy Language

[Westerman, Mark]

On Monday, January 06, 2003 11:52 AM Stephen D. Smalley  wrote:

>> On Mon 1/6/2003 11:06 AM Joshua D. Guttman wrote:
>> Twiddles to the syntax would cause bad feeling for people who have
>> already developed policy analysis tools, or have crafted their own
>> policies.

That why I am posting to the list to try and get a feel from the
people who have created the tools. The changes so far only effect
three files. 

security_classes
initial_sids
rbac

Where security_classes and initial_sids don't change very much,
while rbac only changes on the creations of new roles. The 
general policy writer will hardly notice the change. 

>> 
>> I see that you know how to do the parsing for the language as it
>> currently exists, so please just do what's necessary...

"kludges" ?

>
>Yes, I agree.


The problem I am having in trying to build a policy management
system. The current te language and compiler build the policy.xx
from a policy.conf file. While the language work great with a 
policy.conf it will not check a te file named.te for example 
(ignoring the macros for this example)
  
I would like to eventuality move to a database system that could 
track many selinux policies for different systems. Such that the 
system could look at inputs from different te files and
import then and build policy.conf files for different systems. 

Taking the CLASS rules for example. While the current
definition work great on the policy.conf if does not work 
well on fragments of a policy.conf or a te file that is used
to build the policy.conf.

...
class_def      :  CLASS identifier
...
av_perms_def   :  CLASS identifier '{' identifier_list '}'
               |  CLASS identifier INHERITS identifier
               |  CLASS identifier INHERITS identifier '{' identifier_list
'}'
...

What I need to do when parsing a te file.
The class_def creates a key on identifier and the av_perms_def references a 
a key created by class_def. This way order can be maintain with the
class_def
processing. By adding extra definitions backwards compatibility can be build
into
the language(i.e 

class_def      :  CLASS identifier
               |  CLASSDEF identifier


I am asking to remove context sensitive meaning from tokens in the language.

Taken from "info bison".

"The Bison paradigm is to parse tokens first, then group them into
larger syntactic units.  In many languages, the meaning of a token is
affected by its context.  Although this violates the Bison paradigm,
certain techniques (known as "kludges") may enable you to write Bison
parsers for such languages."

Mark



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

[Frank Mayer]

> That why I am posting to the list to try and get a feel from the
> people who have created the tools. 

Without comment on the specific proposal (which I haven't studied yet),
I do have a general request: 

I would ask that we only change the policy syntax reluctantly and as
limited as possible, and only for strong need.  Every time the language
changes, it can be a lot or little work for us to sync up our parser for
setools.  Since we have a requirement to maintain backwards
compatibility with older policy syntax, each change can be a lot of
work.

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

[Russell Coker]

On Wed, 8 Jan 2003 19:02, Frank Mayer wrote:
> I would ask that we only change the policy syntax reluctantly and as
> limited as possible, and only for strong need.  Every time the language
> changes, it can be a lot or little work for us to sync up our parser for
> setools.  Since we have a requirement to maintain backwards
> compatibility with older policy syntax, each change can be a lot of
> work.

While we're on the topic, I think it would be good if the following files 
change as little as possible, and wherever possible the only changes should 
be in adding new entries.
access_vectors
initial_sids
security_classes
initial_sid_contexts

Whenever we have a major change to the kernel code it seems to result in a 
situation where the policy and the checkpolicy program need to be updated at 
the same time.  Installing the checkpolicy program first has no drastic 
consequences, but installing the new policy first can screw up an existing 
kernel.

This is something I still haven't adequately addressed in my Debian packages, 
and is probably something that will cause problems for other people who are 
preparing SE Linux packages.

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

[Stephen D. Smalley]

> I am asking to remove context sensitive meaning from tokens in the language.
> 
> Taken from "info bison".
> 
> "The Bison paradigm is to parse tokens first, then group them into
> larger syntactic units.  In many languages, the meaning of a token is
> affected by its context.  Although this violates the Bison paradigm,
> certain techniques (known as "kludges") may enable you to write Bison
> parsers for such languages."

The meaning of the tokens is not context sensitive.  The fact that the keyword 
'class' can occur in two different statements does not present a problem in 
scanning and parsing the configuration.  The policy language grammar does not 
rely on any of the "kludges" described in the referenced section of the bison 
manual.  Token parsing does not depend on semantic or syntactic context.

You can use the provided grammar (or a subset of it) as a basis for developing 
your own policy tools, as has already been done by others such as Tresys and 
MITRE.  

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


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

[Stephen D. Smalley]

> I used the wrong terminology (ambiguous) Your are absolutely
> correct that it is not ambiguous. While the following foo.y 
> is easily handled in a (yacc) file, it is not so easily handled
> in other languages. While I am asking could we put a ';' at the
> end of all statements ? 
> 
> For a regular expression on the two statements.
> 
> CLASS identifier
> CLASS identifier { identifier_list }
> 
> To identify the second from the first I have to look
> for a { and not just a white space or a ;

Sounds like you are using the wrong tool for the job (regular expressions rather 
than a grammar).  While it would be straightforward to implement the changes you 
suggest to the language, such changes don't seem to be justified by your 
explanation, and others have already developed policy management and analysis 
tools based on the current language definition.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


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

[Westerman, Mark]

I used the wrong terminology (ambiguous) Your are absolutely
correct that it is not ambiguous. While the following foo.y 
is easily handled in a (yacc) file, it is not so easily handled
in other languages. While I am asking could we put a ';' at the
end of all statements ? 

For a regular expression on the two statements.

CLASS identifier
CLASS identifier { identifier_list }

To identify the second from the first I have to look
for a { and not just a white space or a ;


whereas

CLASSDEF identifier
CLASS identifier { identifier_list }

I not longer have to look for '{' just a white space
on the CLASSDEF

If we use a ; at the end of all statement that would also
remove the difficulty of looking for a '{' to tell the difference
between the two  statements.

Would a ; be too difficult ? You could make the checkpolicy 
backwards compatible.



Mark









-----Original Message-----
From: Stephen D. Smalley [mailto:sds@epoch.ncsc.mil]
Sent: Monday, January 06, 2003 9:29 AM
To: selinux@tycho.nsa.gov; mark.westerman@westcam.com
Subject: Re: Policy Language



> In working toward a policy management system I have run across a few
> ambiguities in the language.

The grammar in policy_parse.y is unambiguous.  For that matter, the attached

grammar for the constructs that you mentioned is unambiguous, even with a 
completely free form statement list.  There are no conflicts.  What
precisely is 
the problem?

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil

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

[Stephen D. Smalley]

[-- Attachment #1: Type: TEXT/plain, Size: 396 bytes --]


> In working toward a policy management system I have run across a few
> ambiguities in the language.

The grammar in policy_parse.y is unambiguous.  For that matter, the attached 
grammar for the constructs that you mentioned is unambiguous, even with a 
completely free form statement list.  There are no conflicts.  What precisely is 
the problem?

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil

[-- Attachment #2: foo.y --]
[-- Type: TEXT/plain, Size: 1508 bytes --]

%token CLASS
%token INHERITS
%token IDENTIFIER
%token SID
%token ALLOW

%%
statement_list          : statement | statement_list statement
                        ;
statement               : av_perms_def |
                          class_def |
                          initial_sid_def |
                          initial_sid_context_def |
                          allow_def |
                          role_allow_def
                        ;
av_perms_def		: CLASS identifier '{' identifier_list '}'
                        | CLASS identifier INHERITS identifier 
                        | CLASS identifier INHERITS identifier '{' identifier_list '}'
			;
identifier_list		: identifier
			| identifier_list identifier
			;
identifier		: IDENTIFIER
			;
class_def		: CLASS identifier
			;
initial_sid_def         : SID identifier
                        ;
initial_sid_context_def : SID identifier security_context_def
                        ;
security_context_def	: identifier ':' identifier ':' identifier 
	                ;
allow_def               : ALLOW names names ':' names names ';'
                        ;
role_allow_def          : ALLOW names names ';'
                        ;
names           	: identifier
			| nested_id_set
			;
nested_id_set           : '{' nested_id_list '}'
                        ;
nested_id_list          : nested_id_element | nested_id_list nested_id_element
                        ;
nested_id_element       : identifier | nested_id_set
                        ;
%%

Policy Language

[Mark Westerman]

In working toward a policy management system I have run across a few
ambiguities in the language.

1. class rule

av_perms_def     : CLASS identifier '{' identifier_list '}'
                   {if (define_av_perms(FALSE)) return -1;}
                 | CLASS identifier INHERITS identifier
                   {if (define_av_perms(TRUE)) return -1;}
                 | CLASS identifier INHERITS identifier '{'identifier_list '}'
and 

class_def        : CLASS identifier
                     {if (define_class()) return -1;}
                 ;

coudl the class_def be defined as

class_def        : CLASSDEF identifier
                     {if (define_class()) return -1;}
                 ;
2. sid

initial_sid_def  : SID identifier
                    {if (define_initial_sid()) return -1;}
                 ;
and 

initial_sid_context_def  : SID identifier security_context_def
                         {if (define_initial_sid_context()) return -1;}
                         ;

Could the initial_sid_context_def be defined as

initial_sid_context_def  : SIDCONTEXT identifier security_context_def
                         {if (define_initial_sid_context()) return -1;}
                         ;

3. allow

allow_def        : ALLOW names names ':' names names  ';'
                    {if (define_te_avtab(AVTAB_ALLOWED)) return -1; }
                 ; 
and

role_allow_def   : ALLOW names names ';'
                    {if (define_role_allow()) return -1; }
                 ;
could the role_allow_def be defined as 

role_allow_def   : ROLEALLOW names names ';'
                    {if (define_role_allow()) return -1; }
                 ;

The changes would make development of a policy management system
a lot easer. The rules would still be order dependent in the
policy.conf, but it would remove the ambiguities of the rules and 
not make it order dependent in a general parse.y file. Such that 
above rule would not need special cases in order to build a policy.conf
file.


Mark


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