Sample policy language extension supporting per-user policy

Sample policy language extension supporting per-user policy

[Eamon Walsh]

The following came out of a private discussion on user management and 
SELinux.  It was poorly received, but I'm posting it here so it gets 
archived.

It's an idea for a policy language extension.  It is intended to reduce 
the size of the policy and the number of types.  It does this by 
providing support for per-user types natively instead of having to 
mangle the username onto the front of types.

The at sign (@) becomes a special character in the language extension. 
The words "group", "member", "each", and "all" become keywords.  The 
exact syntax isn't really as important as the idea.  But here goes:


1. User Attributes

Ability to define attributes ("groups") on users:
group admins;
user ewalsh roles staff_r;
member ewalsh, admins;

There is a fixed group "all" which includes every user.


2. Types and Attributes

The type declaration:
type @app_t;

Declares a type app_t as a "per-user" type.  With a per-user type, the 
user field of the security context counts as part of the type. 
Basically think of @app_t as a set of types, one for each user defined 
in the policy.

Same thing with per-user attributes:
attribute @attr;

Once a per-user type or attribute is defined, it must be referred to in 
all other statements prefixed with a user or group name, or the special 
keyword "each", to qualify it:

all@app_t means the whole set
ewalsh@app_t means only ewalsh's type
admins@app_t means the types of all users in admins.
each@app_t is used for one-to-one mappings, as will be seen.

Same thing with attributes.  Now for the semantics of putting attributes 
on types:

typeattribute all@app_file_t file_type;
Applies file_type to all the per-user types in @app_file_t.

typeattribute other_file_t all@app_file_type;
Applies all the per-user attributes in @app_file_type to other_file_t.

typeattribute each@app_file_t each@app_file_type;
Each per-user type in @app_file_t gets the corresponding (same user) 
attribute in @app_file_type: a one-to-one mapping.

typeattribute all@app_file_t all@app_file_type;
Applies every per-user attribute to every per-user type, which would 
probably be a rare thing.

Of course, "all" could be replaced with individual users or groups to 
narrow down the sets.


Granting Permissions

Same deal with allow rules:

allow each@app_t each@app_file_t:file read;
The most common scenario, this would allow the per-user domains to 
access the files carrying the corresponding per-user type.

allow all@app_t common_file_t:file read;
Allows all the per-user domains to access one file type.

allow common_t all@app_file_t:file read;
Allows a common domain to access all the per-user file types.

allow all@app_t all@app_file_t:file read;
Allows all per-user domains to access everyone's files.  Again, probably 
a rare thing.

Again, narrowing down is possible:

allow admins@app_t special_file_t:file read;
Would only allow the app_t domain to access special files when an admin 
user is running it.


File Contexts

Files would be labeled with the base type.  For example if the per-user 
type is @app_file_t, files would be labeled with app_file_t.  It should 
all just work, because the kernel will know app_file_t is per-user, and 
the user field will name the user in question.

-- 
Eamon Walsh <ewalsh@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: Sample policy language extension supporting per-user policy

[Eamon Walsh]

Responding to a private message on-list:

 > - This discussion should happen on list,
 > - Human understandability of the source policy is a concern,

I think the language extension would be easier to understand than the 
current m4-based way of accomplishing the same thing.


 > - I don't think we want to encourage automatic type mangling, even for
 > short term implementation, as it will just cause confusion and leak
 > though audit messages and kernel APIs.

The language extension could be implemented at compile-time using 
automatic type mangling.  But if this is not possible then it could be 
built into the policy language itself.  The policy size reduction could 
only happen this way anyway.


 > - We need to make sure we are solving the real problem.

This would not really solve the problem brought up in the private 
discussion, which is how to better integrate user management into 
SELinux.  But it could help, by allowing users to be added in policy 
modules and then having existing policy pick them up.

The major problem it would solve is policy size and complexity of type 
names.


 > - Separation of Linux user management from SELinux policy seems
 > necessary, so it won't get us to the point of per-Linux-user
 > permissions.

The debate over whether or not they should be separated triggered this 
proposal, but I think it could stand on its own even if they do remain 
separated.


-- 
Eamon Walsh <ewalsh@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.