Looking like the SELinux but less boring, the AppArmor is a Linux security module (LSM) which provides mandatory access control (MAC). The first distro to adopt the utilization of AppArmor was SUSE in SUSE Linux Enterprise Server 10 and in openSUSE 10.1. It is part of Ubuntu since the version 8.04 and the adoption increase version to version since more profiles are created.
Other software that is part of more and more applications each day is the D-Bus, adopted by GNOME and KDE as an inter-process communication mechanism, the usage of D-Bus allows the communication between different applications. It is used, for example, to provide the communication between a software Core with the UI. Due to the nature of the communication of certain applications (sensible data) is indispensable to have some control about who can acquire some interface or who can listen or send some message.
D-Bus daemon has support to mediate SELinux messages and there is also a D-Bus internal mechanism that has some control over the use of the bus, but none of this is related to AppArmor. There are some experiments that show that it is possible however the necessary patches (Kernel, libapparmor and D-Bus daemon) were not submitted to be part of the respective projects, as explained in the earlier post.
The patches on the experiment enable apparmor parser to understand the tag dbus, as illustrated on the example bellow (line 15). More information about the experiment and the syntax of the file can be seen in: https://lists.ubuntu.com/archives/apparmor/2011-September/001541.html
/home/zimmerle/hello.py flags=(complain) {
#include <abstractions/base>
/usr/bin/python2.7 ix,
/usr/include/python2.7/pyconfig.h r,
/usr/local/lib/python2.7/dist-packages/ r,
/usr/share/pyshared/PIL.pth r,
/usr/share/pyshared/lazr.restfulclient-0.11.2-nspkg.pth r,
/usr/share/pyshared/lazr.uri-1.0.2-nspkg.pth r,
/usr/share/pyshared/pygst.pth r,
/usr/share/pyshared/pygtk.pth r,
/usr/share/pyshared/ubuntu-sso-client.pth r,
/usr/share/pyshared/ubuntuone-client.pth r,
dbus bar.foo.hello acquire,
}
In order to ensure the functionality of the suggestion made in the post: D-Bus Loadable security module support, I decided to modify the AppArmor D-Bus daemon patches to make them compatible with the suggested model. And it is working like a charm.
The code of the current experiment can be fetched from:
http://cgit.collabora.com/git/user/zimmerle/dbus-apparmor-lsm.git/
Note that in this experiment I had to use the D-Bus internal functions/headers. I made little hacks in order to get it working but apparently, this is a good way to go.
Saturday, December 24, 2011
Friday, December 23, 2011
D-Bus Loadable security module support
While I was thinking about LSM mediations of the D-Bus messages, I found out a nice work that is being developed by the Ubuntu sec team in order to support the AppArmor mediation on D-Bus message exchange and service acquisition.
Having a chat with John Johansen (from Unbuntu sec team), he said that he was missing a loadable module support on the D-Bus. Allowing the support of different Linux Security Modules mediation without messing up the D-Bus daemon code, which does make sense.
I started to implement a little PoC about this loadable support, which consists in the following: the LSM modules can be dynamically loadable at the d-bus daemon startup. By copying a D-Bus LMS module to a given directory (which can be specified at the d-bus configuration) it will be loaded and registered.
The idea is to have independent modules, if possible use only the D-Bus functions provided by libdbus, however, of course, if needed symbols can be copied from libdbus-internal.a.
Despite the fact that the modules can be independent of the D-Bus internals, they must have at least one known function, this function should be named as “pre_init“, and receives the pointer to the D-Bus internal function “register_security“. The “register_security” function should be called by the module if it is loaded successfully. The “pre_init” function must return a “dbus_bool_t“: true if everything goes right or false if not. Note that audit can be also initialized by this function.
The function “register_security” receives as parameter a pointer to the structure “security_validations” that is part of dbus-security.h. The structure is illustrated bellow:
The structure “security_validations” defines the hooks and the name of the security module and also the function to shutdown the mediation. Two main hooks were needed, the first is the one responsible to mediate the message exchanges and the second is the responsible to avoid unauthorized process to acquire some service. The shutdown hook is not less important, but less used. Shutdown is only called when the D-Bus daemon is hanging out.
The current implementation of SELinux mediation needs more hooks to work than what I am offering in this PoC. Since the SELinux implementation has some performance improvements by doing caching, it will be necessary to create new hooks to gather some information before deciding whether some message is ok to go or not, but this may be a later discussion.
The patched D-Bus code is available at:
http://cgit.collabora.com/git/user/zimmerle/dbus-lsm.git/
And there is a dummy module at:
http://cgit.collabora.com/git/user/zimmerle/dbus-dummy-lsm.git/
Having a chat with John Johansen (from Unbuntu sec team), he said that he was missing a loadable module support on the D-Bus. Allowing the support of different Linux Security Modules mediation without messing up the D-Bus daemon code, which does make sense.
I started to implement a little PoC about this loadable support, which consists in the following: the LSM modules can be dynamically loadable at the d-bus daemon startup. By copying a D-Bus LMS module to a given directory (which can be specified at the d-bus configuration) it will be loaded and registered.
The idea is to have independent modules, if possible use only the D-Bus functions provided by libdbus, however, of course, if needed symbols can be copied from libdbus-internal.a.
Despite the fact that the modules can be independent of the D-Bus internals, they must have at least one known function, this function should be named as “pre_init“, and receives the pointer to the D-Bus internal function “register_security“. The “register_security” function should be called by the module if it is loaded successfully. The “pre_init” function must return a “dbus_bool_t“: true if everything goes right or false if not. Note that audit can be also initialized by this function.
The function “register_security” receives as parameter a pointer to the structure “security_validations” that is part of dbus-security.h. The structure is illustrated bellow:
struct security_validations
{
char *name;
dbus_bool_t (*bus_security_allows_send) (DBusConnection *,
DBusConnection*,
const char *,
const char *,
const char *,
const char *,
const char *,
const char *,
const char *,
DBusError *);
dbus_bool_t (*bus_security_allows_acquire_service) (DBusConnection *,
const char *,
const char *,
DBusError *);
dbus_bool_t (*shutdown) (void);
};
The structure “security_validations” defines the hooks and the name of the security module and also the function to shutdown the mediation. Two main hooks were needed, the first is the one responsible to mediate the message exchanges and the second is the responsible to avoid unauthorized process to acquire some service. The shutdown hook is not less important, but less used. Shutdown is only called when the D-Bus daemon is hanging out.
The current implementation of SELinux mediation needs more hooks to work than what I am offering in this PoC. Since the SELinux implementation has some performance improvements by doing caching, it will be necessary to create new hooks to gather some information before deciding whether some message is ok to go or not, but this may be a later discussion.
The patched D-Bus code is available at:
http://cgit.collabora.com/git/user/zimmerle/dbus-lsm.git/
And there is a dummy module at:
http://cgit.collabora.com/git/user/zimmerle/dbus-dummy-lsm.git/
Subscribe to:
Posts (Atom)