Joshua Kramer wrote:
You are correct - it's trivial to store the SEL context in a file, much as the ACL's are stored in a file currently. But it presents this problem: suppose I intend to have an SELinux ACL declaring that the server queue called "SecretData" can only be read by users with type accounting_t. Now, suppose I have misconfigured my ACL, and instead, this restriction is applied to the queue "SecretDatz". When a process creates the server queue "SecretData" (or writes to that queue that already exists), it will not know that the queue, which ought to be constrained, is not. It might write some confidential data to the queue. When a bogus application with the type user_t attempts to bind to and read from "SecretData", the ACL won't match (as it is looking for "SecretDatz"), and the binding and read will be successful. This failure can result in the unauthorized read of data, and it is silent. It would be much safer to throw an exception on any security failure; we can enable the throwing of such exceptions if we define the security context of the queue when it is created via the calling application, instead of via a file.
Yes, I agree that makes sense. Sounds like we need to revise the Acl interface to support that.
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
