Using the “ulimit” controls over process resource use it is possible to limit RAM for processes and to limit the number of processes per UID. The problem is that this often is only good for accidental problems not dealing with malicious acts. For a multi-user machine each user needs to be allowed to have two processes to be able to do anything (IE the shell and a command that they execute). A more practical limit is five processes for a single shell session (one or two background jobs, a foreground job where one process pipes data to another, and the shell). But even five processes is rather small (a single Unix pipe can have more than that). A shell server probably needs a limit of 20 processes per user if each user will have the possibility of running multiple logins. For running the occasional memory intensive process such as GCC the per-process memory limit needs to be at least 20M, if the user was to compile big C++ programs then 100M may be needed (I’ve seen a G++ process use more than 90M of memory when compiling a KDE source file). This means that a single user who can launch 20 processes which can each use 20M of memory could use 400M of memory, if they have each process write to a pages in a random order then 400M of RAM would be essentially occupied by that user. If a shell server had 512M of RAM (which until quite recently was considered a lot of memory - the first multi-user Linux machine I ran on the net had 4M of RAM) then 400M of that could be consumed by a single hostile user. Leaving 100M for the real users might make the machine unusable. Note that the “hostile user” category also encompasses someone who gets fooled by the “here’s a cool program you should run” trick (which is common in universities). I put my first SE Linux Play Machine [1] on the net in the middle of 2002 and immediately faced problems with DOS attacks. I think that the machine had 128M of RAM and because the concept was new (and SE Linux itself was new and mysterious) many people wanted to login. Having 20 shell users logged in at one time was not uncommon, so a limit of 50 processes for users was minimal. Given that GCC was a necessary part of the service (users wanted to compile their own programs to test various aspects of SE Linux) the memory limit per process had to be high. The point of the Play Machine was to demonstrate that “root” was restricted by SE Linux such that even if all Unix access control methods failed then SE Linux would still control access (with the caveat that a kernel bug still makes you lose). So as all users logged into the same account (root) the process limit had to be adequate to handle all their needs, 50 processes was effectively the bare minimum. 50 processes with 5M of memory each is more than enough to cause a machine with 128M of RAM to swap to death. One thing to note is that root owned system processes count towards the ulimit for user processes as SE Linux does not have any resource usage controls. The aim of the SE Linux project is access control not protection against covert channels [2]. This makes it a little harder to restrict things as the number of processes run by daemons such as Postfix varies a little over time so the limits have to be a little higher to compensate, while Postfix is run with no limits the processes that it creates apply to the global limit when determining whether user processes can call fork(). So it was essentially impossible to implement any resource limits on my Play Machine that would prevent a DOS. I changed the MOTD (message of the day - displayed at login time) to inform people that a DOS attack is the wrong thing to do. I implemented some resource limits but didn’t seriously expect them to help much (the machine was DOSed daily). Recently I had a user of my Play Machine accidentally DOS it and ask whether I should install any resource limits. After considering the issue I realised that I can actually do so in a useful manner nowadays. My latest Play Machine is a Xen DomU which I have now assigned 300M of RAM, I have configured the limit for root processes to be 45, as the system and my login comprise about 30 processes that leaves 15 for unprivileged (user_r) logins. Of recent times my Play Machine hasn’t been getting a lot of interest, having two people logged in at the same time is unusual so 15 processes should be plenty. Each process is limited to 20M of memory so overflowing the 300M of RAM should take a moderate amount of effort. Recently I intentionally have not used swap space on that machine to save on noise when there’s a DOS attack (on the assumption that the DOS attack would succeed regardless of the amount of swap). Now that I have put resource limits in place I have installed 400M of swap space. A hostile user can easily prevent other unprivileged users from logging in by keeping enough long-running processes active - but they could achieve the same goal by having a program kill users shells as soon as they login (which a few people did in the early days). But it should not be trivial for them to prevent me from logging in via a simple memory or process DOS attack. Update: It was email discussion with Cam McKenzie that prompted this blog psot.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://en.wikipedia.org/wiki/Covert_channels

Share This

Here's a question that has bugged me for a while, and to which I've never found a satisfactory answer. How do people handle mailing list moderation when they have spam filters active? For instance, I get a lot of spam in the moderation queues for the Apache mailing lists I moderate. Sometimes gmail flags it as spam, and I can't quite say it's wrong... I mean the body of the email that's help up for moderation is often full of spam words. But the moderation message itself isn't really spam. I'm afraid of confusing the filter if I let it through. I guess this is where an open source system might be better, as you could simply put a rule in saying "if it's a moderation email, don't even bother looking at the keywords". Gmail's awfully convenient though... anyone else out there with the same problem?

