QPid SELinux Models (was Re: Sepcifying Keyword Arguments)

[Joshua Kramer <jo...@globalherald.net>]

> Is this the right approach for passing the SEL context though? We don't 
> pass ACL permissions for queues that way, at least at present. Would a 
> config file that defines any necessary mapping work?  I would prefer to 
> keep SELinux specific stuff within an ACL implementation plugin if at 
> all possible.

There are a few ways to think about this.

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, that is a simplistic example, and it can be mitigated through other 
rules.  If you deny all applications with type user_t, you would simply 
run into a situation where no app could read from "SecretData" because 
there is no SELinux ACL allowing it.  However, if you have a complex 
ruleset, problems like this can remain hidden.

On the other hand, we could run a check, so that users with type 
accounting_t could call a method to ensure that the queue is constrained. 
However, that adds complexity and risk, and is outside the scope of an 
ACL.

Finally, I envision a time when we can apply security contexts to 
individual messages, much as you can with individual tuples in 
SE-Postgresql.  Doing this through a file-based ACL mechaism will not 
work.

In short, given these two choices:

a) If instance V of thing X has name Y, apply permissions W and allow Z
b) If instance V of thing X has permissions W, allow Z

...I'd much rather b.  Permissions ought to be embedded in a thing itself, 
rather than attached to the name of a thing.

This does shed light on a problem, however.  Even if I am securing the 
queues on the call to create_queue (instead of from an ACL file), how do 
we prevent tampering with the files containing queue definitions for 
persistent queues?  If a malicious entity crashes the server, tampers with 
the SELinux ACL context definitions for queues that already exist and 
restarts the server, this could cause queues that were previously 
constrained to become non-constrained.

I would suspect, however, that an individual that is able to bypass a 
properly secured SELinux system to this depth has already caused other 
forms of damage... but assumptions like this are dangerous when trying to 
secure a system, no?

Where might I be wrong here?  Or right?

Best,
-Joshua Kramer

-- 

-----
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:dev-subscribe@qpid.apache.org

Re: QPid SELinux Models (was Re: Sepcifying Keyword Arguments)

[Gordon Sim <gs...@redhat.com>]

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:dev-subscribe@qpid.apache.org