Problems related to the policy language

Problems related to the policy language

[James Carter]

1. Inflexibility
	a. Limitations to what can be in a module
2. Gaps in features
	a. User transitions
	b. Type inheritance
3. Ordering issues
	a. Unless the rules are in the same file, proper ordering cannot
	be guaranteed for portcon and other rules for which ordering is
	important
4. Confusing semantics
	a. Between templates and interfaces
	b. Between tunables and booleans
	c. Require rules
	d. Optional blocks
5. Inconsistencies in the syntax
	a. Some rules end with a semi-colon, others do not
	b. Some lists are space separated, some are comma separated
	c. Some lists require curly braces even when there is only one
	member, others do not
	d. For some rules the order of the rules matter, in others they
	do not
	e. File contexts start with the path

-- 
James Carter <jwcart2@tycho.nsa.gov>
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: Problems related to the policy language

[Mike Edenfield]

On the subject of language inconsistencies:

One thing that I frequently find myself doing wrong is nesting the 
various types of blocks.  IIRC, you can nest a tunable policy inside an 
optional block, but not vice versa.  I understand why -- one is resolved 
at policy compile time and the other at run time -- but just from a 
policy language perspective it seems inconsistent.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problems related to the policy language

[Tim]

My 2 cents on problems related to the policy language.

[View from embedded system developer]

Than might help to push SELinux into embedded Linux devices.

Path based files labeling using genfscon is _very_ limited. That
creates a lot of problems when non-xattr filesystems are used with
genfscon even with a patch that allows file granularity for labeling
(instead of filesystem granularity). Nature of the problem is:
- non-xattr filesystems are mounted into different mounting points often;
- directory names are same after mounting points, so it is hard to
specify correct labeling;
- read-only filesystems (usually non-xattr) often share same inode for
files with the same contents.

It is preferable to have simple "absolute path-based labeling" using
genfscon (or new keyword, e.g. genapcon) regardless of filesystem.
E.g.:
genfscon /opt/app/myapp  u:r:t   --- "myapp" and everything "below"
/opt/app/myapp will have u:r:t label

Of cause, there are known security issues with such approach (links),
but we can handle it.

Tim

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problems related to the policy language

[Daniel J Walsh]

On 04/09/2009 11:28 AM, James Carter wrote:
> 1. Inflexibility
> 	a. Limitations to what can be in a module
> 2. Gaps in features
> 	a. User transitions
> 	b. Type inheritance
> 3. Ordering issues
> 	a. Unless the rules are in the same file, proper ordering cannot
> 	be guaranteed for portcon and other rules for which ordering is
> 	important
> 4. Confusing semantics
> 	a. Between templates and interfaces
> 	b. Between tunables and booleans
> 	c. Require rules
> 	d. Optional blocks
> 5. Inconsistencies in the syntax
> 	a. Some rules end with a semi-colon, others do not
> 	b. Some lists are space separated, some are comma separated
> 	c. Some lists require curly braces even when there is only one
> 	member, others do not
> 	d. For some rules the order of the rules matter, in others they
> 	do not
> 	e. File contexts start with the path
>
Attributes and types are not interchangeable.

Can not assign and attribute to an attribute.

Booleans can not contain booleans
Attributes can not be assigned via booleans.

Having something like:

tunable_bolicy(`unconfined_services', 	`
	unconfined_domain($1)
')

Tools do not do a good job of telling you when you have a constraint 
violation or any way to get around a constraint violation.

Need ability to easily extend objects

java/mono/execmem extensions.

user_t + execmem + execstack = user_java_t, where user_jave_t has full 
all the same access as user_t and full access between them  user_t <-> 
user_java_t.

sepolgen tool needs more formal syntax to do a better job of finding the 
best interface for an access violation.

Need tools to find out whether a domain is a permissive domain.

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