fidzu : freedesktop

I recently purchased and installed a standing desk. While I normally don't blog about things in my personal life, I figured that this was permissible since it directly affects my ability to write code.

This standing desk is a Fredrik "computer work station," but let's be honest, here: it's a standing desk. It's pretty sturdy and removes the need to hack together various Ikea desks to produce reasonably-scaled tabletops. Pictured here is my desk, in its natural habitat. My workstation and hacked-apart AGP box both have their own monitor, and there is plenty of tabletop room for anything I need to have at my hands.

For those in the audience who aren't yet aware of standing desks, and don't want to read Wikipedia on standing desks, here are the abridged notes:

• Pros
  • Reduces back stress and pain after a few months
  • Reduces risk of DVT
  • When monitors are elevated, reduces neck stress and pain
• Cons
  • Slightly more expensive than sitting desks
  • Hard to find
  • Causes foot and ankle stress for the first few weeks
  • Turns one into a hipster programmer

So, on the bright side, this desk has definitely improved my back pain. But, if I start writing Node.js code soon, we'll all know who to blame.

31 Jan 2012 11:42am GMT

I suspect that I'll be receiving quite a few more hits here given the recent retweets. Unfortunately I haven't had much time to update my blog... In fact, I may not have any time in the future.

On a more positive note, I am much more active on Twitter, so you can follow me there (@omcfadde)

Of course the topics we're discussing, SOPA, ACTA, etc are definitely not pleasant or positive. Let's show them we mean business and that we will not accept these agreements!

STOP ACTA

Updates (possibly) coming in the future.

---

Epäilen, että tulen saa melkoisesti lisää osumia tässä äskettäisten retweets. Valitettavasti minulla ei ole ollut paljon aikaa päivittää blogiin ... Itse en ehkä ole mitään aikaa jatkossa.

Myönteistä huomata, olen paljon enemmän aktiivisia Twitterissä, jotta voit seurata minua sinne (@omcfadde)

Tietenkin aiheita olemme keskustelleet, SOPA, ACTA jne. eivät varmasti miellyttävä tai positiivinen. Katsotaanpa näytä heille että olemme tosissamme ja että me ei hyväksy näitä sopimuksia!

STOP ACTA (In Englanti - Lue!)

Päivitykset (mahdollisesti) tulossa tulevaisuudessa.

30 Jan 2012 7:20pm GMT

So as I talked about in my last blog post we had a great GStreamer hackfest. A lot of things got done and quite a few applications got an initial port over to 0.11. For instance Edward Hervey ended up working on porting the Totem video player, or rather trying to come up with a more optimized design for the Clutter-gst as the basis port was already done.

Another cool effort was by Philippe Normand from Igalia who put a lot of effort into porting WebKit to use 0.11. His efforts where rewarded with success as you can see in this screenshot.

Jonathan Matthew had flown up all the way from Australia and made great progress in porting Rhythmbox over to the 0.11 API, a port which became hugely more useful after Wim Taymans and Tim-Phillip Muller fixed a bug that caused mp3 playback not to work .

Peteris Krisjanis made huge strides in porting Jokosher to 0.11. Although like Jason DeRose from Novacut and myself on Transmageddon he did end up spending a lot of time on debugging issues related to gobject-introspection. The challenge for non-C applications like Jokosher, Novacut, Transmageddon and PiTiVi is a combination of the API having changed quite significantly due to the switch to gobject-introspection generated bindings, some general immaturity challenges with the gobject-introspection library and finally missing or wrong annotations in the GStreamer codebase. So once all these issues are sorted things should look a lot brighter for language bindings, but as we discovered there is a lot of heavy lifting to get there. For instance I thought I had Transmageddon running quite smoothly before I suddenly triggered this gobject-introspection bug.

There was a lot of activity around PiTiVi too, with Jean-François Fortin Tam, Thibault Saunier and Antigoni Papantoni working hard on porting PiTiVi to 0.11 and the GStreamer Editing Services library. And knowing Jean-François Fortin I am sure there will soon be a blog with a lot more details about that .

Thomas Vander Stichele, who also wrote a nice blog entry about the event, was working with Andoni Morales Alastruey, both from Flumotion, on porting Flumotion to 0.11, but due to some of the plugins needed not having been ported yet most of their effort ended up being on porting the needed plugins in GStreamer and not so much application porting, but for those of you using plugins such as multifdsink, this effort will be of great value and Andoni also got started on porting some of the non-linux plugins, like the directsoundsink for Windows.

Josep Torra from Fluendo ended up working with Edward Hervey on hammering out the design for the clutter-gst sink at the conference, but he also found some time to do a port of his nice little tuner tool as you can see from the screenshot below.

