Ich möchte kurz darauf hinweisen, dass man keine EMail-Weiterleitung an GMX einrichten sollte (z.B. an der Uni). Dann kommen nämlich bestimmte EMails nicht an...

Schuld ist eine "Spamfilter"-Funktion von GMX; konkret betroffen sind Emails von Absendern wie Web.de, Yahoo.de und Absendern die SPF [wikipedia] konfiguriert haben.

Das Problem ist ganz einfach zu erklären:

1. Absender "support@web.de" schickt eine email an "beispiel@irgendwo.tld"
2. Der Mailserver von "irgendwo.tld" leitet diese Email weiter an den Mailserver von GMX
3. Der Mailserver von GMX sagt: Dein Absender ist "@web.de", aber der Server gehört nicht zu Web.de, deswegen nehme ich die Email nicht an.

Fazit: man sollte keine EMail-Weiterleitung zu GMX einrichten. (Die andere Richtung, die Weiterleitung von GMX an andere provider ist ok.)

[Update: Unter dem Begriff "Spamserver-Blocker" kann man diesen Filter aber auch ausschalten. Weiss nur keiner...]

Seitenbemerkung: GMX ist auch unfähig eine korrekte Browsererkennung zu machen - das tolle neue "Ajax" Webmail weigert sich mit dem 'umbenannten' (wegen Trademark-Rechten!) Firefox "iceweasel" oder anderen Mozilla-basierten Browsern zu arbeiten. Gecko is Gecko hat Details, wie man korrekt Mozilla-basierte Browser erkennt...

If you want to test your SIP setup (e.g. using ekiga), VoIP-info.org has a list of services you can call for testing, e.g. echo services, test recordings and weather forecasts.

1 und 1 (1 & 1), "world's largest Web hosting provider by known servers", which recently bought GMX (Germanys largest Webmail provider) and has a significant market share in the DSL retail market in Germany, added an instant messenger service.

The best: it's not just "yet another IM service", but just like Google, they have chosen the XMPP/Jabber protocol ("Extensible Messaging and Presence Protocol"). So they can interoperate. I've successfully tried exchanging data between GMX and Amessage, which I'm using for my IM.

Configuration was trivial in Pidgin/Gaim, pick Jabber as protocol; username and server are just these two parts of your email address. The password is the same as for your GMX services. This is set up in a few seconds.

Hooray for open standards!

GMX (genauer gesagt 1&1) hat inzwischen einen eigenen Instant-Messaging-Dienst. Dieser ist (genau wie Googles) Jabber/XMPP-basiert. Daher sollte insbesondere der Datenaustausch mit Google Talk funktionieren (allerdings keine Telefonate).

Verwenden kann man mit GMX jeden beliebigen Jabber-fähigen messenger, z.B. Pidgin (Gaim) oder Apples iChat.

Bei Pidgin ist die Konfiguration trivial - Protokoll Jabber; Benutzername, Server und Passwort genau wie die Email-Adresse. Spezielle IM-Namen muss man nicht kennen, sondern es sind einfach die Email-Adressen.

Der Datenaustausch von GMX funktioniert auch mit anderen Jabber-Diensten wie z.B. amessage.de. Im Gegensatz zu MSN und ICQ handelt es sich eben um ein standardisiertes Protokoll. Es wäre bei EMail undenkbar, wenn man nur an Nutzer des selben Providers senden könnte, oder?

Open Usability has a poll for the next default KDE theme or so. Oxygene or so.

However it lacks options... the first real question "which icon [...] showing the menu with all applications" is lacking the "None is appropriate" option.

The first icon has some windows on it. I don't want to configure windows. The second has a package on it, package manager. Next is a diary/notebook and a text editor. Looking glasses, the KDE logo, a computer and a help icon. I mean, there is nothing at all looking like an "applications menu" in there.

Other questions don't fit into the usability category too much - for example, there is a poll about the 'back' button in the web browser. And there are like three regular left pointing arrows and one which is a reload turned the other way. I'd pick the other three; any of them is fine. But I have to pick one...

Sometimes options are just stupid (e.g. offering a phone icon for email), and sometimes none is convincing (the chat icons, I actually find the 'small human figure' icons quite appropriate, but there was no such icon offered).

Speaking of icons - I'd really appreciate some new Debian artwork. Our web site is looking like it's from the 90s. If it werent for '2007' dates occurring on the first page, it would look like it hadn't been touched since then. Ubuntu and Fedora have really nice pages (layout wise, I'm not talking about the contents which I didn't look at). Gentoo is as miserable as ours. OpenSuSE doesn't do language negotiation and looks somewhat odd. Probably too 'wikiesque'. FreeBSD just got a facelift last year. The artwork looks like 2003 style to me, and that the page has a 'monospace fonts' feeling might even be intentional. I certainly don't want the Debian website to look like a "web 2.0 beta" application, but some modern 'serious' design would be nice to have.

