1 Platforms offer varying security features; we'd like to support the best. 2 3 This is a document that notes which security hardening we have implemented and 4 which things we'd like to see implemented for various platforms. We 5 specifically address exploitation mitigation and containment; security issues 6 such as x509 certification validation are not addressed here, yet. Patches, 7 suggestions and improvements are welcome! We always want the strongest set of 8 options by default on each supported platform. 9 10 We attempt to use the C programming language correctly and in a standard way. 11 We do however use some compiler specific options such as defining integer 12 wrapping because we believe the practical benefit outweights the implied risks. 13 As such, we prefer to be explicit rather than implicit in our casting or other 14 possible ambiguity. 15 16 We should treat all compiler and linker warnings as fatal errors. Currently, 17 consider autotools warnings to be an exception as we would like to support 18 platforms imperfectly rather than not at all. We generally wish to support 19 autotools bootstrapping on all of our supported platforms. This is not possible 20 on Plan 9. Currently autotools will complain on the BSD systems. 21 22 On all platforms we attempt to support available compiler hardening and linking 23 options. Please do not disable these options. Additional compiler and linker 24 hardening options are welcome and the current options are implemented in the 25 following file: 26 27 configure.ac 28 29 On all platforms, we attempt to switch from the administrative user to an 30 unimportant role account which shares data with no other processes. If we start 31 as any user other than an administrative user, we will likely be unable to 32 switch to our normal unprivileged account. These users are defined at 33 `configure` time. It is most effective if such a user is not the traditional 34 'nobody' or group 'nogroup' as is often the tradition. 35 36 In addition to the above hardening options, we have tried to extend our 37 hardening when the platform supports it. Each additional security measure that 38 we take is documented as well as planned or desired improvements. 39 40 We do not currently support or set ulimits, we should do so where possible. 41 42 On Debian Gnu/Linux platforms, we ship with a minimal AppArmor profile, see 43 the policy for details: 44 45 apparmor-profile 46 47 We'd like to have an SELinux policy specifically for tlsdate. 48 We'd like to support capability dropping with libcap or libcap-ng. 49 We'd like to support libseccomp2 filters. 50 Other kernel hardening suggestions are welcome. 51 52 On ChromeOS we use minijail and seccomp filters, see the following policies for 53 details: 54 55 tlsdate-seccomp-amd64.policy 56 tlsdate-seccomp-arm.policy 57 tlsdate-seccomp-x86.policy 58 59 These are enabled by default in ChromeOS. 60 61 On FreeBSD, we'd like to support jails, chroot, and Capsicum. 62 63 On OpenBSD, we'd like to support chroot and systrace. 64 65 On NetBSD, we'd like to chroot. 66 67 On DragonFly BSD, we'd like to support chroot and jails. 68 69 On Mac OS X, we'd like to support chroot and seatbelt. 70 71 On Plan9, we'd like to chroot. 72 73 On Windows, we do nothing beyond compile time hardening. We'd like to do more. 74 75 On other platforms, we'll try to run correctly with the understanding that any 76 bug is likely a much more serious problem. 77
