Thoughts?
Here are a few thoughts and questions I had after consulting the
SE-PostgreSQL documentation.
In SEPG, the contexts for the tables are created by using an extension to
the table manipulation statements. For example,
ALTER TABLE drink
CONTEXT = 'user_u:object_r:sepgsql_secret_table_t';
I propose that we use a similar mechanism for QPid operations. Any time
an operation is performed - creating a queue, bind to an exchange, etc -
the client app will pass a SELinux context as a named parameter. When
QPid calls the ACL module to see if the client is authorized to do the
action, the SELinux ACL module will note the context passed as the
parameter. If SELinux approves the action, then it will create a record
in an internal table with the new object's ID and its security context,
for future use. Any objects that are created as persistent will have
their context saved to disk.
Some security contexts will need to reside on disk as a bootstrapping
mechanism.
In order to ensure the contexts of remote clients, I propose using
Labelled IPSec as SEPG does.
Thoughts?
Thanks,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
