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 3.0 License.

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 3.0 License.

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 3.0 License.

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 3.0 License.

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 3.0 License.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.