commit b53ea90001a5a89c6839bdf220e857a3e936ef73 Author: Jacob Appelbaum jacob@appelbaum.net Date: Thu Apr 18 23:41:35 2013 -0700

Add first draft of notes on how we harden and how we plan to evolve --- HARDENING | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+)

diff --git a/HARDENING b/HARDENING new file mode 100644 index 0000000..479b355 --- /dev/null +++ b/HARDENING @@ -0,0 +1,59 @@ +Platforms offer varying security features; we'd like to support the best. + +This is a document that notes which security hardening we have implemented and +which things we'd like to see implemented for various platforms. We +specifically address exploitation mitigation and containment; security issues +such as x509 certification validation are not addressed here. Patches, +suggestions and improvements are welcome! We always want the strongest set of +options by default on each supported platform. + +On all platforms we attempt to support available compiler hardening and linking +options. Please do not disable these options. Additional compiler and linker +hardening options are welcome and the current options are implemented in the +following file: + + configure.ac + +On all platforms, we attempt to switch from the administrative user to an +unimportant role account which shares data with no other processes. If we start +as any user other than an administrative user, we will likely be unable to +switch to our normal unprivileged account. These users are defined at +`configure` time. + +In addition to the above hardening options, we have tried to extend our +hardening when the platform supports it. Each additional security measure that +we take is documented as well as planned or desired improvements. + +We do not currently support or set ulimits, we should do so where possible. + +On Debian Gnu/Linux platforms, we ship with a minimal AppArmor profile, see +the policy for details: + + apparmor-profile + +We'd like to have an SELinux policy specifically for tlsdate. +We'd like to support capability dropping with libcap or libcap-ng. +We'd like to support libseccomp2 filters. +Other kernel hardening suggestions are welcome. + +On ChromeOS we use minijail and seccomp filters, see the following policies for +details: + + tlsdate-seccomp-amd64.policy + tlsdate-seccomp-arm.policy + tlsdate-seccomp-x86.policy + +These are enabled by default in ChromeOS. + +On FreeBSD, we'd like to support jails, chroot, and Capsicum. + +On OpenBSD, we'd like to support chroot and systrace. + +On NetBSD and DragonFly BSD, we'd like to chroot. + +On Mac OS X, we'd like to support chroot and seatbelt. + +On Plan9, we'd like to chroot. + +On other platforms, we'll try to run correctly with the understanding that any +bug is likely a much more serious problem.