From: Joshua Kramer <josh@globalherald.net>
To: SE-Linux <selinux@tycho.nsa.gov>
Subject: Authorization Workflow for Message Queueing Platform
Date: Tue, 12 May 2009 13:03:43 -0400 [thread overview]
Message-ID: <4A09ABEF.50605@globalherald.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
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?)
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
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
[-- Attachment #2: SEL-Qpid-Workflow.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 27181 bytes --]
next reply other threads:[~2009-05-12 17:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 17:03 Joshua Kramer [this message]
2009-05-18 14:15 ` Authorization Workflow for Message Queueing Platform Stephen Smalley
2009-05-18 17:02 ` Joshua Kramer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A09ABEF.50605@globalherald.net \
--to=josh@globalherald.net \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.