Joshua, I don't think getting SELinux into the broker directly is a good option. My preference is to have SELinux as an ACL pluggin.
As indicated above, there seems to be interest in using 3rd party ACL mechanisms to manage access control. I certainly think it's worth the effort to figure out what needs to be done in order to make the ACL module sufficiently abstract to achieve the above. For starters I think AclModule.h has a reasonable abstraction. The current tests for ACL is more of integration type and assumes ACL file based approach. If we go down the above route we would need to think about how to abstract some of these test cases into a mechanism independent manner. The obvious choice is to have them in the form of unit tests. Regards, Rajith On Wed, Feb 18, 2009 at 1:58 PM, Joshua Kramer <[email protected]> wrote: > > Hey, that'd be great! I may also post to the SELinux mailing list. After > looking over the SELinux documentation and some other resources, here's what > I've found. > > There are a couple of ways we can go about this. The first way, is to use > pseudo-contexts to load ACL's stored in SELinux into QPid ACL's. (Here, > 'context' means a SELinux context.) To accomplish access control in this > manner, we need to do the following: > > 1. Create some pseudo-contexts representing QPid objects (things like > queues, exchanges, etc.) > 2. Go to a file on the filesystem and read in text-based user names. > 3. For each name, compute the target contexts that it is allowed to > access... and convert those into QPid ACL's. > > I do not think there is a way to call SELinux and ask it, "give me a list of > all the users in the QPid Type, and the things they can access..." But I > may be mistaken. There are some third-party SELinux tools for which the > source is accessible, so I may peruse those tools. > > The second way in which we can integrate SELinux into QPid is a bit more > complicated. Instead of using the built-in ACL's, we can go into the data > structures holding the various QPid objects (queues, exchanges, etc.) and > add elements for SELinux security contexts to each object. We would then > place calls to security_compute_av before each call that manupulates an > object, to determine if that particular operation was permitted. > > The second way requires more work because it would be tightly woven into > many different parts of the broker. The first way is less work because it > merely implements an ACL plugin on top of SELinux. > > So, this is becomes a philosophical discussion. Should we implement QPid > ACL's on top of SELinux, or implement SELinux in the broker itself? > > Cheers, > -Josh > > On Wed, 18 Feb 2009, Carl Trieloff wrote: > >> Date: Wed, 18 Feb 2009 12:51:01 -0500 >> From: Carl Trieloff <[email protected]> >> To: Joshua Kramer <[email protected]> >> Cc: [email protected], [email protected] >> Subject: Re: Access management with QPid >> >> Joshua Kramer wrote: >>> >>>> remote interfaces for ACL. Cross >>>> posting to the dev list, as I don't remember who was prototyping/ >>>> implementing this. >>> >>> I am playing with pulling the ACL information from SELinux. Currently, >>> I'm determining the best SELinux method to use to get the ACL's we need. >>> >>> Cheers, >>> -Josh >>> >> If you think you know what to do I can forward your ideas to someone on >> the SELinux team if you want comment. Some of the guys on SELinux sit one >> floor below me ;-) >> > > -- > > ----- > 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] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