George Kiagiadakis kept hammering away at the qtGStreamer bindings, working both on a new release of the bindings for the GStreamer 0.10 series, but also some preparatory work for 0.11.

In addition to the application work, Wim Taymans, Tim-Phillip Müller and Sebastian Dröge from Collabora did a lot of core GStreamer clean ups and improvements in addition to providing a lot of assistance, bugfixing and advice for the people doing application porting. All critical items are now sorted in 0.11 although there are some nice to have's still on the radar, and Wim plans on putting out some new releases next week, to kickstart the countdown to the first 1.0 release.

As for my own little pet project Transmageddon, it is quite far along now, with both manually configured re-encodes and profile re-encodes working. Still debugging remuxing though and I am also waiting for the deinterlacer to get ported to re-enable deinterlacing in the new version. For a screenshot take a look at the one I posted in my previous blogpost.

29 Jan 2012 5:17pm GMT

The real life and work issues had eaten most of my time for the past 2 weeks, but things seem to be geting back to normal now. So time for semi-regular updates from the Intel Linux Graphics land.

Starting with kernel, many notable changes happened in the past weeks. To make our -next merge window process go faster, a new process was adopted for the kernel patch and branch handling process. Let me elaborate a bit more about how this is going to work.

For the past months, we had the drm-intel-next branch (containing patches intended to go into the next merge window - e.g., when the 3.3 kernel is being developed, this is the branch which contains patches intended to be included in the 3.4 kernel version), and also drm-intel-fixes branch (containing patches for the currently developed kernel - e.g., patches which fix issues which were added during the past merge window. So for instance, those are the patches which go into 3.3-rcN kernel versions after the merge window). Both of those patches were maintained by Keith Packard.

However, the amount of patches combined with other tasks resulted in a somewhat slower patch queuing process. So Daniel Vetter has volunteered himself to maintain the drm-intel-next branch from now on, reviewing, queuing and managing the patches intended to get into the next kernel merge window (for now, those are targeting the 3.4 kernel version).

At the same time, Keith Packard will continue to maintain the drm-intel-fixes branch, managing and carrying stability patches for the current kernel.

And finally, to improve the testing and availability of newer features for older kernel versions, I've started my own drm-intel-backports set of branches, for 3.0, 3.1 and 3.2 kernel versions - containing all the latest and greatest patches from the latest kernel releases. Of course, those patches do not follow the usual kernel stable development model, so they introduce new features, capabilities and possible issues. But for the brave souls out there willing to see and test the absolutely latest development in our drivers on top of their kernels, it should be a great chance to do so.

