SE-DBUS updates
Havoc Pennington
hp at redhat.com
Sat Jul 24 16:36:53 PDT 2004
Hi,
Cool stuff, thanks. I've hacked on the patch for a few hours now, mostly
rearranging things to match D-BUS naming schemes and other conventions.
I figured it would be easier to just do this than explain it.
I changed some other random details which I'm happy to explain if anyone
cares, but it's mostly nitpicks.
I don't seem to have the DBUS__ACQUIRE_SVC etc. macros, I changed
configure.in to look for these, I guess they are probably in rawhide.
Anyhow, this means I haven't compiled this patch and chances are 99% it
doesn't compile.
The "can connection A talk to connection B" stuff is now correct, I
think.
However, I think "can connection A own service Foo" stuff was not quite
right. There are two ways to go here.
In the attached revised patch, all config-parser.[hc] changes have been
removed for now, but services.c:BusRegistry still contains the
services-to-sid hash table, though that is probably wrong.
Here are the two ways to go as I see them, and I am pretty sure the
first one is right.
1. There is a global mapping from services to sid. This mapping is
associated with BusPolicy and thus global to the bus daemon.
Like <allow user="foo"/> this could only be used
in <policy context="default"/> and <policy context="mandatory"/>,
not in the per-user or per-group policies.
There's no allow/deny going on here, just a service to
SELinux context mapping. So maybe the syntax is:
<policy context="default">
<association service="Foo" selinux_context="foo_t"/>
</policy>
(Could definitely think of better names)
These would be all merged into one table with "last one wins"
semantics, but first "default" policies are merged and second
"mandatory" policies are merged, each one in order.
The code changes might be:
- document in dbus-daemon-1.1.in
- add bus_policy_append_default_selinux_association()
and bus_policy_append_mandatory_selinux_association(),
call these from config-parser.c as the associations
are seen
- implement these in BusPolicy; to optimize lookup, after the
config is fully parsed, the two hash tables can be merged
- clean up the code in services.c that sticks the
table in BusRegistry, use the table in BusPolicy instead
This shouldn't involve BusPolicyRule at all I don't
think.
2. There is a mapping from services to sid associated with each
connection. In terms of the code, the services to sid table
would go in BusClientPolicy, rather than BusPolicy.
In this case, it's possible to have:
<policy group="wheel">
<association service="Foo" selinux_context="foo_t"/>
</policy>
in addition to the default/mandatory policies option 1 allows.
So we need to store a service to sid table for all of
default, mandatory, each possible user, and each possible group.
The code changes might be:
- add to BusPolicy another four fields analogous to the existing
ones, but replacing all "DBusList of BusPolicyRule" with
"DBusHashTable" mapping service to sid
- add BusPolicy functions that append to these fields,
and call them from config-parser.c during parsing
- extend bus_policy_create_client_policy() to
build up the service-to-sid map that applies to the
given client
- clean up the code in services.c that sticks the
table in BusRegistry, use the table in BusClientPolicy instead
This shouldn't involve BusPolicyRule either afaics.
In short, the two options are to put the service to sid mapping in
BusPolicy or in BusClientPolicy. (If in BusClientPolicy, BusPolicy still
holds the whole set of service-sid pairs that _may_ apply to each
client, and generates BusClientPolicy from there.)
To me it should be in BusPolicy, I'll probably code that up, but
alternate arguments are welcome (or comments on the patch in general,
I'm sure I screwed it up in dozens of ways).
Havoc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus-selinux.patch
Type: text/x-patch
Size: 24735 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/dbus/attachments/20040724/5eea4102/dbus-selinux-0001.bin
More information about the dbus
mailing list