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.

3 0

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/

3 0

To make it more protected I think that it is interesting to confine some, let’s say, “untrusted applications”. Which basically means more restrictive control over the processes. Usually I use GRSecurity for that but this time I am using SELinux. Since I am dealing with RPM and Fedora use to be a reference (at least for me) in the support to the SELinux, most of the specs files were copied from Fedora including the policy. The policy should be well refined to fit my needs, but it will be the subject of another post.

Supporting SELinux involves to support not only the kernel part of SELinux (kernel-selinux-netbook), but to support a huge number of packages as you can see bellow:

audit

Part of these packages are not needed to make the SELinux work, but they are used by auxiliary applications which make SELinux easy to deal with. As you can see, these packages provide dependencies on Ruby, Perl and Python for example. I think we just need the python dependency. The big difference between my packages and Fedora’s packages is the fact that I refuse myself to port the Java SELinux utilities

All the support to that packages (and also the devel version of them) are available at my MeeGo repo at:

http://meego.zimmerle.org/repo/security/packages/

To add SELinux to your image, you just need to add to your .ks file, the following repo:

repo   --name=security --baseurl=http://meego.zimmerle.org/repo/security/packages/

And you also need to place the SELinux package group in the package section:

@SELinux
kernel-selinux-notebook

An example of a kick start file can be downloaded here: http://meego.zimmerle.org/repo/security/build/meego-netbook-chromium-ia32-security-1.0.20100614.1459.ks

You can also download a SELinux MeeGo image at: http://meego.zimmerle.org/repo/security/build/

Here goes a picture of my netbook running selinux kernel:

The policy is not loaded automatically after the boot and the file system is not labeled yet. To load the policy just use load_policy tool.

1 0 ]]> Felipe Zimmerle <felipe@zimmerle.org> feed:d81b00955f076640b4980a1c3646a625 Mon, 14 Jun 2010 19:45:53 +0000 http://maemo.org/midcom-permalink-4225cacc7ae611dfbb11add48e9fc28ac28a http://zimmerle.org/2010/01/4x4-inclinometer-2/ For those who are interested in knowing how steep is your N900, or the
object that supports it. Meet the 4×4 inclinometer.

I developed it to use in my car, hence the name 4×4 inclinometer. Using this
application I can know the slope of the obstacles or the ground below my
car.

According to the manual of the car, it can be in an angle of heel of 45 degrees
with no problem, something higher than this is at my own risk. When I read
this information, just imagined the software for the N900:)

The current version depends on Qt 4.6 with the animation framework. The
animation is used to rotate the images of the car, smoothing the movement. I
am not an expert in gimp, so forgive me for the images poorly done. Next
version I will put a simple support for themes.

The intallations files are already in extras-devel, so you just need to
apt-get it.
And the sources are available at:

http://git.zimmerle.org/?p=inclinometer.git;a=summary

The car image and the application background are Trademark of Troller Veiculos
Especias S/A, http://www.troller.com.br

8 1 ]]> Felipe Zimmerle <felipe@zimmerle.org> feed:d81b00955f076640b4980a1c3646a625 Mon, 18 Jan 2010 12:12:14 +0000 http://maemo.org/midcom-permalink-c4b042d8044e11dfa0976705e20d45e145e1 http://zimmerle.org/2010/01/iptables-on-extras-devel-2/ The iptables package is on maemo extras devel. There is no support for connection state on the device Kernel consequently the NAT is not working. I tried to compile the modules, but I found myself in trouble trying to load them at the device. If you want to flash a kernel with support for connection state there is one available at my personal repository (read: mWall :: netfilter + ui for maemo for more information). Antoher discussion about that modules can be found at: http://forums.internettablettalk.com/showthread.php?t=30916&page=1

7 0 ]]> Felipe Zimmerle <felipe@zimmerle.org> feed:d81b00955f076640b4980a1c3646a625 Fri, 01 Jan 2010 22:13:32 +0000 http://maemo.org/midcom-permalink-ef9db7faf94f11de809ea5b339ae9c069c06 http://zimmerle.org/2010/01/tcpdump-lipcap-on-extra-devel/ For those who are playing with maemo and network, now are available at maemo
extras-devel {fremantle|diablo} the tcpdump package and its dependency (libpcap) working
like a charm

6 0 ]]> Felipe Zimmerle <felipe@zimmerle.org> feed:d81b00955f076640b4980a1c3646a625 Fri, 01 Jan 2010 13:52:11 +0000 http://maemo.org/midcom-permalink-758e8822f94f11de809ea5b339ae9c069c06 http://zimmerle.org/2009/12/mwall-netfilter-ui-for-maemo-2/ Something that certainly bothers me is the fact that i am always online independent of the network. I walk with my n900 in the pocket and sometimes I am using 3g, sometimes using wifi. I am jumping from trusted to untrusted wifi spots, and I have the strange feeling that maybe once (or more…) I will be part of a honeypot, malicious network or something like that.

As part of this type of network my device can be easily identified as an N900. (e.g. MAC address). Once the device is identified a person or a malicious software can start to guess passwords (rootme?) and can try to exploit softwares that are under development.

Avoiding been hacked on that situation I decided to write a small firewall UI for the n900 (netfilter/iptables back end), that allows me to block any incoming connection that is not authorized.

This is just a very first version of the firewall, a lot to be done yet. To install it on your device, check for mWall at my personal repository.

You can install my repository by clicking here: zimmerle’s repo.

I also provide in my repository: the iptables package and a kernel with support to iptables state match. The iptables binary was marked with the suid bit, allowing its execution by users without super powers. But this should be fixed in the next release.

Let me advise you that the firewall rules are not permanent, I mean, you need to run the firewall in every boot. It is under development

The code is available at: http://git.zimmerle.org

1 0 ]]> Felipe Zimmerle <felipe@zimmerle.org> feed:d81b00955f076640b4980a1c3646a625 Mon, 21 Dec 2009 03:16:47 +0000 http://maemo.org/midcom-permalink-3cb04db0f94f11de809ea5b339ae9c069c06