policy language extensions

policy language extensions

[David Caplan]

We are currently working on a couple of policy language extensions for 
which we'd like to let the group comment on.  Both grew out of the 
motivations that drove our previous work in developing a binary policy 
patch tool (see 
http://www.ultraviolet.org/mail-archives/selinux.2003/0768.html). We 
expect all changes to be eventually incorporated into the manline SE 
Linux package.

We're working on two enhancements:  conditional policy statements, and 
loadable binary policy modules.  The first is extending the policy 
language to allow conditional blocks of policy depending on the state of 
boolean variables (also defined in the policy).  The booleans are 
defined in a similar fashion to types and the conditional policy 
statements are of the form:

if (expression) then { policy_block } else { policy_block }

where 'expression' is any number of defined boolean variables joined 
with the standard operators (e.g., &&, ||, ==, !=, !, etc.) and the 
policy blocks are made up of any number of AV and Type rules with the 
'else' block being optional.

We've implemented an initial version of the user space portion of this 
(i.e., modifications to checkpolicy) and are porting the data structures 
and functionality to the kernel/security server.  We are planning to use 
  sysctl as the kernel interface to export the booleans.  A patch 
against the current version of checkpolicy is available at 
http://www.tresys.com/selinux/cond_policy_patch.gz for your perusal. 
Please note that policies built with this version of checkpolicy should 
_not_ be used (i.e., loaded) in an SE Linux kernel.  You can examine 
binary conditional policies with 'checkpolicy -d', and there is a test 
directory under the checkpolicy directory as well with a small utility 
that allows the setting of the booleans and displaying various parts of 
a binary policy.

The second extension we are currently designing is a mechanism to allow 
policy modules to be built independant of a base policy.  These modules 
could then be loaded and unloaded into a running policy.  They could be 
integrated into software packages, an rpm for example, so that if the 
software were installed on an selinux system  the appropriate policy 
would also be loaded.

Comments and contributions are welcome.

David
-- 
__________________________________

David Caplan     410 290 1411 x105
dac@tresys.com
Tresys Technology, LLC
8840 Stanford Blvd., Suite 2100
Columbia, MD 21045


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

[David Caplan]

Sorry, that link should have been:

http://www.tresys.com/checkpolicy_prototype.html

which is also accessible from

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

David Caplan wrote:
> We are currently working on a couple of policy language extensions for 
> which we'd like to let the group comment on.  Both grew out of the 
> motivations that drove our previous work in developing a binary policy 
> patch tool (see 
> http://www.ultraviolet.org/mail-archives/selinux.2003/0768.html). We 
> expect all changes to be eventually incorporated into the manline SE 
> Linux package.
> 
> We're working on two enhancements:  conditional policy statements, and 
> loadable binary policy modules.  The first is extending the policy 
> language to allow conditional blocks of policy depending on the state of 
> boolean variables (also defined in the policy).  The booleans are 
> defined in a similar fashion to types and the conditional policy 
> statements are of the form:
> 
> if (expression) then { policy_block } else { policy_block }
> 
> where 'expression' is any number of defined boolean variables joined 
> with the standard operators (e.g., &&, ||, ==, !=, !, etc.) and the 
> policy blocks are made up of any number of AV and Type rules with the 
> 'else' block being optional.
> 
> We've implemented an initial version of the user space portion of this 
> (i.e., modifications to checkpolicy) and are porting the data structures 
> and functionality to the kernel/security server.  We are planning to use 
>  sysctl as the kernel interface to export the booleans.  A patch against 
> the current version of checkpolicy is available at 
> http://www.tresys.com/selinux/cond_policy_patch.gz for your perusal. 
> Please note that policies built with this version of checkpolicy should 
> _not_ be used (i.e., loaded) in an SE Linux kernel.  You can examine 
> binary conditional policies with 'checkpolicy -d', and there is a test 
> directory under the checkpolicy directory as well with a small utility 
> that allows the setting of the booleans and displaying various parts of 
> a binary policy.
> 
> The second extension we are currently designing is a mechanism to allow 
> policy modules to be built independant of a base policy.  These modules 
> could then be loaded and unloaded into a running policy.  They could be 
> integrated into software packages, an rpm for example, so that if the 
> software were installed on an selinux system  the appropriate policy 
> would also be loaded.
> 
> Comments and contributions are welcome.
> 
> David

-- 
__________________________________

David Caplan     410 290 1411 x105
dac@tresys.com
Tresys Technology, LLC
8840 Stanford Blvd., Suite 2100
Columbia, MD 21045


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

[Dale Amon]

On Thu, Sep 25, 2003 at 05:45:28PM -0400, David Caplan wrote:
> We are currently working on a couple of policy language extensions for 
> which we'd like to let the group comment on.  Both grew out of the 

Looks like just what the doctor ordered. I was thinking
about a related issue yesterday while battling sshd policy
issues (actually I should not use past tense: still am) and
how much easier it would be if I could simply execute or delete
policy statements during a live debugt sessions using a 
policy interpreter. A sort of "perl -de 1" for policy
would be nice. 

Some things could be difficult though: policy statements
do not appear to me to have a 1:1 relation to the binary 
representation.

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

[David Caplan]

Dale Amon wrote:
> 
> Some things could be difficult though: policy statements
> do not appear to me to have a 1:1 relation to the binary 
> representation.
> 

You are right, they do not.  The policy statement:

allow  domain  init_t : process  { sigchld signull };

expands into a hash table entry (in the binary policy) for every type 
associated with the domain attribute.  In a very stripped down policy I 
was looking at this was 49 types.

You also need to keep in mind that "subtraction" or disabling of rules, 
via a conditional policy, is not equivalent to removing permissions.  If 
the above rule were in a condition block that was disabled, there might 
still be an allow rule in the base policy, or even in another 
conditional block, that allowed those permissions.


-- 
__________________________________

David Caplan     410 290 1411 x105
dac@tresys.com
Tresys Technology, LLC
8840 Stanford Blvd., Suite 2100
Columbia, MD 21045


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

[Stephen Smalley]

On Fri, 2003-09-26 at 09:02, Dale Amon wrote:
> Some things could be difficult though: policy statements
> do not appear to me to have a 1:1 relation to the binary 
> representation.

Correct.  A policy statement may specify sets of types and classes as
well as using type attributes to represent sets of types; these
statements are expanded into individual (source type, target type,
target class, access vectors or new types) tuples in the binary
representation.  Also, you may have overlapping or even redundant policy
statements in the policy.conf that are unioned by the policy compiler
(particularly due to macro expansions), so removing a statement doesn't
necessarily mean that the permissions should go away.  If you take a
close look at the policy patch tools posted to the list back in June by
Frank Mayer, you'll see that they had to consider these issues for that
work.
 
-- 
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.