Loadable security modules for D-Bus

[John Johansen]

On 01/10/2012 01:25 AM, Lennart Poettering wrote:
> On Mon, 09.01.12 18:17, Felipe Zimmerle (felipe.zimmerle at collabora.co.uk) wrote:
> 
> Heya,
> 
>> Then it raise another interesting question, having the "security
>> hooks", no matter if dynamic loaded or not, the security
>> implementations which will relay in those hooks will be hosted
>> together with D-Bus or it can be something that is maintained under
>> its own community? Not sure about the benefit of this, maybe it reduce
>> the work to maintain a code which is not D-Bus specific by the D-Bus
>> community.
> 
> This must be in D-Bus itself. It would be a very bad idea to standardize
> on an internal security API for this and give any guarantees about its
> stability -- which you'd have to do if such a project would live outside
> of D-Bus proper.
>
sure keeping the API stable so projects can live outside of D-Bus proper
has a cost.  Some times its worth it, sometimes it isn't. For D-Bus I am
not convinced a stable API for code living outside the project is worth it.

However modularization, where the the code lives as part of the project
and is tied to a specific build, like kernel modules, might be, at least
from a distro packaging pov. Splitting the packaging of D-Bus into a base
package and a package for each security module to break up dependencies is
more appealing than, creating separate D-Bus packages to support different
security solutions. Of course, there are other considerations that might
not make it the correct solution for D-Bus.

> This is also in your own interest since this insures that the apparmor
> code doesn't bitrot that quickly. Like in the kernel, you want
> everything upstream.
>
of course getting code upstream is the sane thing to do.

>> Thiago's affirmative is correct, independent of been one or more
>> supported frameworks, the distribution already know which security
>> framework will be used and can compile the code to provide the
>> mediations for "n" supported frameworks.  However in this case, at
>> least "n+1" runtimes dependencies will be placed. For example, having
>> support to SELinux depends on libselinux.so.1 and libaudit. By having
>> support to
>> SElinux and AppArmor we will have three dependencies:
>>
>> * libselinux.so.1 (form libselinux1 at ubuntu)
>> * libapparmor.so.1 (from libapparmor1 at ubuntu)
>> * libaudit.so.1 (from audit-libs at fedora)
>>
>> And so on, for each framework that a given distribution wants to
>> support. It means that by installing D-Bus the user will have to have
>> installed the libselinux and libapparmor and also libaudit,
>> independent of been using one, two or none LSM mediations.
> 
> Yeah, well, if distros are crazy enough to support multiple parallel
> security architectures it's their own problem. If they don't want the
it certainly has a support cost, regardless it is something that is done
and is just a data point in choosing the correct solution for D-Bus

> deps this pulls in, then they should just compile the package twice, and
> provide alternative packages for installation. But honestly, people who
that is one possible solution

> do crack like this, deserve the pain this brings them, you don't have to
> care.
>
> In general I believe that the explosion of the test matrix which
> multiple parallel compiled-in security archs would mean is a bad thing,
> not a good thing.
> 
>> It is also important to note that depending on the security
>> restrictions of a distribution, the startup of a given mediation could
>> be mandatory, for example, without proper startup of the SELinux
>> support the dbus-deamon won't start. This seems fair, although this is
>> only a possibility since I don't have a real use case.
> 
> Not really. In Fedora our policy is that if selinux is off in the kernel
> it is off in userspace too, and userspace should continue to work fine
> without. No point in being more catholic than the pope.
>
sure
 
>> Regarding the to startup the things in systemd, I have the feeling
>> that we want to startup the security policies/hooks/whatever before
>> start any service, analogue of what we have on the network: the
>> iptables/ebtables starts before the network interfaces.
> 
> We load the SELinux policy from within PID 1 in systemd, and do the
> proper domain transition afterwards. THis is carefully optimized so that
> we don't do more than necessary, don't leak any resources from before
> the policy loading, and are as secure as needed. I am quite sure that
> the right place to load global security policies is in the init process
> itself, otherwise you'll necessarily get ordering problems and the
> security policy would take only incomplete effect on PID 1 itself. (One
> day, should Ubuntu come around and switch to systemd as well, I'd expect
> that we'd add similar code like our SELinux loading logic for AppArmor
> as well right into PID 1.)
> 
I don't think it is necessary for the policy load to be built into PID 1,
but it certainly makes life easier if it is aware of the policy load and
can do the correct domain transition.