Thu, 06 May 2010
Why I don't Like Ubuntu
I am not very fond of Ubuntu because of their leecher's attitude when giving back to upstream. That said, I have considered Greg Kroah-Hartmann's LPC 2008 keynote being a bit rude. Two years later, I have to admit Greg K-H was right:
In this bug report they discuss a kernel performance problem in their enterprise version (LTS). Ted Ts'o has recommended a temporary fix while suggesting to focus on building their own kernel dev team in order to be able to solve such a problem faster.
In response, they have opened a Fedora bug.
Source: Dave Airlie's blog.
2 replies for this story:
Marcel Kolaja wrote:
LTS is not an enterprise version of Ubuntu.
neotronic wrote:
yeah, that is what I dislike about canonical too. They contribute to upstream rarely, rip off debian (i know, it's legal, but i don't think it's legitimate) and always tell the upstream developers, that is better to release the software so that ubuntu can integrate it than to release it when the upstream developers think it's ready to release .
Reply to this story:
Wed, 05 May 2010
Uncovering the Hidden (this time in elinks)
The problem with userland apps (like OpenOffice.org) is that the code is rarely reviewed by anybody outside the development team. From time to time it is possible to read frustrated reports written by people who try to make the system boot as fast as possible, or to preserve as much battery capacity as possible. Those people actually look at what the applications are doing, and are often very surprised. Confining apps under SELinux is a similar kind of frustrating job. I have almost finished confining OO.org, and I have tried to confine elinks for HTML-to-text conversion. The gems found so far are:
elinks -no-references -dump local-file.htmlstill reads the CA certificates bundle, even though it is not expected to make any HTTPS connection at all.- It creates a new TCP socket, sets it to non-blocking mode, calls
getpeername(2)on it (it obviously fails as the socket has not been connected anywhere yet), and then does completely nothing with it:socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 fcntl(7, F_GETFL) = 0x2 (flags O_RDWR) fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0 brk(0x2121000) = 0x2121000 getpeername(7, 0x7fff0afb51f0, [112]) = -1 ENOTCONN
I have tried todontauditthe socket creation, but elinks segfaults then. - It tries to
stat(2)and thenopen(2)directories for temporary files:/tmp,/var/tmp, and even/usr/tmp(!). It reads them but does nothing else with them.Dontaudithere works as expected. - Of course, seeing
open(2)afterstat(2)cries "possible race condition security hole ahead" quite loudly. Why notopen(2)directly, and—if necessary—fstat(2)later?
I did not have time to look at the source code, so I refrain from filling a bug report or sending a patch for now.
0 replies for this story:
Reply to this story:
Tue, 04 May 2010
Confining OpenOffice.org
I don't use OpenOffice.org except for occasionally reading a .doc
file people send to me instead of writing in plain text. I don't know
anything about its internals, and I only have a general feeling
that OO.org is a huge bloated mess[1]. Today I have attempted to confine OO.org
under SELinux in order to be able to convert untrusted documents
to PDF or HTML. I am still not done, but my experience so far has
brought the term "huge bloated mess" to a completely new level.
Here are few examples:
- OO.org is a spaghetti-like set of scripts, binaries and libraries calling each other, sometimes even via shell. So confining OO.org would mean to allow the shell to be executed under the domain which I want to confine it under. Talk about tightly specified rules.
- OO.org components communicate with each other over several different
transports: sometimes it uses an unnamed pipe, there are socketpairs,
and there is even a named socket under
/tmp. - Even though OO.org has configuration option for specifying the
directory under which temporary files are created, some of those files
are created directly under user's home directory, and some of them
under
/tmpno matter what. - OO.org even attempts to execute some of its temporary files!
- Even in batch mode, it still tries to read the
/mediadirectory.
On a positive side, OO.org with the -headless option now
finally can run without actually requiring a connection to the X server
(I have discovered it only after spending several hours writing a policy
for confining Xvfb. Oh well).
I wonder how many security holes in OO.org are waiting to be discovered, because I can't imagine at all how such a code base can be audited for security problems.
[1] Things like mixing Java, C, and their own scripting language for extensions, dialog windows which keep popping up no matter how many times I attempt to close them, their document recovery dialog, and other minor and major surprises.
2 replies for this story:
Adelton wrote: Shell
There's really no problem running the shell under the confined domain. It won't need to transition, just use the same domain as the calling process. As for the /media directory, it's mnt_t -- just dontaudit it if you are sure you won't need it, and you are done. In general, I wonder if Dan Walsh's sandbox or sandbox -X could be the thing you're looking for.
Yenya wrote: Re: Shell
I have of course already dontaudited mnt_t. But I still think it would be more tightly confined when no exec(2) would be required (and shell - as opposed to exec(2) of a simple program - is much worse). I have of course looked at sandbox (the new oo.org does not need -X).