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, ) = -1 ENOTCONNI have tried to
dontauditthe socket creation, but elinks segfaults then.
- It tries to
open(2)directories for temporary files:
/var/tmp, and even
/usr/tmp(!). It reads them but does nothing else with them.
Dontaudithere works as expected.
- Of course, seeing
stat(2)cries "possible race condition security hole ahead" quite loudly. Why not
open(2)directly, and—if necessary—
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.