codeblog code is freedom — patching my itch

September 14, 2010

my part in the ecosystem

I was asked to write about what I do at Canonical and what I do in the Free Software community at large. There is obviously a great deal of overlap, but I’ll start with the things I’m involved with when I’m wearing my “Ubuntu” hat.

My primary job at Canonical is keeping Ubuntu secure. This means that I, along with the rest of the Ubuntu Security Team, coordinate with other Free Software distributions and upstream projects to publish fixes together so that everyone in the community has the smallest possible window of vulnerability, no matter if they’re running Ubuntu, Debian, RedHat/Fedora, SUSE/openSUSE, Gentoo, etc. Between vendor-sec, oss-security, and the steady stream of new CVEs, there is plenty going on.

In addition to updates, the Security Team works on pro-active security protections. I work on userspace security hardening via patches to gcc and the kernel, and via build-wrapper script packages. Much of this work has been related trying to coordinate these changes with Debian, and to clean up unfinished pieces that were left unsolved by RedHat, who had originally developed many of the hardening features. Things like proper /proc/$pid/maps permissions, real AT_RANDOM implementation, upstreaming executable stack fixing patches, upstreaming kernel NX-emu, etc. Most of the kernel work I’ve done has gotten upstream, but lately some of the more aggressive protections have been hitting frustrating upstream roadblocks.

Besides the hardening work, I also improve and support the AppArmor Mandatory Access Control system, as well as write and improve confinement profiles for processes on Ubuntu. This work ends up improving everyone’s experience with AppArmor, especially now that it has gotten accepted upstream in the Linux kernel.

I audit code from time to time, both “on the clock” with Canonical and in my free time. I’m no Tavis Ormandy, but I try. ;) I’ve found various security issues in Xorg, Koffice, smb4k, libgd2, Inkscape, curl+GnuTLS, hplip, wpa_supplicant, Flickr Drupal module, poppler/xpdf, LimeSurvey, tunapie, and the Linux kernel.

With my Canonical hat off, I do all kinds of random things around the Free Software ecosystem. I’m a sysadmin for kernel.org. In Debian, I maintain a few packages, continue to try to push for security hardening, and contribute to the CVE triage efforts of the Debian Security Team.

I’ve written or maintain several weird projects, including MythTVFS for browsing MythTV recordings, GOPchop for doing non-encoding editing of MPEG2-PS streams, Perl’s Device::SerialPort module, and the TAP paging server Sendpage.

For a selection of things I’ve contributed to other project, I’ve implemented TPM RNG access in rng-tools, made contributions to Inkscape‘s build and print systems, implemented CryptProtect for Wine, wrote a PayPal IPN agent in PHP that actually checks SSL certificates unlike every other implementation I could find, added additional protocol-specific STARTTLS negotiations to OpenSSL, implemented the initial DVD navigation support in MPlayer, updated serial port logic in Scantool for communicating with vehicle CAN interfaces, tried to add support for new types of timeouts in Snort and Ettercap, fixed bugs in mutt, and added HPUX audio support to the Apple ][ emulator XGS.

As you can see, I like making weird/ancient protocols, unfriendly file formats, and security features more accessible to people using Free Software. I’ve done this through patches, convincing people to take those patches, auditing code, testing fixes and features, and doing packaging work.

When I go to conferences, I attend UDS, DefCon, OSCon, and LinuxCon. I’ve presented in the past at OSCon on various topics including security, testing, and video formats, and presented at the Linux Security Summit (miniconf before LinuxCon this year) on the need to upstream various out-of-tree security features available to the Linux kernel.

I love our ecosystem, and I love being part of it. :)

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

June 18, 2008

Linux Plumbers Conference 2008

Filed under: Blogging,kernel.org,Ubuntu — kees @ 10:17 am

The Call for Speakers (and registration) for the Linux Plumbers Conference is open! Get those proposals in, register, and come join us in sunny Portland, OR.

The Linux Plumbers Conference was created to bring together the key developers involved in Linux plumbing – the “Linux plumbers” – and give them an opportunity to discuss problems face-to-face, both within subsystems and across subsystems. Participants include invited attendees, speakers selected through an open, competitive review process, and students. Registration is open to the general public as well.