Does anyone have a (partial?) policy for Tomcat on SELinux "strict"? It's definitely something I'd like to confine, however Java needs tons of permissions. Multiple ports, execmem, log files, fifos, on-demand extracted webapps and so on. :-(

Has anyone started on writing a policy for this beast? If there is any way to confine it actually, given that it's pretty much a system on it's own.

[Update: I'd like to point out that running tomcat on a SELinux 'targeted' system works fine by running tomcat in an 'unconfined' domain. Since tomcat usually isn't run with root privileges anyway, it's not that risky]

If you are trying to setup SELinux, a must-know command for you is "sestatus".

Example output:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 20
Policy from config file:        refpolicy-strict

If it doesn't say "enabled", there is no way it will work. :-)

If it says "Current mode: permissive", SELinux will not block any access (that's why it's called "permissive"). So if you still get an "access denied" error from your web server, your unix permissions are blocking the access.

When asking for help, please include which policy you are running (most likely you'll be running 'refpolicy-targeted', since that is the most usable out of the box). Writing e.g. "sestatus says enabled/permissive/refpolicy-strict" is really helpful, and not much to type, is it?

In a previous post, I claimed that SELinux uses a kind of object-oriented approach, and that this has several advantages over path name based access.

Since SELinux policy isn't actually a 'program', the term is somewhat surprising. It's just one fragement of "object oriented programming" that is available in SELinux, and actually a rather simple fragment. Also it's not how it's evaluated; but the OOP 'design pattern' of 'classes' is somewhat present in the SELinux reference policy. The syntax is kind of twisted, too.

Let me give you a simple example policy fragment:

type mylog_t;
logging_log_file(mylog_t)

This fragment defines a new type, and 'inherits' from the 'log_file' class. (you can think of "logging_log_file" as com.tresys.oss.refpolicy.system.logging.log_file if you are a Java freak)

The logging_log_file 'class' (which technically is a M4 macro, and maps to the SELinux 'typeattribute' 'logfile' - this would be called an abstract class in other programming languages) in turn will make mylog_t also be a "file_type" type attribute.

So above line means that the new mylog_t type will 'inherit' certain access rules. Namely those defined via the logfile type attribute or file_type.

This means that I can write policy to grant access on "any file" (e.g. for security scanners such as 'samhain' or the SELinux relabeling utilities, backup application, etc.) or just to any log files (e.g. for logrotate). Independend of where they live or who wrote the policy for them.

So if I write policy for a custom application, add mylog_t for files living somewhere in /home/myapp/logs, I don't need to modify the logrotate policy, because that policy contains:

logging_manage_all_logs(logrotate_t)

Macro names in the reference policy usually start with a namespace prefix. In this example, it's logging_. Since it uses M4 for processing the files, the syntax is largely determined by what is easy to use in M4.

Interest in my DBus inspector has been increasing. I received a couple of interesting mails these days. Two people have suggested I could add a command line version, which would be similar to "dbus-send", but use introspection data to assist in finding the appropriate values. There was also a request when I'll add invocation support to the dbus-inspector GUI (that's the big thing on my wishlist, btw.)

DBus-inspector was also packaged for Foresight linux, and I'll maybe upload a package to Debian these days.

[Update: first parts of the 'invocation GUI' are committed. It has a column for 'in' parameters that you can edit, and an execute button that is only enabled when you've clicked on a method. But it doesn't do actual invocation yet when you click that button.]

I didn't intend to write (ok, rant...) on this topic again, but a few days ago, this "AppArmor FAQ", was posted to the Linux Kernel Mailing list. Again, this is a lot of 'marketing stuff', and doesn't have the facts quite right...

Some quotes:

In the traditional UNIX model, files do have names but not labels, and applications only operate in terms of those names.

No. In the traditional UNIX model, filenames point to inodes, and the inodes contain data such as file modification dates and permissions. This is where SELinux stores the labels it uses for access control. In fact, the "unix owner" and "unix group" are pretty much the same thing as SELinux labels. And also work pretty much the same way.

Contrary to popular belief, AppArmor is *not* "Pathnames R Us", but rather "Use native abstractions to mediate stuff": when you mediate something, you should use the native syntax that users normally use to access the object.

Maybe the appropriate term would have been "naive abstractions"?

And, no, security systems shouldn't be designed around what a user can easily grasp, because that might just not work... it should be designed around the way resources are handled and how you can successfully restrict access.

"Contrary to popular belief", SELinux *does* use path names. Actually in a very convenient way for the users. So I wouldn't claim SELinux is really harder to use than AppArmor because of its use of path names.

The difference is that SELinux doesn't rely on the path names, but it still gives the user the possibility to use them. In fact, the only way I know to get a proplerly labeled filesystem is based on path names.

If I'd for example keep my web stuff in /home/www, I can tell SELinux that the appropriate label is httpd_sys_content_t by doing

semanage fcontext -a -t httpd_sys_content_t /home/www
restorecon -R /home/www

In AppArmor, I'd need to modify the policy for several applications to achieve this, because of it's dependency on path names. SELinux also uses an abstraction. One that is very convenient for users actually. SELinux does access control on object classes. What I'm doing in above example is to put these files into the "Web site data files" class. So please stop scaring people of "labels". That is just the technical term for what is an "object class", a concept every developer will be familiar with. (SELinux policy development has a couple of OOP-like features, btw., for example it is possible to give an application access to 'all log files'.)

There are, however, some true statements hidden in there:

We also acknowledge that pathname based access control requires a way to perform pathname matching in the kernel, and this comes at a cost higher than comparing object labels [...]

So by providing string matching in the kernel, AppArmor trades run-time performance to grant reduced administrative work.

It is however not obvious how large the difference in "reduced administrative work" is between AppArmor testing the filename "run-time" compared to SELinux using filenames to relabel files "on demand" (or, with restorecond, even on creation by using inotify).

What I still seriously dislike is the FUD spread by AppArmor people such as

Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have.

Why should this only be useful to "intelligence agencies"? Some people live in countries with very strict privacy requirements, and we might want to use these techniques to lessen the risk of leaking data. In AppArmor, I can copy a file with private customer data to the web server directory, and it becomes readable by the web server. In SELinux, the file will still be unreadable by the web server. Does that really sound like "only useful to intelligence agencies" to you?

Dear AppArmor people, please stop trying to invoke fear of the NSA, just to make people use AppArmor. That makes you look very untrustworthy, you know...

The SELinux kernel code is part of the Linux kernel, AppArmor is not. So in theory, that code has been reviewed much better than yours, and is maybe even less likely to contain a "NSA backdoor" than yours. Changes to SELinux are openly discussed on a mailing list, and go through peer review there. They foolow a very strict coding style, which makes review easier; obfuscated code doesn't have a place there. It's not like we were running a binary blob from the NSA we can't have a look at.

... I would appreciate that (any *init maintainers going to DebConf?) - but I won't be around. I missed the DebConf sponsorship deadline (which was end of January; since I'm currently devoted to getting my diploma done, I don't have an income, so sponsorship would be good); and even now (they're currently asking for reconfirmation) I don't plan that far ahead. I have no idea what the state of my diploma thesis will be back then in June. Probably not yet stressful, but I just don't know. So I can't commit to DebConf.

A pity, I'd really like to go to a DebConf again, the last (and only) one I was at was in Oslo in 2003. I don't think we needed to sign up that early back then; the school building we could sleep in (and use the showers) was fine with me.

And of course I'd also love to contribute some swing dancing 'course' to the social dancing event...

Wer Google AdSense auf seiner Homepage einsetzt, hat vielleicht schon die eine oder andere unschöne Werbung dabei entdeckt: dubiose Angebote, die beispielsweise mit dem 'gratis'-Download von Gedichten oder Hausaufgaben locken, oder mit kostenlosen SMS, die aber in Wirklichkeit ein überteuertes Abo-Angebot sind. Verbraucherschutz und Fernsehsendungen berichten ja immer wieder über diese Abzocke-Masche.

Solche Domains kann man mit der Filterfunktion von AdSense ausschließen. Eine entsprechende Liste gibt es hier, und ihr könnt dort auch weitere Domains eintragen. Ich werde sie dann prüfen und in die Liste aufnehmen.

Just yesterday I mentioned that DBus contains an own set of init-like scripts. From todays new DBus package in unstable:

  * debian/dbus.init
    + Add functionality to start/stop dbus dependent services based on their
      LSB header.
      Instead of installing an init script into /etc/dbus-1/event.d, services
      depending on dbus should from now on install a regular sysv init script
      and add an LSB header with "Required-Start: dbus".

So the dbus init script now adds a 'workaround' (likely, since this is done in DBus, not in sysvinit) for the missing dependency handling in sysv-style init, by taking care of the restarting itself. This is good, because init scripts aren't distributed into two places anymore (soon).

It probably highlights why we need to work on our init.

Gunnar Wolf commented on my recent series of init script posts. Thanks for the feedback.

The thing is that I've been doing a lot of Debian stuff these days (such as our GSoC coordination, and lots of stuff you saw in this blog). But I shouldn't... instead I should be trying to finally get my diploma thesis done.

I had my exams last july. If I had been focused, I could have been finished with my degree last christmas. Now it will likely by this fall. :-( All that is remaining is my final thesis. It should be written in 6 months, but I still havn't submitted my topic yet. So if you are wondering what took me 8 months already: I investigated two topics, but they didn't work out. Then I started researching for my 'current' topic, and I have a vision for it, but I still havn't managed to convince my professor (which of course is largely due to me not being able to convey this idea, and that the topic is in information management and representation, where it's probaly often hard to find a solid theoretical part. I have examples I'd like to do, and I hope they are actually convincing, but I have no idea how to 'prove' something here; it's too much about social aspects and human perception I guess, and I'm not really qualified or capable to do solid research in that field.)

(And as you can probably imagine, I'm pretty fed up with studying now. A year ago, I'd have considered to go for a PhD afterwards, but now I just want to get out, and work on my projects.)

Anyway, I got distracted. Back to the init topic.

I already posted this link: Init Hackfest, as well as a pointer to the initscripts-ng mailing list. I'd really like to get this topic on it's way for lenny. So please, join this effort. While I'd like to push it, I shouldn't; on contrary, I should suspend my Debian efforts.

As for your (Gunnar) suggestion on how to handle multiple inits: what's wrong with just including multiple init scripts in one package? They are not particularly large and compress well. A single init script package might already be bigger than all the init scripts.

The problem is more on how to write these init scripts; by the time we're done with this project, we might actually have hit 1000 init scripts. Yes; I didn't just make up this number: packages.debian.org has 890 hits for /etc/init.d; the init-like scripts in /etc/dbus-1/event.d not included. So if just want to add support to 5 alternate init systems, this means we would need to write 5000 new init scripts. Ouch. So we maybe should convert them to 1000 meta-init-scripts instead, and generate the 6000 real init scripts from them.

Please join the discussion, and lets get this project going, despite having to face such scaringly high numbers...

Today's post (previous parts) tries to show what benefits other init systems can offer.

I'm picking 'minit' as an example; not because it's the ultimate solution or anything, but because I happen to know it quite well. I used to be the package maintainer for some time, and I've also used it on an embedded system (where it was a perfect match). However, it's not very distribution-friendly; it's great when you can invest some time into configuring it (such as when building an embedded system) but not when it should ideally work automatically out of the box. The Debian package is still there, but it's orphaned. Still it's well written, clean code; there shouldn't be any bigger bugs in there.

The first thing to notice is that minit is tiny. It's statically linked, but only about 6.5 kb. Regular init is 86 kb plus some libraries (despite actually not doing much during init!). This makes it very well-suited for embedding.

But now for the benefits of minit over regular init:

1. Service monitoring. This is the biggest point: minit will keep an eye on the services and restart them when needed. (Another thing very useful in embedded situations, btw.)

Minit doesn't use the start/stop paradigm of sysv/shell-style-init. Instead it has a "run" script for every service. If a service is flagged as 'respawn', it will automatically be restarted when the run script quits; therefore the applications should not background themselves. This offers some benefits, for example the init process will be notified by the kernel of a termination, and can immediately respawn the service; in contrast to other monitoring systems suchas monit it doesn't rely on 'busy polling'.

2. Dependency handling. Minit handles startup dependencies. If a service lists another service as a dependency, it will bring that service up first.

3. Parallel startup. Unless an ordering is given via dependencies, minit will start the services in parallel.

4. Control apps. In minit, you don't start a service by running some random shell script. Instead you call "msvc -u servicename", which will signal minit to bring up the service (and it's dependencies). This would (there currently is no policy for minit) be especially useful in SELinux, but it also allows to e.g. give a user the permission of running "sudo msvc -u" without introducing a huge security hole, since this cannot be used to execute arbitrary scripts. "msvc" can also be used to check if a service is up. (Another benefit for embedded systems, since that removes the need for pid files, which then need a ram (writeable) filesystem)

I'll also give an example for a minit service:

A service is represented by a directory in /etc/minit which can contain various files. I'm going to look at getty/1 example; which will bring up a console login on the first terminal. There are three files:

• a symlink named 'run' to /sbin/getty, which is the daemon we want to bring up
• a file named 'params' containing the parameters for the getty application, one per line
• an empty file named 'respawn', since we want the login screen to reappear

This allows minit to start the getty with no overhead. There is no shell script being executed or anything (note: sysvinit also does this for gettys, but it's not being used much for other services).

Of course minit isn't perfect. I've already said that it isn't particularly distribution friendly. This is because it uses a lot of magic files (e.g. an empty file named 'respawn' to flag a service as needing to be respawned), and it's configuration files aren't easy to handle automatically. The often frowned-upon 'symlink farms' of sysv-shell-style init are much better here.

Another thing that is missing from minit is an automatic rollback of dependencies. If we told minit to bring up service 'a', which lists dependencies 'b' and 'c', minit will bring these three up. If we tell it to shutdown 'a', it will however not shutdown 'b' or 'c'. And unfortunately, even if we shutdown 'b', it won't shutdown 'a'. If you want a more complex dependency handling (or things such as runlevels), you need to do this externally. (An example is my 'enitdir' app, it adds runlevel support to minit, and allows switching of runlevels by replacing a symlink; Services are added and removed from runlevels by adding a symlink to the service into the runlevels directory. By using dnotify, this also takes virtually no CPU time.)

Minit also lacks a differentiation between a 'started' and a 'running' service. It has support for 'sync' services, such as e.g. mounting a filesystem. It will wait for this operation to complete before it starts services depending on it. However, there are services that will continue to run, while not being instantly available when the exec() was called. Sometimes it would be nice if a service could go into a 'started' state, then do some cleanup work, and then when actually running the real service signal minit that it's now 'running'.

As a last malus, minit won't print progress messages to the console. A minit boot is pretty much silent, directing it's output to some logging processes. There are good reasons for this (since services are started in parallel!), but it makes debugging harder, and users might be wondering what their system is actually doing (though some users prefer to see a colored 'busy' bar)...

I guess this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? I hope to have given an impression on where there is room for improvement in our current init to one or the other. Now we just need some people to actually work on a better support for other inits in Debian...

I've done a needed upgrade to my blog software. In this process, I've also been changing my blogs GUIDs. Unfortunately, this probably means that some planets or feed readers will recognize all of my postings as 'new'. Sorry about that. I'm not sure if I can somehow prevent it from happening.

Every now and then I receive a mail from someone complaining that the links to my blog entries are broken. Well, they aren't. The link tag has an appropriate value. However some applications (usually involving planet) prepend the feeds base URI to the GUID field or use it in other RDF places. And then some readers seem to not know about the link tag and use that instead. So I'm now using the permalink as GUID, so it should be a bit easier for some people, since they now can just click on my entries.

Ich finde es beängstigend, dass jemand, der praktisch täglich etwas fordert, dass gegen das Grundgesetz ist, CSU-Chef werden soll.

Ebenso unser werter Herr Innenminister.

... und dass das letztlich auch die offizielle CDU- und CSU-Position ist, dass wir uns von einem Freiheits- und Rechts-Staat zu einem Überwachungsstaat 'entwickeln müssen'.

(Übrigens sieht das auch der Deutsche Anwaltverein so...)

Die größte Gefahr der Terroristen ist doch, dass wir uns von diesen freiheitlichen Grundwerten verabschieden!

Vor diesem Hintergrund finde ich, dass Herr Schäuble zurücktreten müsste: wenn seine Meinung in solch einem Widerspruch zum Grundgesetz steht, so kann er doch nicht Innenminister sein!

"Einigkeit und Recht und Sicherheit"?

DebianMuc release party, add yourself now. Saturday, at the Flaucher (Isar).

Weather forecast for this week is great. Probably around 24 C on saturday, the warmest day this week I've heard. It will still be getting cold at night (after all, it's not summer yet, though we like pretending it is); so maybe we should meet rather early. Also make sure to bring some warmer clothes, too.

Anyway, there is the Wiki and our mailinglist for organizing the party.

"Beta" is short for "BETrAying". It means the web site isn't honest to you about the benefits for you, what they are doing with the data or what they are telling you.

Examples:

• Download services: 'all download slots are busy, please wait 15 seconds' - not true, but they just would like you to look at the ads for 15 seconds
• Social networking: Myspace claims "foo is in your extended network". Even when you are the Google robot or using an anonymizer. This is a hard-coded string, not a calculated connection.
• Most Web 2.0 services: we have no idea how to continue providing this service for free once our venture capital is used up.

So spelled out it would be like:

Sorry, we're not telling you the truth about our service and the benefits, and that's why we're calling the service beta; once we've found out how to do it right and still earn some money with it, we'll remove the beta sign.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script.

Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway.

So what does a typical init script in /etc/init.d do?

If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts.

A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code.

The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable.

Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there).