(I assume that I was not that fast with the drm-intel-backports patch merging process in the past 2 weeks, so for now it only contains patches from the 3.2 kernel branch. I intend to backport the 3.3 and 3.4-next patches for all those versions in the coming days. Also, apparently those backported patches do not work correctly with pre-Ironlake chipsets on 3.0 kernel, and there are some display-related issues on top of 3.1 one - I'll look into it as well. Sorry for the delay - but the real life interfered with my patching capability for the past weeks…)

Besides those changes, we had a large number of notable kernel advances in the past weeks:

• One of the most interesting features is the support for interlaced modes in the Intel Linux Graphics cards. A great work by Peter Ross, Daniel Vetter and Paulo Zanoni resulted in a series of patches which provided support for interlaced modes. These patches will be queued for inclusion in the 3.4 kernel - but when I'll get back to my -backports series of patches, I'll certainly include them into the 3.[012] series as well.
• More Ivy bridge 3-display pipes issues were fixed, such as the hibernation problem with 3rd pipe being active.
• Stabilizing the almost-ready-to-launch Ivy bridge platform, the hopefully final forcewake-related fixes were included in both drm-intel-next and drm-intel-fixes branches, and were also cherry-picked by Greg to be included in the stable 3.2 kernel as well. This should solve the remaining missing interrupts problems we were experiencing.
• Initial patches to support the hardware context switching were sent by Ben Widawsky, and are accessible in his own freedesktop.org repository for testing. Hardware-supported context switching allows to save the hardware registers and state for each process, so it could essentially help the GL_EXT_transform_feedback extension and advanced geometry shading state passing between different stages. And, of course, it can also improve the stability - hardware would ensure that different processes would not interfere with each other in a harmful way.
• And almost a hundred pending patches were picked by Daniel Vetter for his new drm-intel-next branch. The next merge window certainly looks interesting for the Intel Linux Graphics support in this sense…

On Mesa side, the 8.0 release is getting really close. After the 8.0-rc1 release a couple of weeks ago, lots of patches were picked into the 8.0 branch, improving the stability, performance, and fixing many rendering issues - especially on the Ivy Bridge platform. More excitingly, the communication between Mesa and Unigine developers resulted in better support for open-source drivers in the just released Oil Rush game. It is really great to see such cooperation - and Unigine-based game certainly is one of the most advanced graphical releases of past years on Linux.

Speaking about the Mesa development, this final stabilization phase prior to the 8.0 release is a great chance for you to report issues, bugs and problems before the release which is expected in a few days from now. So if you observe any last-minute problems and regressions with Mesa 8.0 branch - please, let us know! This next release looks really impressive from the technical side, but your help in additional testing is more than welcome.

On Wayland side, lots of different patches and features were received in the past weeks. Wayland and Weston development goes on with great pace - and the ones of you to attend FOSDEM next week will have some really interesting stuff to gaze upon. But I won't spoil the surprise .

On Xserver development, the 1.12 RC2 and 1.11.4 releases were unleashed last week, together with a new glproto, util-macros and xkeyboard-config versions. The development continues non-stop, with hundreds of patches and discussions happening in the mailing lists.

And finally, the phoronix feedback I got from you over the past weeks was amazing. Thank you all for all your questions and suggestions - it was really nice to hear what you have in mind, what you like (and dislike) in our drivers and what direction we should be heading. I'll try to answer the last remaining questions in the next few day, and will summarize everything on a dedicated blog post.

29 Jan 2012 3:11pm GMT

After seeing, this article about "How secure is Paypal for eBay sellers" in this morning's Guardian, I'll share my personal experience with you.

In October, I sold my first generation MacBook Air on eBay, and got a buyer within a day for the £500 "Buy It Now" price. "Buy It Now" requires using Paypal, and the £500 (minus commission) appeared in my Paypal account¹. After a bit of to and fro, the buyer got in contact, and suggested that he come and pick it up. Saving about £30 of shipping, and sorting out the sale faster, strike me as good ideas.

The "buyer" said he couldn't come, sent one of his "employees". A very courteous man came to pick the laptop. In hindsight, he seemed slightly uncomfortable, and looked like he was very happy to see how easy it was going to be.

The spooky thing is that within 40 minutes -- note, not 3 hours, not a day after, not the day before) -- within 40 minutes of the laptop getting picked up, the holder of the eBay and Paypal accounts submitted an "unauthorised account activity claim", leading to "payment reversal" (me owing £500 to Paypal²).

During my call to eBay's customer support, I was told that "I had nothing to worry about" (I'm guessing that would be the case as long as I repaid the £500). Paypal promptly sent a mail mentioning they needed my help, but with very little possibilities from my side ("no courier tracking number? Give us the money now").

