Today was the last day of the Linux Plumbers Conference, which overall seems to have gone really well. Certainly it exceeded my expectations, which were already pretty high. In my view, the conference was distinctive in that it was totally developer-focused and collaborative, with no thinly-disguised marketing talks.
The atmosphere was relaxed, and not overly structured, which allowed for a lot of useful ad-hoc discussions between developers working in different areas of the OS. An example was Arjan’s talk on achieving a five-second boot, which itself was very interesting and entertaining, but was also followed by a lunch session with a bunch of distro maintainers to work out various specifics. It seems that a small arms race has been launched between Fedora & Ubuntu on who can first get the default install to a five second boot.
I was interested to catch up on the latest file system developments, and caught the updates on btrfs and crfs by their respective authors, Chris Mason & Zach Brown. The disk format for btrfs will be locked in before the end of the year, according to Chris, to encourage more developers and users to start playing with it. crfs is looking increasingly impressive as a small-scale, fast, reliable and sane networked file system: I grabbed a photo of the slide comparing it with other network filesystems:
Other photos I took at the conference are here.
It was really great to catch up with so many people I work with over the net, and also finally meeting some people I must have known for more than a decade but still never met in person — possibly due to this being the first Linux conference I’ve attended in the US.
During the closing, Kristen Accardi did a brief survey on several aspects of the conference, and it seems that virtually everyone was happy with it. I think the conference has a bright future, as it seems to have filled a now obvious need for a place where a cross-section of mainline Linux developers can meet up specifically to solve problems.
It turns out I was able to make it to Linux Plumbers Conference, after another last minute change of circumstances, and I’m in fact in Portland.
Regretfully, it turns out I won’t be able to attend the Linux Plumbers Conference next week in Portland OR. This means I have a surplus transferable conference registration (currently costing $300).
If you’re an established FOSS community developer who is otherwise unable to obtain funding for registration, shoot me an email. I’ll transfer the ticket at no cost to whoever makes the first appropriate request.
Following up on a couple of the comments on my last entry on SELinux memory protections vs. Zend Optimizer:
The policy does indeed look like it was generated automatically by audit2why or similar. This very clearly highlights a core problem with “learning mode” security schemes, which can blindly encapsulate dangerous behavior in a buggy application, or even an attack in progress. This issue was previously expounded by Josh Brindle in Status Quo Encapsulation.
Such techniques do have their place, although it is always recommended that such resulting policy be reviewed. Again, it is easy to find help.
It’s unfortunate that some vendors promote automated policy generation schemes as a core usability feature, leading many people to assume that this is a great idea, and even the way things are supposed to work.
Of course, nobody would ever capitalize on peoples’ combined fear and lack of expertise in an area and sell a “miracle” solution which doesn’t quite work. No, that would never happen.
As H.L. Mencken and some character on the single episode of CSI I suffered through said: “… there is always an easy solution to every problem — neat, plausible and wrong.”.
The idea that the problem of OS security can be solved effortlessly with the click of a mouse should be raising alarm bells in everyone’s heads by now, surely ?
I don’t know what a Zend Optimizer is, but it apparently does not play well with SELinux. I’ve encountered a blog entry by someone who has tried to do the right thing and keep SELinux enabled, after finding the code for a policy module which makes this stuff work.
I was surprised when I saw the source of the module, which includes:
allow httpd_t self:process execstack;
allow httpd_t self:process execmem;
allow httpd_t self:process execheap;
allow httpd_t usr_t:file execute;
When loaded, this will enable the web server to execute memory on its heap, stack or certain types of executable memory allocated via mmap(2). These are well-known attack vectors and disable some very important memory protection mechanisms. See Ulrich Drepper’s SELinux Memory Protection Tests for details.
The file execute permission is also very concerning, as it allows the web server to execute generically labeled user files. Combined with disabled memory protections, and third-party software using unsafe memory execution techniques, I’d recommend being cautious about deploying this solution.
What I would suggest, if you don’t understand the security policy, is to run it by your nearest SELinux community. Many mailing lists and IRC channels exist where people will be able to help: see User Resources from the SELinux Project Wiki.
It’s important to note that whatever this code is supposed to be doing (apparently, dealing with some form of source code obfuscation), techniques such as making a stack executable are inherently insecure and should never be necessary.
SELinux really is trying to help you here, and free expert advice is merely an email away. At the very least, someone will be able to explain what the risks are, and help you make an informed decision on how to proceed: perhaps it will be better for your particular requirements to allow certain accesses rather than disabling SELinux for the entire system. And if the code is not trying to do something dangerous, an SELinux developer may write a simple module for you to load to work around the issue.