This is a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and systems of Debian contributors and users. If you would like to help make Debian more secure, help on all of these topics is welcome. Don't be intimidated by the length of the list, pick the things you can do something about and put some time into them. If you aren't sure about how to start helping on a particular item, the debian-mentors list should be able to direct you.
Get more people to get involved in Debian so that we have enough people to continue it and keep it secure into the future.
Encourage more contributors to use Tor so that they are less easily targeted by active attackers.
Prevent installing packages with unpatched vulnerabilities, see 431804 for some debscan/apt integration ideas.
Build all binary packages, installer images, preinstalled images and live images on official Debian machines (buildds etc).
Fix the various issues with the security and privacy of apt and image mirrors.
Recruit more people to join the security issue tracking effort.
Revive the security audit project.
Revive static analysis services like DACA, firewoes, debile etc.
Periodically send notifications of open vulnerabilities to maintainers.
Encourage package maintainers to check their packages using various tools before upload:
Package more tools for testing the security of both code and installed systems.
Push the compiler flags hardening release goal. Push GCC/LLVM upstreams to enable these by default.
Enable various security features in the Linux kernel, for example hidepid fs.protected_symlinks etc.
Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references.
GCC >= 4.8 also supports ASan (?AddressSanitizer). Some info:
Another similar idea is to have a page like http://clang.debian.net/ building the Debian archive with Clang AddressSanitizer enabled and reporting the unexpected failures when running the package's unit tests.
Refuse to use proprietary software on our personal Debian development machines and on Debian project machines and switch to hardware with free and auditable firmware. Develop security guidelines for personal Debian development machines.
Constructively attack the use of markets/repositories that distribute non-free software, helping make developer machines safer and make developers more aware of the risks:
- third-party Eclipse plugin sites
- can the packaged version of Eclipse be patched to direct people to 100% free alternatives to any non-free plugin they try to install?
- Maven Central repository
- many binary JARs here claim to be free software but they are not and the source can't be found
- can the Debian version of maven be patched to refuse to download any JAR that can't be traced to source?
- insert examples
- try and ensure the popular artifacts from any of the above repositories are available through Debian itself so that people don't need to trust so many other distribution sites
All of the above for code that we run but don't package.
Work on improving FreedomBox security and port the improvements into Debian.
Educate upstreams about upstream best practices.
Develop/package a tiger-like tool like this that provides suggestions and tips to less technical (desktop) users.
Also see DebianSanctuary
Non-Debian attack vectors:
- Help people free their mobile devices / smartphones and improve security practices (e.g. email password stored in a mobile device is very vulnerable)
- Help people free their routers
- Make it easier to install (insert name of preferred firmware)
- Make a shortlist of routers that are easy to re-flash (the full list of supported routers on OpenWRT is not always helpful for people wanting to make a quick purchasing decision)
Advertise the Securing Debian Manual and keep it up-to-date (maybe turn it into a wiki?)