"Debian: Secure by Default" is a project to examine various security feauters available to the open source community and bring those which do not cause end user complications to Debian's standard distribution. The goal is to make Debian GNU/Linux a simple but effective example of excellence in security, without sacrificing any of Debian's current or future ease of use.
There is no point in separating discussions on securing Debian. Rather than creating a D:SbD forum and/or IRC channel, those interested in discussing security features in Debian are encouraged to join the Hardened Debian IRC channel #debian-hardened on Freenode.
After reading through the content of this web site, please take our survey if you have an Alioth account. Aggregated results of the survey will be made visible to the public (as soon as I figure out how); individual responses and identities of individuals in general are not visible to the project administrators nor to the general public.
Systems proposed here aren't new inventions; they come from things found on the net, especially in other distros and OSes such as Hardened Gentoo, OpenBSD, and Adamantix. D:SbD only attempts to bring these technologies to everyone's attention so that review may be given, and if possible, so that they can be moved into Debian to improve the future experience of users by better guarding them against future viruses, worms, and crackers.
To the left, you can see a rough estimate of the total performance impact of all features suggested by D-SbD combined. The top graph indicates the performance impact assuming -fomit-frame-pointer is not used; while the bottom value is compared against an -fomit-frame-pointer system. There are several caveats when measuring performance, most having to do with Position Independent Executables.
The first caveat is that the -fomit-frame-pointer optimization can give a 5% performance gain on x86. This optimization does not seem to gain anything with Position Independent Code. Thus this is a "lost gain," which can be considered to be 0 in relation to a reference environment only using normal optimizations (remember, -fomit makes debugging impossible on many archs).
The second caveat is that the overhead from making position independent executables should be calculated as a fraction of the cost of PIC code; unfortunately, what fraction that is is unknown at this time. All code in libraries is already PIC, and thus unaffected by making executables PIC.
The final caveat is that the overhead of SSP cannot be measured, as it is highly dependent on program structure and flow. It is completely discarded, but is very low.
Please note with overhead the following facts, based on single CPU machines:
"Debian: SbD" is not a core Debian project (at the time of this writing). As such, it has no forcefulness over what does and does not go into Debian GNU/Linux. Thus, D:SbD needs a influential angle to make its proposed changes go upstream.
D:SbD follows a plan of action outlined on the site for public view. The project concentrates mainly on diffusing information to the Debian maintainers and users; other projects such as Hardened Debian or the Debian maintainers themselves have to work to implement these features.
D:SbD plans to demonstrate simple implementations of the security features detailed here. These demonstrations are normally smallscale; but larger scale demonstrations such as refabricated Knoppix CDs are being examined, as such a thing would make an excellent largescale demonstration.