Re: Authorization Workflow for Message Queueing Platform

[Stephen Smalley <sds@tycho.nsa.gov>]

On Tue, 2009-05-12 at 13:03 -0400, Joshua Kramer wrote:
> Hello,
> 
> In considering the authorization workflow for a message queueing 
> platform - specifically, apache qpid - I came up with the following.  
> Please let me know how I can improve this.
> 
> Thanks,
> -Josh
> 
>  I.Definitions
>  A.In this narrative, "this Subject" means the process connecting to qpid.
>  II.Determine the Action.
>  A.If ACT_CREATE, ACT_DELETE:
>  i.Determine the object type.  If OBJ_QUEUE, determine if it is a 
> server-side or client-side queue.
>  ii.Determine if the Context of this Subject permits to CREATE or DELETE 
> Objects in the parent Object?  (i.e. are we allowed to create queues  in 
> this broker?)
>  a)Determine this by searching the SELinux context list first by finding 
> the map corresponding to object_type, then the map corresponding to the 
> parent's name. TODO: how do we determine the parent from this object as 
> passed in the Acl::authorise call?)

SELinux is not an ACL scheme, and thus you don't want to search a list
of security contexts associated with the object to decide whether
something is permitted.  Instead, you want to perform a SELinux
permission check using avc_has_perm() and friends, as is done by Xorg,
D-BUS, and SE-PostgreSQL.

>  b)If this is not permitted, deny and return.
>  iii.If command is create and Context does permit object creation:
>  a)If this is OBJ_QUEUE
> Does the Context of this Subject permit it to CREATE or DELETE queues of 
> the type noted in i above?  TODO: how do we represent "permitted to 
> create server queue" and "permitted to create client queue" in the 
> SELinux context list?
> If Context does permit creation:
> Add an item in the SELinux context list for this object.
> Inherit this Object's context from the parent, OR

Compute the default label using the security_compute_create(3) function.
This consults the security policy, particularly the type_transition
rules for the object class.

> Label according to the arguments passed in on the create call.
> Create the Object
> Return control
> Otherwise deny creation of object.
>  b)If this is an OBJ_EXCHANGE,
> Add an item in the SELinux context list for this object.
> Inherit this Object's context from the parent, OR
> Label according to the arguments passed in on the create call.
> Create the Exchange.
>  iv.If command is delete and Context does permit object deletion:
> Delete object as specified by method call.
> Delete object's reference in the SELinux context list.
>  B.If ACT_CONSUME, ACT_PUBLISH, ACT_ACCESS, ACT_BIND, ACT_UNBIND,  
> ACT_DELETE, ACT_PURGE, ACT_UPDATE:
>  i.Determine if the Context of this Subject permits the noted action on 
> the target Object:
>  a)Search the map of object types; when the target Object's Type is found,
>  b)Search the resulting map for this Object's ID.
>  c)Call security_compute_av to determine if this Subject is permitted to 
> access the target Object with the Subject's context.
>  ii.If Yes: Allow
>  iii.If No: Deny

Use the avc functions rather than directly calling security_compute_av.

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