AclModule (which is pluggable). Can that not be implemented as a call to
security_compute_av?
yea, I think we might have enough abstraction. We might need to add a map of
IDs to the object list for SELinux. If that is needed I can volunteer to do
That's what I was thinking, as I took a look at
/qpid/cpp/src/qpid/broker/AclModule.h
...and its friends under qpid/acl. The data in AclModule.h looks like
it's a good representation of the various Actions we'll have to model.
We will need to model the security contexts pertaining to each item. For
example, you can have a file type for an index.htm file, of
httpd_sys_content_t. Contrast this to user_home_t. We might have a
queue, FinancialDataQueue, that should not be able to be read by the
webserver. FinancialDataQueue would have a type of fin_content_t. Since
the contexts are not stored in the Qpid objects themselves, the ACL plugin
will need to map each object to its context. If a user with type httpd_t
attempts to read from FinancialDataQueue, then the authorize call would go
something like this:
1. User Name = 'httpd'
2. Queue Name = 'FinancialDataQueue'
3. Lookup current context of user 'httpd' (that is a SELinux library
call, to find the SELinux user called 'httpd') and find its type to be
httpd_t
4. Lookup current context of queue FinancialDataQueue and find its type to
be fin_content_t
5. Call security_compute_av with the contexts, and pass or fail as needed.
Number 4 is tricky. I am not yet sure if SELinux contexts can be stored
for arbitrary named objects. On the filesystem the are usually stored in
xattrs. Dan?
Thoughts?
--
-----
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]