Akoha s sister company, Standout Jobs, has been hosting Montreal on Rails for quite a while. We figured we d get into the act. So we re sponsoring the first Montr al Python gathering tomorrow. Sadly, we don t really have enough space for everyone, so we re commandeering the Standout Jobs offices upstairs. After all, what good are siblings if you can t ask them for favours? I will actually be on a train to Toronto, so I m going to miss David Goodger talking about crazy awesome stuff he does in Python. But you should go! Intimidated? Don't think that Python is for you? Worry not! Python programmers are friendly, charming, and helpful. Montr al Python 1
Thursday, 7 February 2008
18:30 21:00
Standout Jobs
3981 boul. St-Laurent #615
Free admission ( Website Facebook Google Maps )

On the 20th of January (8 days before the start of linux.conf.au) I advertised contest to write blog posts related to computer security for the conference Planet [1]. The aim of the contest was to encourage (by money prizes) people who had no prior experience in computer security to get involved by writing blog posts. The rules permitted security professionals to enter but only for an honourable mention, the money was reserved for people without prior experience. The money that I initially advertised was a fraction of what was reserved for prizes, the idea being that if the contest went well then the prize pool could be easily increased but that if it didn’t go well then there would only be one small prize for someone to win by default. At the time I considered a single entry winning by default to be the worst case scenario. The eventual result was that there was only one entry, this was from Martin Krafft on the point of keysigning [2]. Martin has prior experience in the computer security field which excludes him from a money prize, but he gets the only honourable mention. From a quick conversation with him it seems that his desire from entering the contest was to get his ideas about weaknesses in the keysigning process spread more widely, so this seems like a fairly ideal result for him. I agree with Martin that there are significant issues related to the keysigning process, but my ideas about them are a little different (I’ll blog about it later). His point about people merely checking that the picture matches on the ID and not verifying what the ID means is significant, the fact is that the vast majority of people are not capable of recognising ID from other countries. Other than requiring passports (which differ little between countries) I can’t think of a good solution to this problem. Congratulations Martin! It is a good post and a worthy entry. Now as to why the contest failed. I spoke to some people at the end of the conference about this. One delegate (who I know has the skills needed to produce a winning entry) said that I advertised it too soon before the conference and didn’t give delegates time to write entries. While I can’t dispute his own reasons for not entering I find it difficult to believe that more than a small proportion of delegates had that motivation. The LCA Planet had some lengthy posts by other delegates, and the guy who won second prize in the hack-fest spent something like 20 hours coding on his entry during the conference time (I suspect that my contest had the potential for a better ratio of work to prize money). Also the 8 days before the conference started was a good time to write entries for the contest. One suggestion was that I propose that the conference organisers run such a contest next year. The problem with this is that it’s difficult to say “I tried this and failed, could you please try it too”. If nothing else I would need some significant reasons to believe that the contest has the potential to be more successful before attempting it on a larger scale. If the contest had been backed by the LCA organisers then it might have been more successful, but that possibility seems unlikely (and there is scope for an event to be more successful than mine while still being a failure). The reason that I consider it unlikely that official support would make it more successful is that I first advertised the event on my blog (syndicated to the conference Planet). Everyone who has a blog and attends the conference can be expected to have read about it. I then advertised it on the conference mailing list which I believe had as subscribers a large portion of the people who have enough spare time to create a blog specifically for the purpose of entering such a contest. A blogging contest related to a conference but which had a wider scope (IE not limited to one field but instead covering anything related to the conference) might be successful. If someone wants to run such a contest next year then it’s probably worth doing. Of course I have not given up on the plan of getting more people involved in computer security, expect to see some blog posts from me in the near future with other approaches to this. Suggestions would be appreciated.

• [1] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [2] http://madduck.net/blog/2008.01.28:on-the-point-of-keysigning/

Share This

