New SE-DBUS patch
mjricka at epoch.ncsc.mil
Fri Jun 25 05:43:46 PDT 2004
On Thu, 2004-06-24 at 17:11, Colin Walters wrote:
> On Thu, 2004-06-24 at 10:43 -0400, Matthew Rickard wrote:
> > The patch does still need some work. One remaining issue is that
> > dbus_connection_get_unix_fd() needs to be able to handle the case of
> > multiple file descriptors. Any suggestions on the best way to do this?
> I'm a bit confused as to how this case can arise. From my reading of
> the code, DBusConnection only has one DBusTransport, and a DBusTransport
> only has one fd. Am I missing something?
That was my impression too, but Havoc mentioned in his response to the
initial patch that this wouldn't always be the case. Perhaps he can
give some more details on this?
> If this could happen, it seems to me we should return a list of
> contexts, and the avc would check each one, and if any of them would be
> denied, then deny the operation.
This seems like the logical way to do it.
> > Also, the #ifdefs should be cleaned up,
> Yeah - it would be nice if we could use an approach more like Linux,
> where the SELinux types and calls are hidden behind a generic LSM
> interface. If we had a generic security abstraction layer in D-BUS,
> then the need for #ifdef would be greatly minimized. That's probably a
> fair bit more work though.
That would probably be the ideal way to do things. If we decide to go
this way we'll need to determine exactly where this security layer
should hook into. If not, we can probably still clean up some of the
#ifdef uses in the current code.
> - We probably need to wrap openlog/syslog in dbus-sysdeps.c?
Yeah, we should do that.
> - It looks to me like table_free_service_sid is unnecessary, since
> dbus_free already handles NULL
We still need to sidput() these sids here to decrement their ref
counts. Or do you mean table_free_service_name()? That can be replaced
by a simple dbus_free() for the reason you mentioned.
More information about the dbus