The goal of the Plumbers Conference is to solve problems. The conference is arranged as a series of microconferences, each on a topic that is narrow enough to identify specific problem areas and brainstorm workable solutions. Each microconference is led by an expert in the field and organized to encourage discussion and problem solving.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 9, 2006

metalink

Filed under: kernel.org,Networking — kees @ 10:47 am

I’ve been watching metalink for a while now, and was urged to write about it, so I am! If you want to download something large that isn’t available via bittorrent, you can still get the distributed download benefits of bittorrent. Basically, metalink-aware downloaders split up your download across many mirrors of the resource you want, using existing protocols.

Bittorrent is great for “new releases” or other similiar things that are currently “in demand” by a large number of people. For older stuff, especially large trees of files, as found on many mirrored archives, you won’t find a bittorrent, and metalink can really distribute and speed up the download.

OpenOffice is using it, and I hope to figure out a way to incorporate it into kernel.org directly. There are already places hosting auto-generated metalink files for various projects, including the linux kernel. I’m hoping kernel.org can publish more complete metalink files since we should be able to build them more easily, having the list of which mirrors are in which countries, their access mechanism, and if they carry bz2, gz, or both. We’ve talked about it briefly, but haven’t finalized the plans yet.

You can even generate your own metalink files online.

Another blog has other details, so I hope I’ve not been too redundant. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 16, 2006

kernel.org and sendfile

Filed under: kernel.org,Networking,Security — kees @ 4:50 pm

The “sendfile” system call is a way to send file contents directly out to a network socket. This saves time in userspace (so it doesn’t have to copy buffer contents around), and was one of the reasons I upgraded kernel.org‘s Apache to version 2.x at the end of 2003 (because version 1.x doesn’t have sendfile support). A few weeks ago, one of the other kernel.org admins discovered that files greater than 2G were not being delivered by Apache.

I had a lot of fun tracking down the issue. The “amount to send” argument in the sendfile call is a “size_t”, which is basically an “unsigned long”. Having a 2G limit didn’t make sense, since even with 32 bits, that should be a 4G limit. However, the kernel.org servers are both 64bit, so as it turns out, “size_t” is a full 64 bits. After writing a quick test, I was able to verify that it was, indeed, a 31 bit limit on both 64 bit and 32 bit kernels. Peter Anvin took it from here, and tracked down the origin of the problem: filesystem operations greater than 31 bits in offset were being rejected deep in the kernel. He suggested truncating the request instead of returning a failure.

Seems as though Linus decided to limit the size of filesystem calls to make sure there aren’t security problems (signed vs unsigned overflows) in the various filesystem drivers, while people using the Linux kernel migrate more from 32bit to 64bit systems. Personally, I don’t agree with this, but from a practical stand-point, it hardly makes a difference. Instead of sending all 4G out the pipe and returning to user space, it just returns twice, sending 2G per call.

This should be fixed in 2.6.16. Until then, we could patch Apache to keep it’s offset request under 31 bits, but we’ll probably just tell people to use FTP, since vsftpd doesn’t use sendfile yet.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 17, 2005

kernel.org at OSUOSL

Filed under: kernel.org — kees @ 6:54 pm

I joined the OSUOSL guys to meet master.kernel.org as it was flown in from California this morning. The master server’s new home is just above a stack of Mozilla servers at the OSL’s facilities. Great place. Nice people (some with blogs). Lots of bandwidth. :)

Afterwards, I got invited to OSU’s annual “Geeks and Steaks” picnic. That was great, and I got to meet all sorts of other folks that work in the IT groups at OSU and stand around watching them light the BBQ. No liquid oxygen, but, then, they all wanted to keep their arm hair, I guess.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

May 3, 2005

nice kernel.org write-up

Filed under: kernel.org — kees @ 2:50 pm

As if a blog itself wasn’t enough shameless self-promotion, I’ve just gotta share more! There’s a nice write up at Kernel Trap on how the kernel.org servers work. I’m mentioned in there since I’m one of the guys that helps keep the machine running. Mostly I manage the mirror server validations. I’m the guy that bugs the other mirror admins about falling behind, etc. The real work is done by HPA and Nathan. They’ve got some great gear in place now. I can’t wait until the next Fedora Core release; it really drives the machines hard. I think it’s great to log into a fairly responsive machine, and see a load average over 200. And then realize that that’s normal. I love it!

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

Powered by WordPress