New Jersey is one of the states holding presidential primaries on this Super Tuesday and since you asked, I voted for John McCain. The chief reason for my vote is of course the war against Islamic terrorism. Now that we are finally gaining the upper hand in Iraq, we can't afford to elect someone who will fail to see victory through. Mind you this isn't necessarily a reason not to vote Democrat. The anti-war wing of that party has been thoroughly marginalized. Hillary atleast has a commendable reputation for viciousness. Even Obama has made some encouraging remarks (ok that was probably a red herring but I have the audacity to hope you see.) But while the Democrats do not take the anti-war crowd seriously, they do depend on them for a great deal of their funding. A Democratic president might feel the need to throw them some bones inadvertantly screwing up things in the process. On the Republican side, Huckabee might leave tactical planning to Jesus. Romney would toe the line but there is no sign that he has any original thoughts on the matter. While I continue to support the President, it must be admitted that this whole war is stretching out as long as it is because mistakes were made. We need options beyond "staying the course" and "cutting and running" and McCain a military hero and early supporter of the surge could be the one to find them. The other big issue is supreme court appointments. One, possibly two justices may need to be replaced in the next four years. We need to ensure that the court does not veer leftward again as it will inevitably do during a Democratic administration. Here there is a big split in the Conservative establishment. Ideologues consider McCain to be insufficiently pure and worry he will end up appointing another Souter or O'Connor (both appointed by Republicans it should be noted.) Pragmatists point out that McCain is viewed more favorably than Romney or Huckabee amongst the independent and moderate voters who will be crucial to victory and that even the slight chance of a bad choice is better than the certainty of a bad choice if Clinton or Obama get to make it. Social issues are important to many Republican voters and in this area too there is some grumbling about McCain being too liberal. Some have even suggested that if McCain beats Huckabee or Romney, a Democratic victory and four years out of power would be preferable in order to bring the GOP back to the straight and narrow. Although this contingent is loud I frankly don't think they have the influence people think (As evidenced by the actual performance of Huckabee or previous champion Fred Thompson.) When push comes to shove, they will rally behind the party candidate especially if McCain makes a bona fide social conservative (Huckabee himself?) his vice-president. On economic issues, the president's job is to not interfere and let business run itself. I don't see any of the Republican candidates being much different in this regard. Or the Democrats for that matter. [Careful readers will have noticed I have avoided mentioning Ron Paul. Paulestinians, consider this carte blanche to send me your long, rambling, incoherent screeds about how Dr. Paul has the answers to everything. Because God knows I haven't read enough of them lately.] Update: Kevin asks what I think about the candidates in terms of "geek" issues such as net neutrality, DMCA etc. IMO there is not a whole lot of difference between the major candidates on these issues. Republicans one would think would be more beholden to corporations in general. Democrats on the other hand have a closer association with the media who are behind many of the sillier IP laws. Overall, I don't think it ought to be much of a factor in choosing the president even for Free Software types. Rather we should focus on the legislative branch (in Congress as well as the states) which holds the real power here and in the court of public opinion.

Best(*) Firefox extension ever: Long Titles (Spotted on http://xkcd.org/about/) (*) PS: Of course Open in browser and Generic URL creator are also way cool.

libqt3-compat-headers is a debian package containing headers from qt3 to help migrating from qt2 to qt3.
This is long ago. Qt people laughed at me when I asked about how long ago that would have been. Apparantly, this package is still build-depended upon by 66 different debian packages. A big bunch of them are probably just leftovers from the past. The rest is probably a 5 minute job (+build time) pr package. For me, it kind of makes the packages look kind of unmaintained. grep-dctrl -sPackage -FBuild-Depends libqt3-compat-headers /var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_source_Sources to see the full list. I just filed bugs with patches on 3 random of them.

... finally I got my blog up again and I start with yet another lame post My latest security backports to the upstream abandoned mozilla 1.8.0 branch are now available at http://people.ubuntu.com/~asac/mozilla-security/moz-1.8.1.12a-backports.tar.gz. Those patches should cover all security related fixes that landed on the 1.8 branch (firefox 2) as of 2.0.0.12 RC3. I noticed that I didn’t really release any of the post-mortem security patches released in debian and ubuntu. So, here the patchsets for the 1.8.0 branch that contains them all:

• firefox – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-ffox-all-1.8.1.12.tar.gz


• thunderbird – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-tbird-all-1.8.1.12.tar.gz


• xulrunner – http://people.ubuntu.com/~asac/mozilla-security/moz-backports-xul-all-1.8.1.12.tar.gz

Those tarballs ship quilt patch directories. This means that the sequence to apply them cleanly can be found in the contained series file. To apply them to MOZILLA_1_8_0_BRANCH checkout, just copy the directory contained to your checkout (name the directory patches if you like) and run Have fun!

In the past I was not blogging small things if they were not worth a full blog entry on their own (or if I did not have the time to make up a full entry of it :). Inspired by the example of Raphaël Hertzog <hertzog@debian.org> with "News for Debian developers" for <debian-devel-announce@lists.debian.org>, I am intending to do the same on a monthly basis about my own Debian related work. This first entry about January 2008 also covers a few things from the last month of 2007. General News

• Trusted Computing
  
  After having taken over some rotting ITP bugs, Debian has now all the important packages to support Trusted Computing on platforms containing a TPM chip. The packages are not in good enough quality for release, but there is still some time left to fix that. Looking forward to make lenny supporting TPM properly out of the box, as well as aiming for making Debian the best TPM enabled distribution available.
  
  Currently, the TSS software stack consists of trousers, tpm-tools, opencryptoki, libengine-tpm-openssl, and ecryptfs-utils.
  
  
• Smartcards
  
  I am using smartcards since a while to hold GnuPG, LUKS, and OpenSSL keys/certificates. Thanks to Jonas Meurer <mejo@debian.org> for applying a fix and a patch of mine to cryptsetup. Together with my uploads of gnupg-pkcs11-scd, pam-pkcs11 and pcsc-omnikey, I can now use Debian out of the box with smartcards for authentification, not relaying on patched or private packages anymore.
  
  The next aim is to integrate smartcard support into debian-installer. It should be possible to use/store keys or certificates for encrypted filesystems directly from/to a smartcard during installation time.
  

Package News

• botan-devel
  
  The Botan library is maintained upstream in a stable release branch and a development release branch. Before, I was uploading as versioned source packages, botan1.4 and botan1.5. To be a bit more consistent, the two source packages are named botan and botan-devel now.
  
  
• gitosis
  
  Tommi Virtanen <tv@eagain.net> has written a marvelous tool to securely manage hosted git repositories, named gitosis. Having always looked for an elegant sollution to maintain git repositories through push/pull over SSH only, this package made an excellent addition to the Debian archive.
  
  
• gnunet
  
  GNUnet, more precisely the gnunet, gnunet-gtk and gnunet-qt packages where mainly maintained the last years by Arnaud Kyheng <Arnaud.Kyheng@free.fr> with me playing co-maintainer.
  
  Arnaud has become busy within the last months, so I took over a more active role on its maintenance. Currently, all gnunet related packages are in sync and in its latest upstream version available in the archive. There is even a new sibling, gnunet-fuse.
  
  
• icedove-l10n
  
  After one and a half year of pushing its maintainer without any effect at all, I finally took over the unmaintained icedove-locales package in October 2007. I immediately changed the package to the proper naming scheme (icedove-l10n-*) which was an outstanding issue since August 2006.
  
  In the last weeks, I have added unofficial localizations for Galizian, Nepali and Ukrainian, now supporting 38 localizations in total. Icedove localizations are now in good shape again, always matching the Icedove version and no longer lagging behind.
  
  
• iceowl-l10n
  
  Following iceweasel-l10n and icedove-l10n, there are finally also localizations for iceowl (Mozilla Sunbird) available. Populating packages for iceowl-extension (Mozilla Lightning) from the same source package is a bit trickier package-wise, but will be available soon too.
  
  
• iceweasel-l10n
  
  In September 2007, Robert Milan <rmh@debian.org> on behalf of the Catalan/Valencian Debian translator team asked me to remove the iceweasel-l10n-roa-es-val package. Unfortunately, this localization is related to a long standing cultural and political dispute between the Catalan speaking Spanish people and the City of Valencia. Additionally, the localization itself is of poor quality. Of course, I removed the package in unstable immediately and prepared an upload for stable at the same time.
  
  As usual, me asking something on debian-release results in first beeing ignored, then denied and third, two month after my request, beeing privately asked to upload nevertheless. This is one of the reasons I sometimes fully understand fellow maintainers not carring about stable at all anymore, it has become indeed too much of a hassle.
  
  
• traceroute
  
  For the last decade, Debian was shipping an implementation of traceroute originating from BSD. After I took over the package in late 2006, it became clear to me that Debian should not maintain its very own version of traceroute. Therefore, I replaced traceroute in August 2007 with an implementation from Dmitry K. Butskoy <Dmitry@Butskoy.name>. Apart from the fact, that this modern implementation is better in every way (faster, cleaner, less bugs), it has an active upstream maintainer and is used by different other Linux distributions too.
  
  
• syslinux
  
  Thanks to the work of Robert Milan <rmh@debian.org>, syslinux has now 64-bit CPU detection in unstable (2:3.55-2) and experimental (2:3.60-2) again.
  
  

Team News

• Debian Forensics
  
  Unfortunately, Debian has at the moment very few forensic related packages in the archive.
  
  Christophe Monniez <dfence.242@gmail.com> maintains a lot of forensic related packages on behalf of his Debian based forensic LiveCD. Beeing interested to see them in Debian, I am mentoring him now how to merge them properly into Debian where possible, and maintain them in the official archive. We have formed an Alioth project for this purpose. Packages are maintained in git, everyone is welcome to join.
  
  
• Debian Website
  
  After having offered my help to maintain the Debian Consultants list, I got added to the webwml team. Doing Debian consultancy myself, this is just another way of helping out Debian from time to time by adding, removing and updating some entries of like-minded people in a list.
  
  

Well I've had a busy weekend, but I'm sober now. I made a new release of xen-tools, which has a couple of minor bugfixes and not much else. I also released a new update for Debian of the xen-shell which fixes a couple of bashisms. Finally I've managed to sign up two new users to my anti-spam proxy. Hopefully they're very happy. In real news I painted about 1 square meter of my flat, (we're now into week three of painting a single room...), and replaced five light bulbs:

My eyes! The goggles do nothing!

Now I need to install a request tracking system (otrs2) and catch up on significantly outstanding RT status updates. I'm getting hopeless again. Maybe I should just give it all up and become a plumber. Plumbing is easy: Water goes downhill. The rest is just regulations and a willingness to get dirty...

Links in Markdown can be done in a couple ways. First, similarly to HTML links, where you place the link next to the anchor text, like this:

  I am a [Debian](http://www.debian.org) Developer.

Or, if you feel this clutters your paragraphs too much, you can choose an alternate syntax, which I prefer (particulary handy for very long links):

  I am a [Debian][] Developer. Bla bla bla...
    [debian]: http://www.debian.org

There is however a gotcha with this alternate syntax, namely, anchor text with spaces in them. This works fine:

  I study Computer Science in [this University][].
    [this University]: http://www.ua.es

But this does not:

  Some years ago, I started studying Computer Science in [this
  University][]. Bla bla bla...
    [this University]: http://www.ua.es

This actually happens quite a lot when formatting the paragraphs in the editor, which made this otherwise-pleasant syntax almost a no-go for me. (Well, to be honest you could use it like this, but still:

  Some years ago, I started studying Computer Science in [this
  University][uni]. Bla bla bla...
    [uni]: http://www.ua.es

)

---

There is a beta version of Markdown in experimental that almost fixes the problem. This version introduces a new but similar syntax for links: you can omit the second pair of empty brackets. And when using that newer syntax, there is code in the program to change newlines into a space when looking for the link definition. It is not applied to the code path of the old syntax, though, which is a pity. This is all explained in bug #459885, with a patch as well (that applies both to 1.0.1 and 1.0.2). You can find packages with that patch applied here.

Last year at LCA Crispin Cowan suggested to me that I make a joint offer of a combined tutorial on SE Linux and AppArmor as a way of publicly comparing the two technologies. I ended up not accepting the challenge, among other things I had a long-term project going in production in early December that needed some ongoing support. Crispin’s plan B was to just give a lecture about AppArmor. Recently Crispin joined Microsoft [1] and John Johansen of Suse was going to give the talk in his place. The LCA people made a minor mistake by having the conference web site give the description of the tutorial option [2] (which I don’t believe was ever going to happen as I had not accepted the offer), but it’s easy to understand the webmaster copying the wrong description when the one person makes two offers (which I believe is not a common practice). So this morning I and about 150 other people were waiting in the main lecture theatre and no-one from Suse turned up. Being fairly audacious when the announcement was made that the event was officially cancelled I stood up and asked if anyone would like an impromptu talk about SE Linux instead. The audience received that idea quite well. My talk wasn’t as good as I had hoped, not having had a proper breakfast or any caffeinated drinks reduced my mental stack space. So I could talk well on one topic but when questions diverted me to a side topic I found it difficult to remember the previous point I was making. Fortunately when giving an impromptu talk with no notes or presentation materials the audience expectations for a consistent plan of the talk seem reasonably low. ;) I started by talking about my SE Linux Play Machines. Some of that material had been covered in previous talks at other conferences (such as at a previous SE Linux Symposium), but some things (such as my use of Xen) I had not previously covered, but none of it had been mentioned in a talk in Australia for a while. Having given an hour-long talk about SE linux yesterday to an audience with many of the same members I wanted to start by talking about something that they hadn’t heard before, and I was also wearing a Play Machine T-shirt (with the root password printed on it) [4]. After I finished talking about my Play Machines and started covering some of the same material as yesterday about a quarter of the audience left (which was fair enough). I then spoke about general SE Linux issues, largely in response to questions. I covered the differences between the policies (including the history of policy development), the JFFS2 XATTR development (and how SE Linux couldn’t be used on an iPaQ without it), issues of disk space usage for XATTRs for SE Linux labelling on various filesystems and how it drives the use of context mount options, poly-instantiated directories (including some discussion on how the actual storage location for such directories can be on a different filesystem and how this could be convenient when using encrypted filesystems), how Apache/PHP work in a SE Linux environment, and a lot more. I couldn’t resist mentioning to the audience the irony that I had declined a challenge for a joint presentation and then got a sole presenter spot (and a large audience) due to the Suse guy not showing up. For future situations I plan to load lecture notes from all my common talks on my iPaQ. Then next time I have such a speaking opportunity I can give a better prepared talk. Update: It turned out that the LCA people had been informed that the Suse talk was cancelled and had made a mistake, see this link for details.

• [1] http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx


• [2] http://linux.conf.au/programme/detail?TalkID=210


• [3] http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html


• [4] http://www.cafepress.com/play_machine

Share This

I live in a cooperative living group, and during the fall semester a person who we’d invited to live with us who is a dwarf and relies on a scooter for most of his transportation decided he’d like to move in. Unfortunately, while he can get out of his scooter and come inside by himself, we had no stepless entrances such that he could bring his scooter inside to protect it from the angry Cambridge winter. Mmm, frozen batteries. So, we’re a coop and we maintain the house ourselves—so we decided to build one, of course. A ramp up to the back porch! Nevermind the fact that we need to sink four-foot foundation holes in the ground in January. We got started right away at the beginning of IAP, while people were still trickling back into town from all over the country. First we surveyed out where the posts should be sunk: Then it was time for excavating the holes where concrete would eventually be poured. This involved a power auger of DOOM: It’s advertised as a 2-man tool. Two 200-pound construction workers, that is. We had to put four people on it plus one person with a shovel clearing dirt to make it manageable, and even then it was a pain. There’s a delicate rhythm you have to get into to avoid getting the bit stuck—DOWN. UP. CLEAR. And inevitably there are rocks and roots that have to be dealt with. We lucked out with a fairly warm weekend to do the digging on, but on the first day we still had to deal with a couple inches of frozen ground: There was also some fun stuff involving having to clear away our (frozen) mulch containers and use a concrete cutter on a weird old concrete pathway that used to run through the same area: Next we mixed and poured concrete: And placed hardware in the concrete to hold the posts: Framing: Eventually it became functional, woo: And done! (except for metal handrail): This all took place over the course of about three weeks. And now our scooter-bound housemate can bring his wheels inside! The house still isn’t totally accessible to wheelchairs/scooters, but at least the first floor is. It really brings me pride to see things like this go from start to finish here. We can do it! This guy who is moving in has really influenced my life—he’s really good at making people feel comfortable talking to him, and for me it’s gone from “wow this is awkward, I have no idea what to say” to “talking to a person with different physical abilities and characteristics seems normal”. And that’s made me a better person.

I'm a bit tired after driving up to Munich for the Android developer meeting, hosted by Google, and being "on" all day, but it was worth it. I was a bit apprehensive that it might be too 'introductory' in the sense of the Google guys telling you in person things that you could have easily looked up on the web, without spending a bunch of time driving around Austria and Bavaria. Fortunately, that wasn't the case. There was some of that, but also plenty of unstructured time to chat with Dan Morrill and Jason Chen, the two Google "Developer Advocates", who are both very friendly, informative and informed, approachable and put a lot of energy into what they do, despite being a bit tired from flying over from the US. It was nice to get a chance to talk with them, and considering that the platform is still changing, useful as well, because they were definitely listening to what people had to say to them. My thanks to them for a job well done. Here are some "impressions" I took away - note that they're not what anyone said, just ideas I got about what they said:

• Source code is being released when handsets ship because they want to work very closely with the hardware partners to make sure the phone experience is good (they said this). They want to "set the bar high", and they probably run the risk of someone snatching the code and slapping together a phone if they let out the source code to early. (They definitely didn't say this, it's just me connecting the dots).
• Despite interest for 'other languages', it really looks like they want everything to go through Dalvik in some way or another. Clearly, at some point in the future, there will be specs for writing Dalvik byte code.
• They won't talk about the upgrade strategy, something I asked about. I want to know that as a developer, I won't be stuck with N combinations of things that I have to support over the years. I want to know how they'll minimize that pain, but they're not currently able to discuss it.
• Talking with other people attending, there seemed to be some doubts about security and permissions for user data, since Android is moving away from the j2me "everything is private" model, to a model where data can be shared between apps, which opens up lots of good things, but also some potentially bad ones as well.

There's still really a sense of Android continuing to evolve, in a true spirit of openness. I liked that, as it means there is space for people to tell Google what they want, rather than simply being given a finished product and told that that's that... but then again, I would, being the open source guy that I am. I didn't get to show off Hecl quite as much as I would have liked to, but I did get to mention it a few times, so I guess I did ok.

I speculate that most of what we do for Debian squares with what others do for their respective distro. Thus, it should be possible to identify a conceptual workflow applicable to all distros, consolidate individual workflows on a per-package basis, and profit from each other. Jonathan let me have the after-afternoon-coffee slot of the Distro Summit for an impromptu discussion on the various workflows used by distros for packaging. The discussion round was very short-notice and despite the announcement sent to the conference mailing list, only ten people showed up: two people familiar with Fedora, and ( versus ) eight Debianites. Regardless, I think the discussion was success- and fruitful. We were able to identify a one-to-one mapping between the Fedora and Debian workflows, even though we use different techniques:

• both distros separate original software ( orig tarball ) from modifications made to fit the software in with the rest of the distro.
• Fedora keeps the .spec file, which references the original tarball, alongside any patch files in a per-release directory in their CVS tree, e.g. /mdadm/fedora8 and /glibc/rawhide. To obtain a source tree, the contributor checks out the CVS subtree, downloads the tarball according to the .spec file, and merges the two. There is a tool to automate this, obviously. This process is regularly executed to produce source RPMs .
• Debian keeps the original tarball next to a diff.gz file on the mirrors, along with a dsc file which refers to them both. Tools like dget take the URL to the dsc file to download all three, then invoke dpkg-source to unpack the tarball and apply the diff. Individual patch files are either stored in ./debian/patches/ (and applied by the diff), or they don t exist (meaning that all modifications are concatenated in the diff.gz file.

Many Debian package maintainers use version control systems to maintain the ./debian directory, and if patch files are stored in ./debian/patches/, then Debian and Fedora both store patch files in a version control repository, which seems awful. Just as I am only one of many who are experimenting with VCS-based workflows for Debian packaging, the Fedora people are also considering the use of version control for packaging. Unlike Fedora, who seem to try to standardise on bzr, I try to cater for the plethora of version control systems in use in Debian, anticipating the impossibility of standardising/converging on a single tool across the entire project. It seems that our two projects are both at the start of a new phase in packaging, a paradigm shift . What better time could there be for us to listen to each other and come up with a workflow that works for both projects? My suggestion currently centres around a common repository for each package across all (participating) distros, and feature branches. Specifically, given an upstream source tree, modifications made during packaging for a given distro fall into four categories:

• upstream changes, such as bug fixes in the original code, or simple things like manpage typos.
• (Linux) distro stuff, such as init.d scripts or Linux-ifications, which upstream doesn t care about or doesn t want.
• .deb/.rpm-specific changes, like the ./debian directory or the .spec file.
• distro-specific modifications, like policy compliance and the like.

Given a version control system with sufficient branching support, I imagine having different namespaces for branches: upstream-patches/*, distro/*, rpm/* or debian/*. Now, when building the Debian package, I d apply upstream-patches/*, distro/*, deb/* and debian/* in order, while my colleague from the Fedora project would apply upstream-patches/*, distro/*, rpm/* and fedora/*, before calling the build tools and uploading the package. There are surely problems to be overcome. Pascal Hakim mentioned patch dependencies, and I can t necessarily say with a clear conscience that my workflow isn t too complicated to be unleashed into the public yet. But if we find a conceptual workflow applicable to more than one distro, it should be possible to implement a higher-level tool to implement it. Also, the above is basically patch maintenance, not the entire workflow. Bug tracking system integration is going to play a role, as well as other aspects of daily distro packaging. I ll leave those for future time. For me, this is the start of a potentially fruitful cooperation and I hope that interested parties from other distros jump on. For now, I suggest my mailing list for discussion. You can also find some links on the Debian wiki.

As I mentioned I would a month or so ago, I attended a workshop on Computing in the Cloud organized by Ed Felton's Center for Information Technology Policy at Princeton University. The conference aimed to discuss the policy issues that are raised by the shift from computing on machines we own and have direct control over to computing on servers owned by others. Think Google, Facebook, MySpace, and that lot. I talked about what all this might mean for free software and for open source and our communities, a bit about the AGPL, and discussed some ideas of how might proceed as a community. Princeton has been organized enough to post audio and video of the whole conference, including recordings of my talk, in a variety of formats and qualities (although unfortunately not in Vorbis and Theora). As I said in my FSF membership appeal last month, I think complications raised by "cloud computing" are one of the most important sets of challenges facing free software this year.

Tomorrow (January 28th), I'll be in Munich for this: http://www.mobile-monday.de/web/guest/android Unfortunately, the event filled up super fast and I barely managed to squeeze in, so there are probably no spaces left. Still, if anyone would like to meet up afterwards, send me an email soonish. If you managed to get in, and would like to see a demo of Hecl, let me know, because I'd like to have the chance to show that off some too! Hopefully it will be a valuable experience. Android is a pretty convincing system in many ways, but of course has yet to fully come into contact with reality, so I'm curious to meet some of the people involved and hear about it from them. I really hope it doesn't end up being a rehash of information that's available on the web, as it's a two hour drive from Innsbruck.

Today I gave a talk about Debian security at the security mini-conf of LCA. Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing. I started with describing some of the history of security in Debian (primarily things that involved me in some way): In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned. A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield… In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long. FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it. I described the current status: The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works. Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages. The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it. SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it. Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing). There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []). Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

• [0] http://etbe.coker.com.au/2008/01/20/lca-2008-security-blogging-contest/


• [1] http://www.debian.org/News/weekly/2003/45/


• [2] http://www.linux.org.au/conf/2005/security_miniconf/presentations/smashing.pdf


• [3] http://wiki.debian.org/Hardening


• [4] http://alioth.debian.org/projects/hardening/


• [5] http://etbe.coker.com.au/2007/12/28/twilight-of-the-books/

Share This

According to a notification of trade on the Oslo B rs market, Nokia has made an offer for Trolltech of about 843 million Norwegian kroner , around 104 million. What this could mean for GTK+ is anyone’s guess. I’d expect at least that Nokia’s competitors that use Qtopia (like Motorola, Panasonic and Sony) are probably a little worried at the moment. Maybe there’ll be impetus for OSSO to move over to Qt, or maybe there’ll be internal competion at Nokia between a Qtopia stack and a GTK+/X11/Freedesktop stack. Maybe Qt will become more closed as Nokias pushes its advantage, or maybe it’ll be more open as development becomes less dependant on non-GPL license revenues, or maybe it’ll just stay the same. An interesting left-field move in this space is OpenMoko moving over to EFL, but on a primarily GNOME/Freedesktop stack. EFL is certainly much more capable than GTK+ in producing flashy UI’s on limited hardware. I”ve also heard of some companies writing UI’s in Flash using Gnash. I also wouldn’t be suprised if we start seeing embedded hardware running Mono and Moonlight at some point. Maybe one day we’ll have a GTK3 with DOM-like two pass event system and a cairo backend that renders totally on the GPU. One thing’s for certain, there’s a hell of a lot of competition on the toolkit front and it will only grow.

I can’t believe I have not bogged about this before. With all that terrorism threat bullshit, wouldn’t it be nice if there was an airline that would declare itself to be ‘terrorist friendly’ - i.e. all passangers are welcome to come on board with just a simple identity check, no security check, no baggage security check, no delays. You can arrive 10 minutes before departure and just fly away. Wouldn’t that be nice? A budget company could do that to spare on airport security fees and high-end airline could do it just to spare your time. All flights could be marked private charter for legal reasons. Can we please return to a world when I can take a bottle of mineral water and a nail clipper on board with me?