Projects/Propolice
From Mandriva
Introduction
The ProPolice (web page at http://www.trl.ibm.com/projects/security/ssp) stack protection technology adds protection from exploitability of buffer overflows at compiler level.
It adds two new arguments to the compiler: -fstack-protector and -fnostack-protector. They turn it on and off.
How does this work
From [OpenBSD homepage]:
"...function prologues are modified to rearrange the stack: a random canary is placed before the return address, and buffer variables are moved closer to the canary so that regular variables are below, and harder to smash. The function epilogue then checks if the canary is still intact. If it is not, the process is terminated. This change makes it very hard for an attacker to modify the return address used when returning from a function."
Other systems using it
Currently OpenBSD in the latest 3.3 version uses it by default. All software comprising OpenBSD is compiled with stack protection turned on, and the option is also on for gcc by default.
I've used it on my server and it doesn't seem to negatively affect any functionality.
Performance loss
See this page for benchmarks and comparison to other similar protection technologies: http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000000000000000
They state that in worst case it can add 8% performance loss. Worst case being a program that uses massive amounts of function calls, with extremely short function bodies. In practice, it's been shown to not exceed 4% with the Perl benchmark, and be close to 0% for imapd.
Proposed organisation of inclusion in Mandrake
I propose that the standard GCC shipped with Mandrare be patched to with ProPolice. The protection should be inactive by default (as it causes slight performance degradation and can potentially make some software not work).
Then the packages comprising Mandrake should be divided into several categories (in decreasing order of protection importance):
daemon processes listening on the network, running with root privileges
- samba server, winbind (it may be possible for winbind to run as non-root)
- cups (cupds runs as root AFAIK)
- proftpd server
- openssh server
- postfix (I know, the listening process is unprivileged, but it passess data on to privileged local delivery daemon)
- pop3, imap server
- rpc (portmap runs as rpc) and nfs (rpc.mountd and rpc.quotad run as root, rpc.statd as rpcuser)
- XFree (X11 on socket 6000 open by default)
- snort
- prelude
- others - package maintainers know better than me, please complete this list...
libraries used by aforementioned daemons
- glibc?
- libsasl
- samba common (samba does not use any shared libraries it provides, libsmbclient is use mostly by clients such as kios_smb when compiled against it)
- libldap (samba-2.2.x with ldap - non-default build, samba>=3.0.0)
- krb5-libs (samba >= 3.0.0)
- libcups (samba)
- openssh
- others - package maintainers know better than me, please complete this list...
suid root binaries
- smbmnt/smbumount
- crontab
daemon processes listening on the network, running as unprivileged users
- apache server
- apache extensions (mod_php, mod_perl etc.)
- bind dns server
- squid
- openldap
- mysql
- postgresql
libraries used by aforementioned daemons
- openssl
- perl
- php
- python
- others - package maintainers know better than me, please complete this list...
popular network client applications
(popularity being the most important factor as those more popular are more likely to be attacked)
- samba-client
- openssh-clients
- mozilla
- konqueror
- galeon
- evolution
- kmail
- gaim
- OpenOffice (e-mail attachments are opened mindlessly and automatically by users, almost like network protocol handlers...)
libraries used by aforementioned applications
- kdebase
- no idea :( ...
less popular network applications
- bitchX
- licq
libraries used by aforementioned applications
- no idea :( ...
local tools, not network related
- bash
- fileutils
- dia
- lyx
- tetex
- the remaining stuff
Please, help me complete this list.
Ideas (how to effect this on the distro)
Build with protection according to a fixed policy
(Idea by AleksanderAdamowski)
The policy would be agreed upon by Mandrake people for each release.
A typical policy
Build with protection the packages that meet a certain threshold on the aforementioned list
The decision on threshold at which the protection should begin would have to be supported with a poll on MandrakeClub during the period a significant time before the next version is released.
Example policies
- The packages that belong to the first 2 groups would have to be compiled with propolice unconditionally.
- The packages that belong to the first 6 groups (that's more paranoid)
A parallel system of packages with a different release prefix (e.g. not mdk but mdks)
(Idea by Giuseppe Ghibò):
An alternative would be to have a parallel protected build of all the applications (e.g. with RPM named "mdks" instead of "mdk") and let users (or installer) decide to which level install the protected one (e.g. level5 install stack protected RPM version only for the running daemons, level10 install the stack protected RPM version for everything).
RPMs
A standard has to be established WRT comstruction of Mandrake RPMs. All SRPMs need to support 2 build switches:
--with propolice --with no_propolice
A SRPM would default to one of those two options, depending on its category.