The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message.

An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.

[Update: next part]

I thought I could write a multi part blog series about init systems (with the obvious goal of convincing some more people we should properly support other init systems as well).

In the first step, I'll have short look at our current init.

First of all, our init isn't really /sbin/init from the sysvinit. The real work is done by /bin/sh, so usuall bash or dash. Using the latter can already cut down boot time for you by a few seconds, according to some people.

The init process is indeed used to kickoff the system, but it's in fact not doing much. Pretty much all it does is described by /etc/inittab. If you havn't ever had a look at this file, maybe you should now.

During a typical system boot, init is doing three things:

1. Start /etc/init.d/rcS
2. Start /etc/init.d/rc 2
3. Start the gettys (console logins)

So my claim that our init system actually is /bin/sh isn't really far off, is it?

Some random notes:

• Starting and stopping services is not handled by init, but these are just shell scripts invoked by the root user
• The only services monitored (and restarted) by init are the gettys. You could add other services, but the inittab approach doesn't scale very well with respect to automatic editing by package install script and such. That is strongly discouraged.
• Some users/services add their own monitoring because of that. MySQL has a shell wrapper for this, and packages such as monit also take care of checking for crashed services and restarting them.
• Debian has a script called invoke-rc.d, that should/must be used by package installation scripts instead of calling the init scripts directly.

