[ubuntu-hardened] Removing suid room from binaries where it isn't needed

Jeff Schroeder jeffschroed at gmail.com
Tue Oct 30 20:15:14 GMT 2007


gaten wrote:
> It would be great if we could forgo any "Ubuntu specific" patches, but I
> understand that might not be possible.

Understand that these "Ubuntu specific" patches would go immediately
upstream to be merged with the next release (with the maintainer's
buyin).

> God yes. SUID has always been a problem (or at least an attack vector),
> and I for one can see no reason NOT to do this, as long as we aren't
> breaking a million other things in the process.

The key to properly rolling this out involves:
- Packaging the userspace tools, filing a MIR, and getting them in
main. This allows interested volunteers to start working on this as
soon as the kernel team starts uploading the 2.6.24 series kernel to
the Hardy repos.
- Doing a quick look through what affected binaries can be quickly
fixed to remove suid root and which can't without patches.
- Writing patches where appropriate and sending patches upstream
- Figuring out a proper way to remove suid root and add the
capabilities. My thoughts were some sort of an apt-trigger similar to
the wrapper around ldconfig. What do you think?

We should try to minimize the diff from Debian as much as possible and
get their buyin where appropriate. Does anyone know the proper
security contacts who we should talk to about this? I started doing
this awhile ago with the cap_over[1] kernel module and the perl script
is provides to do the same thing involving adding caps on a per inode
basis. It isn't all that hard.

It doesn't take forever as long as your are comfortable with strace,
capabilities(7), looking at kernel headers, and the software's source
code.

[1] http://www.randombit.net/projects/cap_over/

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the ubuntu-hardened mailing list