Surrey Police failed to find the culprits, with the 2 mobile numbers associated with the con only being pay-as-you-go phones (topped up in a little convenience store in North London that only keeps a day's worth of CCTV).

So my advices:

• If you sell anything via eBay using Paypal, send it recorded, and keep the receipt.
• If you bought a MacBook Air first generation with the serial W88500DJ12G, it's stolen, send me an e-mail.

And as opposed to Mssrs Lodge and Reakes, Paypal didn't reimburse me anything, and I'm £500 out of pocket.

¹: I'll pass you the details on eBay referring to a closed Paypal account that meant I got conned two days later than the "buyers" anticipated.
²: On an account that was already closed, see ¹.

Update: Added mention of eBay's ludicrously bad customer service.

28 Jan 2012 4:19pm GMT

Working from designs.


The cool stuff first

Go to YouTube directly if you can't see the video here.

A new arrival

As mentioned by Cosimo, we have a new library to help us implement the settings you saw: libwacom.

libwacom is there to give us metadata about tablets, whether or not they are connected to your system, the list of styli it supports, as well as information about the styli themselves. As you can see from the UI, it's pretty important that we know:

• whether the tablet is builtin (so we know whether you can calibrate it)
• which form factor it has
• the list of styli it supports
• for each stylus, its full name, the number of buttons, what it looks like

In the past, all this information was only available within the drivers (as comments), exported in different ways (sysfs attributes), non-machine readable in public documentation, or, worst of all, hidden in Wacom's internal drivers for OS X or Windows.

So if you have a Wacom tablet, send us a definition file for your tablet, so you can configure it with the impression that the software actually knows about your device.

Where's that configuration again

After knowing what each tablet had to offer, we had to have a way to match the definitions to XInput devices, assign settings per-tablet, and importantly, switch stylus configuration when the user switches stylus. This is done using the new GsdWacomDevice and GsdWacomStylus objects, shared between gnome-settings-daemon (which will apply the configuration) and gnome-control-center (which will set the configuration).

This also means we have a few debugging applications, such as list-wacom in gnome-settings-daemon, to show you the attached GsdWacomDevices, or test-wacom in gnome-control-center, to test display of particular tablets if you don't own them (this is the place where I spend a lot of time).

What's next

Peter Hutterer, my input buddy at Red Hat, who made the original Wacom panel for GNOME 3.2, and the first version of libwacom, is currently spending a lot of time on Multi-Touch, and fixing bugs I report in the Wacom driver.

Jason Gerecke, from Wacom, who did most of the initial work on calibration support, is working on the related display-mapping. This will allow choosing whether a tablet's working area is the whole desktop, or a single monitor when in multiple monitors are used.

For my part, after fixing the layout bugs that so annoy me in the settings panel, I'll be starting work on tablet button mapping. I look forward to making the LEDs on the tablet match up with the selected keyboard shortcut!

Many thanks to Cosimo and Monty for helping out with presenting the work, and doing the video.

27 Jan 2012 1:07pm GMT

Hello Planet GNOME readers and GNOME community members,

The board of directors has agreed that from now on, to be part of Planet GNOME, it is mandatory to be a member of the GNOME Foundation. In three weeks we will proceed to remove all blogs from people that are not foundation members. This policy change means a few things:

• If your blog is in Planet GNOME and you are not a member of the GNOME Foundation, you have three weeks to become a member!
• New planets additions from now on will take this policy into account.
• This doesn't mean that your blog automatically gets into Planet GNOME if you are a member, the same blog review process will be applied to requests for addition.
• There will be a slight exception with GSoC/GOPW members we will encourage them to join in the meantime, but being able to use the planet to report progress to the community is an important part of their work as interns.
• We will delete the feed syndication from the planet if your membership expires.

The rationale behind this new policy is simple, we want to increase the value of becoming a foundation member. Think of this as the blogging equivalent of rocking an @gnome.org e-mail address.

Update: I have clarified the language behind the deletion of the feed. Someone in the comments thought I was talking about removing their blogs from blogs.gnome.org. This is not the case, if your membership expires your feed won't show up in the Planet, but that's it, if you have a blog in blogs.gnome.org none of your posts will be deleted.

Foundationally yours,
the Planet GNOME editors team.

27 Jan 2012 2:56am GMT

One of the features of Fedora 17 is the /usr merge, put forward by Harald Hoyer and Kay Sievers^[1]. In the time since this feature has been proposed repetitive discussions took place all over the various Free Software communities, and usually the same questions were asked: what the reasons behind this feature were, and whether it makes sense to adopt the same scheme for distribution XYZ, too.

Especially in the Non-Fedora world it appears to be socially unacceptable to actually have a look at the Fedora feature page (where many of the questions are already brought up and answered) which is very unfortunate. To improve the situation I spent some time today to summarize the reasons for the /usr merge independently. I'd hence like to direct you to this new page I put up which tries to summarize the reasons for this, with an emphasis on the compatibility point of view:

The Case for the /usr Merge

Note that even though this page is in the systemd wiki, what it covers is mostly orthogonal to systemd. systemd supports both systems with a merged /usr and with a split /usr, and the /usr merge should be interesting for non-systemd distributions as well.

Primarily I put this together to have a nice place to point all those folks who continue to write me annoyed emails, even though I am actually not even working on all of this...

Enjoy the read!

Footnotes:

[1] And not actually by me, I am just a supportive spectator and am not doing any work on it. Unfortunately some tech press folks created the false impression I was behind this. But credit where credit is due, this is all Harald's and Kay's work.

26 Jan 2012 9:29pm GMT

Things have been going really well here at the GStreamer Hackfest in Malaga. Thanks to the help of Ara and Yaiza from Nido Malaga, we have a great venue in downtown Malaga and they have also helped us greatly with sorting out food.
We have a great group of people here and are making great progress, and by tomorrow I hope we will have screenshots of quite a few applications running with GStreamer 0.11, for instance both Rhythmbox and Jokosher for instance is already screen shootable, if not fully functional

Also making good progress on Transmageddon, even if the move to GObject Introspection bindings are making things a bit more complicated. Screenshot below of the progress so far.

Also a big thanks to Fluendo who is sponsoring the lunches at the hackfest and Collabora who is sponsoring tonight's dinner. Ensuring that no hacker is left hungry during this hackfest.

Update: Yaiza took these photos from the hackfest

26 Jan 2012 2:12pm GMT

With all the talk generated by Arun Raghavans blog post comparing PulseAudio and Audioflinger I thought it would be good to follow up with an interview with Arun about the latest developments in PulseAudio and the way forward for the project. You can find the PulseAudio interview here. I also made a new page listing all the Collabora developer interviews done so far. Enjoy

25 Jan 2012 3:45pm GMT

Tomorrow I will be heading off to attend the GStreamer Application Porting Hackfest in Malaga, Spain. I think we have managed to pull together an absolutely incredible group of people for this event and I have great hopes that by next weekend we will have squashed a ton of bugs in GStreamer 0.11/1.0 and also have initial ports of a long range of important applications and bindings. This is the first time in GStreamer history that we are trying to hold a hackfest focused on application developers, but hopefully it will be the first of many and that they can become a good way for the core GStreamer community and the application development community to interact and collaborate more closely.

Also want to say a special thanks to the community members attending the event on their own and also to the companies sending their employees to the hackfest; Collabora, Fluendo, Flumotion and Igalia and finally a special thanks to the GNOME Foundation for sponsoring some of the attendees.

Hopefully I will be able to post some screenshots of a fully functional GStreamer 1.0 Transmageddon next weekend

23 Jan 2012 9:39am GMT

It is a running joke in the X.Org community that X12 development will commence as soon as all of the X11 bugs in the FreeDesktop.org bug tracker have been closed. When I first heard this, my reaction was, of course, "Challenge accepted!" But where to start?

There were about 10,000 bugs open on the tracker at that point, a few years ago. We're definitely improving; there are about 9180 bugs open (at the time of writing) which could be considered relevant to any kind of desktop development. Many of those don't belong to anything in X11, but assuming they did...

Pretend that all of the card-carrying members of X.Org closed 92 bugs. That would be 1% per person. We could be done with X11! So, during XDC 2011, I pulled out my netbook, and started closing bugs. I picked, as my targets, things that nobody would miss, like Xprint.

I closed some Xprint-related bugs, before simply shuttering everything in the Xprint product. I also picked up a couple of stray bugs. Finally, with maintainer permission, I closed everything still assigned to xf86-video-nv.

The results:

• 24 Xprint-related bugs
• 37 bugs in Product: xprint
• 42 bugs in Component: driver/nv
• 37 bugs in Component: driver/nVidia (open)
• #9455, #28657, #29832, #30129

A total of 144 bugs. We can do this, guys!

22 Jan 2012 12:00pm GMT

Last October we published a wishlist for plumbing related features we'd like to see added to the Linux kernel. Three months later it's time to publish a short update, and explain what has been implemented in the kernel, what people have started working on, and what's still missing.

The full, updated list is available on Google Docs.

In general, I must say that the list turned out to be a great success. It shows how awesome the Open Source community is: Just ask nicely and there's a good chance they'll fulfill your wishes! Thank you very much, Linux community!

We'd like to thank everybody who worked on any of the features on that list: Lucas De Marchi, Andi Kleen, Dan Ballard, Li Zefan, Kirill A. Shutemov, Davidlohr Bueso, Cong Wang, Lennart Poettering, Kay Sievers.

Of the items on the list 5 have been fully implemented and are already part of a released kernel, or already merged for inclusion for the next kernels being released.

For 4 further items patches have been posted, and I am hoping they'll get merged eventually. Davidlohr, Wang, Zefan, Kirill, it would be great if you'd continue working on your patches, as we think they are following the right approach^[1] even if there was some opposition to them on LKML. So, please keep pushing to solve the outstanding issues and thanks for your work so far!

Footnotes

[1] Yes, I still believe that tmpfs quota should be implemented via resource limits, as everything else wouldn't work, as we don't want to implement complex and fragile userspace infrastructure to racily upload complex quota data for all current and future UIDs ever used on the system into each tmpfs mount point at mount time.

20 Jan 2012 8:26pm GMT

Given that there is a copious amount of misinformation being spread, here is a summary of CVE-2012-0064, straight from a horse's mouth.

Outline of the issue

The bug allows users to work around screen locking (e.g. gnome-screensaver) by hitting Control+Alt+keypad multiply or Control+Alt+keypad divide. This terminates the input grab the screensaver has and thus allows a user to interact with the desktop, skipping the password entry.

Affected versions

Affected is anyone running X server 1.11 or later (or release candidates thereof). So if "Xorg -version" shows something else on your box, stop worrying. I doubt any distribution would have back-ported the patches.

In Fedora/Red Hat land - the only distributions affected are Fedora 16 and current Fedora Rawhide. Both have been fixed, the F16 update is avaialble here. Note that the update is to xkeyboard-config, not to the server itself.

Fedora 15 is not affected. RHEL 4, 5, 6 and thus CentOS 4, 5, 6 and other derivatives are not affected. I believe that most other distributions have now pushed out updates as well, if you want to link to the respective updates, please do so in the comments.

Sergey has also pushed out xkeyboard-config 2.5 today with the fix included.

History of the feature

The X protocol does not allow the server to break grabs. Once a client has a grab, the server must wait for that client to release the grab, terminate, or the grab window to become unviewable. This is an issue when debugging applications - if your client has a keyboard grab, you cannot use the debugger since all key events will go to the client being debugged. To avoid this issue, the X server has had two combinations to break grabs: Control+Alt+Keypad multiply and Control+Alt+Keypad divide. They forced grab termination inside the X server and although against the protocol it made debugging possible. The option required explicit enabling in the xorg.conf.

These options were removed in server 1.4 and disabled since. Which made debugging hard, so last year we merged a patch to bring them back, together with some other features. They are triggered by XKB actions (as they used to be). The plan was to remove the XKB actions from the default keymap so that the action is available on request but not enabled by default. This is where a miscommunication happened, the removal from the default keymap never happened. So server 1.11 and vanilla xkeyboard-config ship with both the actions available and present in the current keymap. As a result, any user can break a grab from any application and thus get around screen locking.

Outline of the fix

To shoot yourself in the foot, you need two items: a gun and a trigger. We have removed the trigger. The fix we've now pushed into xkeyboard-config removes the actions from the default keymap and into an XKB option instead. So the fix does not remove the gun, but it requires the user to screw the trigger in themselves before trying to hurt themselves. In a default configuration, it is thus no longer possible to break the grab of your screensaver.

To re-enable grab debugging, run setxkbmap with "-option grab:break_actions" or enable "Allow breaking grabs with keyboard actions (warning: security risk)" in the "Miscellaneous compatibility options" in your keyboard layout configuration tool of choice.

20 Jan 2012 2:39am GMT

Here's the twelfth installment of my ongoing series on systemd for Administrators:

Securing Your Services

One of the core features of Unix systems is the idea of privilege separation between the different components of the OS. Many system services run under their own user IDs thus limiting what they can do, and hence the impact they may have on the OS in case they get exploited.

This kind of privilege separation only provides very basic protection however, since in general system services run this way can still do at least as much as a normal local users, though not as much as root. For security purposes it is however very interesting to limit even further what services can do, and shut them off a couple of things that normal users are allowed to do.

A great way to limit the impact of services is by employing MAC technologies such as SELinux. If you are interested to secure down your server, running SELinux is a very good idea. systemd enables developers and administrators to apply additional restrictions to local services independently of a MAC. Thus, regardless whether you are able to make use of SELinux you may still enforce certain security limits on your services.

In this iteration of the series we want to focus on a couple of these security features of systemd and how to make use of them in your services. These features take advantage of a couple of Linux-specific technologies that have been available in the kernel for a long time, but never have been exposed in a widely usable fashion. These systemd features have been designed to be as easy to use as possible, in order to make them attractive to administrators and upstream developers:

• Isolating services from the network
• Service-private /tmp
• Making directories appear read-only or inaccessible to services
• Taking away capabilities from services
• Disallowing forking, limiting file creation for services
• Controlling device node access of services

All options described here are documented in systemd's man pages, notably systemd.exec(5). Please consult these man pages for further details.

All these options are available on all systemd systems, regardless if SELinux or any other MAC is enabled, or not.

All these options are relatively cheap, so if in doubt use them. Even if you might think that your service doesn't write to /tmp and hence enabling PrivateTmp=yes (as described below) might not be necessary, due to today's complex software it's still beneficial to enable this feature, simply because libraries you link to (and plug-ins to those libraries) which you do not control might need temporary files after all. Example: you never know what kind of NSS module your local installation has enabled, and what that NSS module does with /tmp.

These options are hopefully interesting both for administrators to secure their local systems, and for upstream developers to ship their services secure by default. We strongly encourage upstream developers to consider using these options by default in their upstream service units. They are very easy to make use of and have major benefits for security.

Isolating Services from the Network

A very simple but powerful configuration option you may use in systemd service definitions is PrivateNetwork=:

...
[Service]
ExecStart=...
PrivateNetwork=yes
...

With this simple switch a service and all the processes it consists of are entirely disconnected from any kind of networking. Network interfaces became unavailable to the processes, the only one they'll see is the loopback device "lo", but it is isolated from the real host loopback. This is a very powerful protection from network attacks.

Caveat: Some services require the network to be operational. Of course, nobody would consider using PrivateNetwork=yes on a network-facing service such as Apache. However even for non-network-facing services network support might be necessary and not always obvious. Example: if the local system is configured for an LDAP-based user database doing glibc name lookups with calls such as getpwnam() might end up resulting in network access. That said, even in those cases it is more often than not OK to use PrivateNetwork=yes since user IDs of system service users are required to be resolvable even without any network around. That means as long as the only user IDs your service needs to resolve are below the magic 1000 boundary using PrivateNetwork=yes should be OK.

Internally, this feature makes use of network namespaces of the kernel. If enabled a new network namespace is opened and only the loopback device configured in it.

Service-Private /tmp

Another very simple but powerful configuration switch is PrivateTmp=:

...
[Service]
ExecStart=...
PrivateTmp=yes
...

If enabled this option will ensure that the /tmp directory the service will see is private and isolated from the host system's /tmp. /tmp traditionally has been a shared space for all local services and users. Over the years it has been a major source of security problems for a multitude of services. Symlink attacks and DoS vulnerabilities due to guessable /tmp temporary files are common. By isolating the service's /tmp from the rest of the host, such vulnerabilities become moot.

For Fedora 17 a feature has been accepted in order to enable this option across a large number of services.

Caveat: Some services actually misuse /tmp as a location for IPC sockets and other communication primitives, even though this is almost always a vulnerability (simply because if you use it for communication you need guessable names, and guessable names make your code vulnerable to DoS and symlink attacks) and /run is the much safer replacement for this, simply because it is not a location writable to unprivileged processes. For example, X11 places it's communication sockets below /tmp (which is actually secure -- though still not ideal -- in this exception since it does so in a safe subdirectory which is created at early boot.) Services which need to communicate via such communication primitives in /tmp are no candidates for PrivateTmp=. Thankfully these days only very few services misusing /tmp like this remain.

Internally, this feature makes use of file system namespaces of the kernel. If enabled a new file system namespace is opened inheritng most of the host hierarchy with the exception of /tmp.

Making Directories Appear Read-Only or Inaccessible to Services

With the ReadOnlyDirectories= and InaccessibleDirectories= options it is possible to make the specified directories inaccessible for writing resp. both reading and writing to the service:

...
[Service]
ExecStart=...
InaccessibleDirectories=/home
ReadOnlyDirectories=/var
...

With these two configuration lines the whole tree below /home becomes inaccessible to the service (i.e. the directory will appear empty and with 000 access mode), and the tree below /var becomes read-only.

Caveat: Note that ReadOnlyDirectories= currently is not recursively applied to submounts of the specified directories (i.e. mounts below /var in the example above stay writable). This is likely to get fixed soon.

Internally, this is also implemented based on file system namspaces.

Taking Away Capabilities From Services

Another very powerful security option in systemd is CapabilityBoundingSet= which allows to limit in a relatively fine grained fashion which kernel capabilities a service started retains:

...
[Service]
ExecStart=...
CapabilityBoundingSet=CAP_CHOWN CAP_KILL
...

In the example above only the CAP_CHOWN and CAP_KILL capabilities are retained by the service, and the service and any processes it might create have no chance to ever acquire any other capabilities again, not even via setuid binaries. The list of currently defined capabilities is available in capabilities(7). Unfortunately some of the defined capabilities are overly generic (such as CAP_SYS_ADMIN), however they are still a very useful tool, in particular for services that otherwise run with full root privileges.

To identify precisely which capabilities are necessary for a service to run cleanly is not always easy and requires a bit of testing. To simplify this process a bit, it is possible to blacklist certain capabilities that are definitely not needed instead of whitelisting all that might be needed. Example: the CAP_SYS_PTRACE is a particularly powerful and security relevant capability needed for the implementation of debuggers, since it allows introspecting and manipulating any local process on the system. A service like Apache obviously has no business in being a debugger for other processes, hence it is safe to remove the capability from it:

...
[Service]
ExecStart=...
CapabilityBoundingSet=~CAP_SYS_PTRACE
...

The ~ character the value assignment here is prefixed with inverts the meaning of the option: instead of listing all capabalities the service will retain you may list the ones it will not retain.

Caveat: Some services might react confused if certain capabilities are made unavailable to them. Thus when determining the right set of capabilities to keep around you need to do this carefully, and it might be a good idea to talk to the upstream maintainers since they should know best which operations a service might need to run successfully.

Caveat 2: Capabilities are not a magic wand. You probably want to combine them and use them in conjunction with other security options in order to make them truly useful.

To easily check which processes on your system retain which capabilities use the pscap tool from the libcap-ng-utils package.

Making use of systemd's CapabilityBoundingSet= option is often a simple, discoverable and cheap replacement for patching all system daemons individually to control the capability bounding set on their own.

Disallowing Forking, Limiting File Creation for Services

Resource Limits may be used to apply certain security limits on services being run. Primarily, resource limits are useful for resource control (as the name suggests...) not so much access control. However, two of them can be useful to disable certain OS features: RLIMIT_NPROC and RLIMIT_FSIZE may be used to disable forking and disable writing of any files with a size > 0:

...
[Service]
ExecStart=...
LimitNPROC=1
LimitFSIZE=0
...

Note that this will work only if the service in question drops privileges and runs under a (non-root) user ID of its own or drops the CAP_SYS_RESOURCE capability, for example via CapabilityBoundingSet= as discussed above. Without that a process could simply increase the resource limit again thus voiding any effect.

Caveat: LimitFSIZE= is pretty brutal. If the service attempts to write a file with a size > 0, it will immeidately be killed with the SIGXFSZ which unless caught terminates the process. Also, creating files with size 0 is still allowed, even if this option is used.

For more information on these and other resource limits, see setrlimit(2).

Controlling Device Node Access of Services

Devices nodes are an important interface to the kernel and its drivers. Since drivers tend to get much less testing and security checking than the core kernel they often are a major entry point for security hacks. systemd allows you to control access to devices individually for each service:

...
[Service]
ExecStart=...
DeviceAllow=/dev/null rw
...

This will limit access to /dev/null and only this device node, disallowing access to any other device nodes.

The feature is implemented on top of the devices cgroup controller.

Other Options

Besides the easy to use options above there are a number of other security relevant options available. However they usually require a bit of preparation in the service itself and hence are probably primarily useful for upstream developers. These options are RootDirectory= (to set up chroot() environments for a service) as well as User= and Group= to drop privileges to the specified user and group. These options are particularly useful to greatly simplify writing daemons, where all the complexities of securely dropping privileges can be left to systemd, and kept out of the daemons themselves.

If you are wondering why these options are not enabled by default: some of them simply break seamntics of traditional Unix, and to maintain compatibility we cannot enable them by default. e.g. since traditional Unix enforced that /tmp was a shared namespace, and processes could use it for IPC we cannot just go and turn that off globally, just because /tmp's role in IPC is now replaced by /run.

And that's it for now. If you are working on unit files for upstream or in your distribution, please consider using one or more of the options listed above. If you service is secure by default by taking advantage of these options this will help not only your users but also make the Internet a safer place.

20 Jan 2012 1:26am GMT

Do you wanna contribute to a funky open-source project? Are you tired of your nerdy and boring community of developers? Are you the one that wants to get rid of X because it's a giant, old and fat dinosaur in your system? :) Cool, I have a project to solve your problems!

-

While there's still lot of churn in the protocol, and yet our goal is soon to wrap up all we've been doing to a steady and settle-on-the-stone one description, there's a lot on the implementation side that needs love. And that mainly concern Weston compositor, which is becoming the de facto compositor on several systems targeting Wayland.

In past months I was accumulating a TODO list for Weston and libraries that I think wouldn't require any exceptional knowledge on core graphics or Wayland internals. These are good items for people that want start hack or just do some contribution on Wayland:

1. log facility (easy)

Back in July, I had already warmed up a discussion how we could log on Wayland. So now we spit everything to stdout but we want to do it similarly as Xorg, i.e. redirecting to its own file. It turned out that we might want only on Weston compositor and implement our own way of logging for sake of simplicity. Ideally it has to be very simple, without verbosity levels probably, etc. This task should be quite easy to finish.

2. launcher for Weston (medium)

Weston is meant to run as a normal user. Now we have to set manually input devices, DRM and tty with root permissions, so Weston can happily be started. Ideally we should have a setuid helper script doing all this tricky, and in fact I started something here. For a real system though, we need to enhance a bit this program with the policykit, specially for dealing with hotplugs. Probably zero understanding on Wayland internals is needed but an overall knowledge of OS is required.

3. libxkbcommon X merge (medium)

Actually that's not much Wayland work, but it most definitely would help its development. xkbcommon is the library that exposes the keyboard mapping logic to clients, converting keycodes in keysyms. Weston clients are using for evdev convertion. The library is an adaptation of a bunch of X11 modules to fit in a non-X11 world and as such, it still requires xproto, kbproto and libX11. One task would be to untie such dependencies with X and the other to proper merge libxkbcommon with Xorg. I'd classify as medium-size task due the involvement with the community and the hairy understanding of XKB in general, although Daniel, Kristian and other guys already made a nice progress there.

4. xwayland on X (hard)

xwayland is the implementation on Xorg to make it run as a Wayland client. That works well on Intel chipsets and might work as well with other drivers through the shm X driver. In principle, basic X11 applications work with some WM control lacking, input grab as well and things like Xrandr don't. One would also forward port xwayland and driver to upstream, once the work is shaped up. I bet WM developers would have an ecstasy and delight themselves hacking around.

-

Hopefully you get excited with some of the items. I definitely can give a hand with any, so just poke me on #wayland at freenode.

18 Jan 2012 1:53pm GMT