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