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-subscr...@qpid.apache.org
