SecurityBOF
How to improve proactive security in Ubuntu
Derootification
- ongoing process, much is already done
- short discussion about derooting X
Compiler enhancements
SSP:
provides reasonable buffer overflow protection (http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/mechanism.html)
implemented in OpenBSD by default, supported in Gentoo (http://www.gentoo.org/proj/en/hardened/propolice.xml)
- well tested, little runtime overhead
- not adopted/supported in gcc upstream, mainly because of bad communication/interaction
compile time change, requires rebuilding the whole archive -> too late for Hoary
- we could apply the patch and provide a package in universe for people to play around with
mudflap:
- integrated in gcc 4
- more like a debugging tool, no real runtime check
gcc 4.1 smashing stack protection:
- kind of SPP, eventually rewritten and adopted in gcc upstream (gcc 4.1, not yet released).
- from the gcc changelog: GCC can now emit code for protecting applications from stack-smashing attacks. The protection is realized by buffer overflow detection and reordering of stack variables to avoid pointer corruption.
- from the gcc changelog: Some built-in functions have been fortified to protect them against various buffer overflow (and format string) vulnerabilities. Compared to the mudflap bounds checking feature, the safe builtins have far smaller overhead. This means that programs built using safe builtins should not experience any measurable slowdown.
- as SPP, requires building the archive with it to be effective.
- when gcc 4.1 will come out this implementation will not be well tested as was SPP, so require caution.
Kernel enhancements
- execshield: mentioned, but not discussed (comparable to OpenBSD's W^X)
PaX (http://pax.grsecurity.net/):
- separates writeable and executable memory, which collapses former root exploits into denial of services
- upstream mainly supports 2.4 due to the huge 2.6 commit rate
- latest available patch is for 2.6.7, needs tweaking to apply to 2.6.9
Mandatory access control
- SELinux is a pain to integrate; other systems are much easier, but do not receive upstream support
- possible future: provide different profiles (tight server, easy server, desktop, etc.)
- SELinux requires a bunch of patched packages and dpkg support, hard to switch to it right now
Chrooting
processes running as root can break out of a chroot (at least without OpenWall etc. patches)
- processes that run as a normal user normally cannot breakout, but chrooting them does not bring much benefit
- postfix already supports chrooting (Jeff: let's run everything in postfix then)
Misc
- hardened glibc: no information available, probably already upstream
- userv could help to provide more fine-grained privilege separation
short talk about using automated valgrind checking -> hard to reach the critical cases
Assignments
- Fabio: compile Kernel with SELinux, off by default
- Martin: provide PaX kernel in universe
- Martin: compare various kernel enhancements (technical and support-wise) of distros/bsd/etc.
SecurityBOF (last edited 2008-08-06 16:39:34 by localhost)