1 |
Hi everyone, |
2 |
|
3 |
During the last meeting of the hardened team [1], we discussed the issue |
4 |
of the proper use of the global "hardened" flag. Because "hardened" has |
5 |
various meanings the flag is being (ab)used in various way. Primarily |
6 |
there are two distinct meanings that need to be distinguished in the tree. |
7 |
|
8 |
1) hardened toolchain which means SSP, PIE, FORTIFY_SOURCES=2 and all |
9 |
the good stuff. |
10 |
|
11 |
2) hardened kernel which is complicated by the fact that there are many |
12 |
hardening features the user can choose from. These, however, fall into |
13 |
three groups, "pax", "grsec" and "selinux". |
14 |
|
15 |
An example of using "hardened" in the first sense is mail-mta/postfix. |
16 |
Examples of using it in the second sense are app-admin/syslog-ng and |
17 |
dev-lang/mono. |
18 |
|
19 |
Since there are some users which use a hardened toolchain, but not a |
20 |
hardened kernel and vice versa, this ambiguity leads (and has led) to |
21 |
undesirable consequences. |
22 |
|
23 |
Here's how we propose to disambiguate the flag: |
24 |
|
25 |
1) The current "hardened" flag will mean only the toolchain. Setting it |
26 |
globally means that the user wants a hardened toolchains + resulting |
27 |
hardened binaries upon emerge -e world. |
28 |
|
29 |
2) The choice of a hardened kernel is made by emergeing |
30 |
hardened-sources, configuring, compiling, booting. There is no use flag |
31 |
for this choice per se. That means that virtual/linux-sources would |
32 |
remove the condition RDEPEND: |
33 |
|
34 |
hardened? ( =sys-kernel/hardened-sources-2.6* ) |
35 |
|
36 |
and simply replace it with |
37 |
|
38 |
=sys-kernel/hardened-sources-2.6* |
39 |
|
40 |
3) Since a hardened kernel can be configure with various flavors of |
41 |
"pax" or "grsec" or "selinux", there should be useflags to reflect |
42 |
userland needs to conform. There already is a "selinux" flag which is |
43 |
set by selinux profiles. Currently we don't see a need for a "grsec" |
44 |
flag, however, there is a need for a "pax" global use flag which we |
45 |
propose calling "pax_kernel". (If nothing else to distinguish it from |
46 |
app-arch/pax.) |
47 |
|
48 |
Userland binaries which will run under a pax enabled kernel may need |
49 |
special treatment to run, or else they'll be killed by the kernel. The |
50 |
best example here is an RWX mmapping. Although the ideal case is to |
51 |
"fix the code" this is not always feasible and so binaries will still |
52 |
need markings with paxctl -m. |
53 |
|
54 |
4) The hardened team will work with maintainers to clean up the flags. |
55 |
|
56 |
|
57 |
Thanks, and we await comments. |
58 |
|
59 |
--The hardened team. |
60 |
|
61 |
Ref |
62 |
[1] |
63 |
http://archives.gentoo.org/gentoo-hardened/msg_040568ebe0a2f55c76820cfdcf8a0ff9.xml |
64 |
|
65 |
-- |
66 |
Anthony G. Basile, Ph.D. |
67 |
Gentoo Linux Developer [Hardened] |
68 |
E-Mail : blueness@g.o |
69 |
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 |
70 |
GnuPG ID : D0455535 |