Maybe tomorrow I'll write a bit about features of other init systems, and what benefits they offer. Maybe also on why the SELinux strict policy doesn't really like this way of starting and stopping services because of isolation issues. Or on that there are two types of things happening at init.

[Update: next post in this series.]

Don't use the browser name for capability detection.

I'd like to emphasize that. For example Google Groups won't let me upload an image to my profile, because I'm not running Firefox or Internet Exploder.

Well, I tried both Epiphany (which has a very clean and fast UI, unlike Firefox which is totally cluttered) and Iceweasel (which is Firefox, but with the trademark replaced). Both are using Gecko, Gecko/20070324 for Epiphany and Gecko/20070310 for Iceweasel. So I'm very sure they have the same capabilites as Firefox 2 when it comes to web sites.

If you want to test for Firefox's capabilities, use the Gecko version number.. Thank you.

[Update: it was suggested I point people to GeckoIsGecko.org, which has links on how to properly detect the Gecko engine, instead of relying on the browser name.]

[Update: Mike Hommey pointed out that the 'Gecko/date' string is mostly meaningless, and largely is the build date; it doesn't contain tree information. Instead you should be using the "rv: 1.8.0.11" part of the User-Agent. This is also what the getGeckoRv function on the howto linked from GeckoIsGecko.org does. Oh, and Firefox 2 is not gecko 2, but IIRC uses gecko 1.8.x, just like my Epiphany.]

You probably have read it alread Gaim will be renamed to Pidgin. Most likely because of AOL being unhappy with them using AIM in their name (although they support a dozen other messengers as well; getting rid of AIM in the name was also 'wanted' by the Gaim developers I guess).

However, such software renames eventually cause some problems. For example, will the API also be renamed? Will libgaim become libpidgin? Will the DBus interfaces change their name? A dozen of applications might be affected by that, including the popular AdiumX messenger for OSX. (One of the prettiest I've seen so far, btw.)

Other examples of such renames (and the problems caused by that) is the Mozilla chaos. Mozilla doens't allow to distribute modified versions of Firefox or Thunderbird under these names, so Debian has to replace the names (though most of our patches at some point are adopted by upstream, or they'd be okay with them, Debian also has the requirement that our users must be able to do their own modifications!). This is why etch just shipped with "Iceweasel" and "Icedove" instead.

However some web sites don't test for the browsers "Gecko" version, and for example Google Groups, when trying to set the profile image, tells me I need to run Firefox or Internet Explorer. Though I'm pretty sure the function would just work fine with both Epiphany (my primary browser) and Iceweasel.

The transition from "cdrecord" to "wodim" was a bit smoother. On the one hand, many application were already expecting functionality not present in the "official" cdrecord (and yes, Joerg, I know that your opinion might differ on that point - I don't care, nor does anybody else I know). On the other hand, it mostly affects programs included in the distribution, so they can be easily handled. There aren't random websites testing for it either, and custom scripts written by users can probably handled via a wrapper (this is much more difficult for libraries I guess, or the DBus API of Gaim. Fortunately for Gaim, these interfaces aren't used much, so it can be solved with a simple search and replace and recompilation in affected applications).

I think when more distributions switch from Firefox to Iceweasel because of realizing that it might be important to some of their users and recommend Epiphany because of it's smoother user interface, we might also see less websites doing incorrect browser capability detection.

I've written a small parser for iptables rules in Python, and made it output GraphViz data. Byte counters are translated to line width, packet counters to line color. Dashed lines didn't receive any data so far.

This is the result for my laptop's tiny firewall setup (generated by Pyroman; the double accept/drop/reject rules are mostly for cosmetic purposes, and counting data and packet totals. However the reject rule also does a 'cleaner' reject for TCP connections)

I've ran it on a much larger firewall (~100 chains, ~600 rules; a multi-homed firewall at our university), but it becomes to messy with the dotty layout algorithm. The firewall chains generated by pyroman are pretty flat; it generates one chain per client-server combination, the INPUT etc. chains are filled with source/destination filters, the services are filtered in the second level then. Also most of the traffic is handled by connection tracking, so it boils down to having one big accept line, with little going on beyond that.

So the visualization turned out to be only of partial interest (at least for Pyroman-generated firewalls. It could be useful if someone actually nests chains more levels deep).

Still there is some interesting stuff I might be going to try with the iptables-save parser I've written:

• pyroman could reload the firewall, keeping traffic counters where possible
• based on traffic counters for hosts and services, it could reorder entries in the firewall to optimize the firewall slightly (in the pyroman model, hosts and services can be reordered to a certain extend; I'm aware that this is not true for generic iptables rules. It might however be still helpful for some users to get suggestions on how to order their rules. It's also unlikely this will have a large performance impact in general, unless you have one really heavily used service and didn't place it first on your own...)

[P.S. Anyone aware of a GTK/Gnome application or library for visualizing graphs?]

[P.P.S. Bernd Zeimetz has been running it on some really complex firewalls. I guess it really could benefit from a layouting algorithm optimized for this kind of graphs, dotty can become kind of messy. :-) Maybe I'll make an interactive version, where you can see for each chain the incoming and outgoing flows or so, but not try to make such a huge graph.]

Most of the time when I lookup the IP addresses used in FTP and SSH scans, they belong to some network in china. And apparently the last two times when the Asus website was modified (this time exploiting another unpatched vulnerability in Microsoft Internet Explorer, with .ani files), they were loading exploit code from certain servers in China.

Well, I guess you just cannot trust their regime; if it isn't actively encouraging the hacking activities, it at least completely fails to do something about them (you might recall that China tries to censor much of the Internet, but apparently they aren't able to firewall off hackers going out?).

It's hard to tell what their motivations are. I guess it's military interests (i.e. having points of attack in case of a war) combined with industrial espionage.

To me this means, that I can't really trust developers from China, and that I better double-check their code. While I don't assume them to be bad guys, you never know what their government might force them to do. Sorry about that.

It's finally out. Happy Easter.

Debian has just

• Updated 'sarge' (aka: new 'oldstable') for a last time
• Elected a new project leader (congrats, Sam)
• Released Debian 4.0 'etch' (aka: new 'stable')

Yes, it's finally out. And I hope it has the high quality you've come to expect for Debian releases (which is probably why it takes us so long, apart from supporting 11 architectures in this release).

Congrats, and a big thank you to all those involved, especially our release managers.

I've upgraded an old woody box to etch these days. Live - I've been telling people they need to find a replacement for this machine for years now, but it's still around and playing an important role.

And with 'woody' I mean 'a woody heavily played around with, with a couple of backports and exotic stuff like XFS, a custom 2.4.25 kernel with grsecurity'. Especially the latter was why I was afraid of doing the upgrade.

In a first step, I incrementally upgraded everything to sarge (well, at least where the backports weren't already newer than sarge). I installed the stock sarge kernel, and prepared a reboot.

The reboot was then done out of schedule, because the machine died on it's own - it has been crashing about 1-2 times a year, and it hadn't happened for some time. Judging from the logs, it was that old problem again.

At second try it came up with the new kernel: I always forget to enable init ramdisks in the bootloader when switching from a custom kernel with every needed module built-in.

I then continued upgrading to etch, pretty much one service at a time.

Some things (I didn't do a full list; the box was running to many modified versions of packages of this being useful as upgrade reports to the release team, and it's a bit late in the schedule, too) where upgrading didn't work out of the box:

• Incompatible configuration file changes: amavis, courier, monit
• OpenLDAP refusing to load one of the third-party schemas
• Newer Courier POP/IMAP is incompatible to drac, breaking SMTP-after-POP
• Configuration changes of saslauthd breaking SMTP-AUTH
• IMP3, a webmail interface, doesn't work with PHP5. It has been replaced by IMP4 in sarge, however I'd like my users to be able to keep on using it for some while (and I need to find a way to migrate e.g. the address book over). I consider this a major upgrade annoyance with PHP5, that it no longer allows "return false;" in some situations (if you want to return by reference, you need to use a named variable). The behaviour of "get_class" also has changed in an incompatible way.

The bad news: there is still something wrong with the machine. It doesn't crash, but spits e.g. the following to dmesg:

amavisd-new: page allocation failure. order:5, mode:0xd0
 [<c013aa08>] __alloc_pages+0x2f8/0x370
 [<c013aaa5>] __get_free_pages+0x25/0x40
 [<c013e0b2>] kmem_getpages+0x22/0xc0
 [<c013ed0a>] cache_grow+0xba/0x180
 [<e0aebe1e>] xfs_bmap_read_extents+0x36e/0x540 [xfs]
 [<c013ef3a>] cache_alloc_refill+0x16a/0x220
 [<e0ae80fd>] xfs_bmap_alloc+0xe0d/0x1c60 [xfs]
 [<c013f3e4>] __kmalloc+0x74/0x80
 [<e0b389c9>] kmem_alloc+0x59/0xc0 [xfs]
...

I'd like to propose a Init Hackfest for Debian when etch is released.

Debian includes several init systems, including sysvinit, runit, minit, initng and upstart. However, only sysvinit is really supported, and others can be used in a compability mode (and most of their benefits are gone then). So there is some work to be done here. Some init scripts probably could also use some cleanup. :-)

Shortly after the release of etch is probably the best moment to work on such key parts such as the init system, since many packages are affected. I suggest to provide patches to the package maintainers and do uploads to 7-day delayed.

If you are interested, maybe you could add your name to the wiki page? I also think the mailing list initscripts-ng-devel at alioth is appropriate for discussion.

I've been added to Planet GNOME (thanks jdub!), and this post is just to say hello!

I havn't been a large GNOME contributor so far (I was the Debian maintainer for Galeon some years ago, thats about it), but I recently started a small DBus related project (for exploring the DBus APIs of programs), dbus-inspector, which is now hosted in the GNOME subversion repository.

Other GNOME-related projects I'm thinking of:

• DBus hook, an application that allows you to easily setup ECA rules (event-condition-action) for DBus signals. E.g. to start your music synchronization tool when you plug in your mp3 player, whatever, in a rather generic way. Mount your network file server when you connect to your home wireless network, etc. - preferrably in an easy to understand way
• MP3val GUI, right now a tiny PyGTK wrapper around the MP3 validation and repair tool mp3val (you can't imagine how many MP3's are broken in one way or another, fortunately most errors are ignored by most players or only affect e.g. seeking) could use some extended functionality.
• Pyroman, a firewall configuration tool with some nice capabilities (rollback on error, debugging, very fast and efficient, Python or XML configuration files) could use an easy to use UI. It doesn't expose you to all the complexity of iptables, but instead lets you work in a "client, server, service" way of configuring the firewall, generating a somewhat sane layout of tables automatically.
• Flow analysis and visualization of iptables rules

I'd like to say thank you for all the great work you did. Having been a Galeon power user, I'm by now quite convinced of the "keep it simple" approach, and I have the impression that not having so many options means that I get more work done (since I don't waste time playing around with infinite options). Thanks for that. And for providing me with a pretty and unobtrusive work environment for the last 8 years or so.

These days I picked up the Debtags AI topic again (so yes, development is alive, not the AI).

Some people will remember this topic, it was a Google Summer of Code project. The project didn't really complete back then.

Since my thesis isn't coming along too well (I don't know how to explain to my professor what I'm trying to achieve...), I've been playing around with different stuff. So I've picked up the Debtags AI again.

Back at the end of the GSoC or sometime later last summer, I had started a rewrite of the Debtags AI stuff in C++ for performance reasons. I also had some ideas on how to make it scale better and on how to improve the results. I think I've reached an interesting state now; training time of the AI is down to a few minutes (remember it was a few days when the GSoC started?), so I managed to cut off another order of magnitude. Evaluation of a text against the database (i.e. for every tag) happens in the fraction of a second.

This AI is turning out quite well now. I have one more idea for a trick that could improve the results from an algorithm side, and one from the data side. Enrico is already looking at how to integrate it with the web apps. :-)

And I also want to scale it up further. How about using it to classify web pages by their text content? I already have an idea on how to get some good training data... maybe I should consider writing a business plan instead of a diploma thesis...

Some more comments on AppArmor, since some people might see my previous post just as being disappointed by seeing it in Ubuntu, and not much work on SELinux.

First of all, I should note that I don't have any SELinux systems I'm responsible for anymore. They still run SELinux in strict and are doing well, but I'm no longer responsible for them. So I'm actually pretty much out of SELinux development nowadays. I did some occasional policy merge to monitor policy development, and when I tried VMware, I even setup a SELinux system to check the current state. But I wouldn't call myself an active developer or even user. So I don't think I'm as biased as you might think I am.

Some things why I don't trust the AppArmor people:

• their website is incredibly full of marketing blah-blah such as "AppArmor is the most effective and easy-to-use Linux application security system available today" (effective as in what?)
• their Wiki/FAQ states wildly inaccurate things about SELinux such as "To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries." (no, you don't need to recompile and relink all your applications...) - and they even contradict themselves to some extend; on one hand they claim that you don't need to modify applications for use with AppArmor, on the other hand they highlight it as a feature that you can patch your apache for AppArmor to get some more security for embedded interpreters such as PHP. This is pretty much the same as with SELinux.
• they state such misleading things as "every user should give each system an afternoon's test to decide which is a better match for their needs." - sounds good at first sight, but how many admins are able to evaluate the security of a kernel-based security solution such as AppArmor or SELinux in one day? What this actually is, is an encouragement for admins to pick the security solution because of ease-of-use, not because of security considerations.

Instead they should be honest about what AppArmor can, and what it can not do. I don't doubt that it can be used to make exploits with specially crafted PDF files in evince and such simple viewer applications a lot harder, but their security is not as thorough and complete as SELinux. They are potentially vulnerable to some attacks caused by their path name based approach, or that they cannot do MAC for files with unpredictable names such as most of /proc (e.g. /proc/1234/cmdline), any kind of sockets or when file descriptors are passed from one application to another.

They should also admit that since SELinux initially assigns file labels by very similar pathname/filename patterns as AppArmor uses, it maybe isn't that much harder to setup in this aspect... In fact, it's much easier in SELinux to add an additional location for font files, since all the application policies don't need to be modified or reloaded, just the new font directory needs to be relabeled. In AppArmor, you'd need to modify an 'abstraction', then reload any policy that depends on this abstraction (you probably can only reload all at the same time, so that's not too hard).

To anyone with a tiny bit of computer science knowledge, it should also be obvious that the performance of reconstructing the file path and matching it against a large set of filename globs (AppArmor) necessarily is slower than just using the security label in to the files attributes (SELinux, where this globbing was done once when doing the relabeling); any performance difference that shows that SELinux is slower than AppArmor is probably caused by SELinux doing a lot more security checks than AppArmor. So even AppArmor could benefit from using labeled security...

I'm cool with saying that AppArmor is easier to get started with than SELinux, but they need to be honest about the differences to SELinux and the problems with AppArmor.

Ubuntu got AppArmor support.

This is bad news. AppArmor is a weak design. IMHO it gives the users a false impression of security, while leaving too much open to bypass security.

But the biggest problem IMHO is that noone at Ubuntu seems to be working on their SELinux support. All I've seen is Ubuntu users breaking their system to a point where they didn't know how to fix it in the attempt to install their SELinux packages. The packages are mostly a 1:1 copy of the Debian packages I guess, but for example their new 'upstart' init-replacement likely isn't capable of actually starting a SELinux enabled system. Oh, and Debian didn't include the relevant package in any 'stable' release, Ubuntu had it in 'universe' since 'warty'. Right now, feisty will include the package, though it reportedly can't be installed.

In the example used in the blog, evince is maybe protected from exploits by bad PDF files, but if you do a cp /usr/bin/evince /tmp and run that copy, all the protection is gone. A symlink might already be sufficient! So AppArmor is heavily relying on the user playing nicely.

You might want to read this Article at LWN about AppArmor and why it's having a hard time getting into Linux mainline and "Security Anti-Pattern: Path based access control" in Joshua Brindle's "SecurityBlog" for a detailed article on the weaknesses in AppArmors approach.

And their constant claim of being easier to use than SELinux isn't true either:

the 'learning' mode itself will only generate you an incomplete policy. It's about as much as you can achieve in SELinux by transforming audit errors to allow rules using the "audit2allow" tool. Maybe even less; for example when an application accesses a font file, SELinux audit2allow will generate a rule that allows access to all font files (since they have the same type). This doesn't rely on any directory globbing magic, but because there is a type for font files. I expect that future versions of audit2allow will actually recommend which interfaces to add instead of just listing raw allow statements.

AppArmors 'abstractions' seems to match what is called 'interfaces' in SELinux, except that interfaces in the SELinux reference policy are well documented and much more extensive. The 'abstractions' offered look like an early, incomplete version of the old NSA policy to me, before this was restructured to become the 'reference policy'.

Interaction between processes also seems to be completely ignored by AppArmor. So it seems to me that "preventing evince from trashing your home directory when opening a malicious PDF file" is pretty much all you can do with AppArmor?

But again, this isn't so much about bashing AppArmor or Ubuntu. I'm just disappointed that noone at Ubuntu seems to work on the more sound and solid SELinux. Most of SELinux is already in Ubuntu (inherited by their Debian roots), but it's lacking some integration work and such. Ubuntu is often said to be more agile than Debian and better at adopting new technologies, but in my experience, this often is limited to 'visual' stuff. If Debian were better at recruiting new people (for example in the SELinux section, we also seriously lack manpower), I'd probably be annoyed by Ubuntu 'trying to be first with all the pretty stuff' (yes, saying this would not be fair, that's why I'm putting it in quotes). Right now I'm mostly happy that they 'divert' many newbies off Debian and to their huge forums. Although it occasionally means I need to help an Ubuntu user to fix his system when he doesn't get any help there.

Launchpad, Ubuntus proprietary (!) bug tracker has received a facelift.

I'm deliberately calling it a facelift, because I still don't understand it. It sure is a lot prettier than Debians bug tracking, and it likely has some really nifty features, too, but I'm totally lacking the basics:

Have a look at this bug for example. It's about the Intel ipw3945 driver being unstable on systems with SMP and load when using WPA2 encrypted networks.

Launchpad says "fix committed" for linux-source-2.6.17, but I still havn't found out in which revision of that package. Or how I could actually find out how they fixed the bug. Or how I could access that information.

Nor have I found any way to access changelogs for the packages.

I just filed Intend-to-package bug number #416996:

* Package name    : stereo
  Version         : 2.0 beta
* URL             : http://www.mono-project.com/Stereo
* License         : LGPL
  Programming Lang: C#
  Description     : Mono (.NET) extension for running
                    multiple applications

Stereo is an extension to the Mono (.NET/C#) platform for running multiple applications at the same time.

As you probably know, C# is a language using a bytecode, called CIL: Common Intermediate Language. Using code in an intermediate language has benefits for platform and operating system independence (Java is the most prominent example of this approach), however it also means an overhead when running the applications. Various approaches have been tried to remedy these effects, such as JIT (just in time) compilers translating the bytecode to native code when needed.

Applications running based on such bytecodes tend to use more memory than regular applications (for example, they need to keep the compiled code in writeable memory, whereas regular applications can use shared read-only memory for this), and you probably have heard many people complain about the memory usage of Java and .Net applications. Some people even claim the Linux .NET platform is called "Mono" because you can run at most one such application at the same time.

That how "stereo" was born: an extensions to run two (or more) applications in the same mono environment, thus reducing the memory overhead significantly, and making it useful for more people.

Future versions should even be able to run Python (using IronPython) and eventually Java applications in the stereo runtime. It is also planned to add support for multiple user operation. So eventually, it will be able to replace your whole system. The project will then also change it's name to Multics, to reflect it's unique multi-user capabilities. At least if we get enough funding by Dunc-Tank, who is currently sponsoring all our development efforts.