Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status

Gentoo Archives: gentoo-commits

From: "Anthony G. Basile (blueness)" <blueness@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/hardened: index.xml pax-quickstart.xml
Date: Sat, 29 Dec 2012 22:54:44
Message-Id: 20121229225432.E8B812171D@flycatcher.gentoo.org
1 blueness 12/12/29 22:54:32
2
3 Modified: index.xml pax-quickstart.xml
4 Log:
5 Update Pax Quickstart to cover both PT_PAX and XATTR_PAX
6
7 Revision Changes Path
8 1.109 xml/htdocs/proj/en/hardened/index.xml
9
10 file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/index.xml?rev=1.109&view=markup
11 plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/index.xml?rev=1.109&content-type=text/plain
12 diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/index.xml?r1=1.108&r2=1.109
13
14 Index: index.xml
15 ===================================================================
16 RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/index.xml,v
17 retrieving revision 1.108
18 retrieving revision 1.109
19 diff -u -r1.108 -r1.109
20 --- index.xml 3 Nov 2012 12:00:59 -0000 1.108
21 +++ index.xml 29 Dec 2012 22:54:32 -0000 1.109
22 @@ -88,7 +88,8 @@
23 <resource link="/proj/en/hardened/roadmap.xml">
24 Hardened Roadmap
25 </resource>
26 -<resource link="/proj/en/hardened/hardened-debugging.xml">Hardened Debugging
27 +<resource link="/proj/en/hardened/hardened-debugging.xml">
28 +Hardened Debugging
29 </resource>
30 <resource link="/proj/en/hardened/hardenedxorg.xml">
31 Using Xorg with Hardened
32 @@ -97,13 +98,13 @@
33 Hardened Toolchain Technical Description
34 </resource>
35 <resource link="/proj/en/hardened/pax-quickstart.xml">
36 -A quickstart covering PaX and Hardened Gentoo
37 +PaX Quickstart Guide
38 </resource>
39 <resource link="/proj/en/hardened/pax-utils.xml">
40 PaX Utils
41 </resource>
42 <resource link="/proj/en/hardened/grsecurity.xml">
43 -Grsecurity2 QuickStart Guide
44 +Grsecurity2 Quickstart Guide
45 </resource>
46 <resource link="/proj/en/hardened/grsec-tpe.xml">
47 Grsecurity TPE Guide
48
49
50
51 1.14 xml/htdocs/proj/en/hardened/pax-quickstart.xml
52
53 file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml?rev=1.14&view=markup
54 plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml?rev=1.14&content-type=text/plain
55 diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml?r1=1.13&r2=1.14
56
57 Index: pax-quickstart.xml
58 ===================================================================
59 RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v
60 retrieving revision 1.13
61 retrieving revision 1.14
62 diff -u -r1.13 -r1.14
63 --- pax-quickstart.xml 28 Oct 2012 15:21:07 -0000 1.13
64 +++ pax-quickstart.xml 29 Dec 2012 22:54:32 -0000 1.14
65 @@ -1,30 +1,36 @@
66 <?xml version='1.0' encoding="UTF-8"?>
67 -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v 1.13 2012/10/28 15:21:07 swift Exp $ -->
68 +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v 1.14 2012/12/29 22:54:32 blueness Exp $ -->
69 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
70
71 -<guide>
72 +<guide lang="en">
73 <title>Hardened Gentoo PaX Quickstart</title>
74
75 <author title="Author">
76 + <mail link="blueness@g.o">Anthony G. Basile</mail>
77 +</author>
78 +<author title="Contributor">
79 + <mail link="klondike@g.o">Francisco Izquierdo</mail>
80 +</author>
81 +<author title="Contributor">
82 <mail link="tseng@g.o">Brandon Hale</mail>
83 </author>
84 <author title="Editor">
85 - <mail link="blackace@g.o">Blackace</mail>
86 + <mail link="blackace@g.o">blackace</mail>
87 </author>
88 <author title="Editor">
89 <mail link="solar@g.o">solar</mail>
90 </author>
91
92 <abstract>
93 -A quickstart covering PaX and Hardened Gentoo.
94 +Understanding and working with PaX in Hardened Gentoo.
95 </abstract>
96
97 <!-- The content of this document is licensed under the CC-BY-SA license -->
98 <!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
99 <license/>
100
101 -<version>1.4</version>
102 -<date>2007-09-11</date>
103 +<version>2.0</version>
104 +<date>2012-12-19</date>
105
106 <chapter>
107 <title>What is Hardened Gentoo?</title>
108 @@ -32,10 +38,13 @@
109 <body>
110
111 <p>
112 -Hardened Gentoo is a project interested in the hardening of a Gentoo system.
113 -Several different solutions are supported by us and there is a fair bit of
114 -flexibility to create your own setup. At the heart of a common Hardened Gentoo
115 -setup is <e>PaX</e>.
116 +The Hardened Gentoo project focuses on adding features to a Gentoo system
117 +that help resist security compromises. The approach is not always systematic,
118 +and many features that enhances security are added. Some of these compliment
119 +one another (eg. PIE from toolchain hardening and ASLR from PaX kernel hardening),
120 +and some are mutually exclusive (eg. SELinux and Grsecurity's RSBAC kernel
121 +hardening). This document focuses on <c>PaX</c> which adds security enhancement
122 +to that area between both kernel and user land.
123 </p>
124
125 </body>
126 @@ -48,62 +57,338 @@
127 <body>
128
129 <p>
130 -PaX is a patch to the Linux kernel that provides hardening in two ways.
131 +PaX is a patch to the Linux kernel that provides hardening in three ways.
132 </p>
133
134 <p>
135 -The first, <e>ASLR</e> (Address Space Layout Randomization) provides a means to
136 -randomize the addressing scheme of all data loaded into memory. When an
137 -application is built as a <e>PIE</e> (Position Independent Executable), PaX is
138 -able to also randomize the addresses of the application base in addition.
139 +<b>1.</b> The first protection provided by PaX is a judicious enforcement of
140 +non-executable memory. This prevents a common form of attack where executable
141 +code is inserted into the address space of a process by an attacker and then
142 +trigger, thus hijacking the process and possibly escalating privileges. The
143 +typical vector for the insertion is via user provided data that find its way
144 +into executable memory. By ensuring that "data" only lives in memory which is
145 +non-executable, and that only "text" is found in memory which is executable,
146 +PaX pre-emptively protects against this class of attacks.
147 </p>
148
149 <p>
150 -The second protection provided by PaX is non-executable memory. This prevents a
151 -common form of attack where executable code is inserted into memory by an
152 -attacker. More information on PaX can be found throughout this guide, but the
153 -homepage can be found at <uri>http://pax.grsecurity.net</uri>.
154 -</p>
155 +Try running the following with PaX's MPROTECT enforced and then not enforced
156 +to see this feature in action:
157 +</p>
158 +<pre caption="mmap-rwx.c: violate MPROTECT with RWX mmap">
159 +/*
160 + * Contrast compiling with:
161 + * gcc -UBAD -o mmap-rw mmap-rwx.c
162 + * gcc -DBAD -o mmap-rwx mmap-rwx.c
163 + */
164 +
165 +#include &lt;stdio.h&gt;
166 +#include &lt;stdlib.h&gt;
167 +#include &lt;sys/mman.h&gt;
168 +#include &lt;errno.h&gt;
169 +#include &lt;string.h&gt;
170 +
171 +int main()
172 +{
173 + size_t *m;
174 +
175 +#ifdef BAD
176 + m = mmap( NULL, 1024, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0 );
177 +#else
178 + m = mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0 );
179 +#endif
180 +
181 + if( m == MAP_FAILED )
182 + printf("mmap failed: %s\n", strerror(errno));
183 + else
184 + printf("mmap succeeded: %p\n", m);
185 +
186 + return 0;
187 +}
188 +</pre>
189
190 -</body>
191 -</section>
192 -</chapter>
193 +<p>
194 +Similarly, try running the following with EMULTRAMP both enabled and disabled.
195 +This convoluted code forces gcc to set up a trampoline for the nested function
196 +f2(). The trampoline is executable code which lives on the stack and could allow
197 +the user to inject their own code via the variable i.
198 +</p>
199 +
200 +<pre caption="trampoline.c: force gcc to generate a trampoline">
201 +/*
202 + * Contrast compiling with:
203 + * gcc -DTRAMPOLINE -o trampoline trampoline.c
204 + * gcc -UTRAMPOLINE -o trampoline trampoline.c
205 + *
206 + */
207 +
208 +#include &lt;stdio.h&gt;
209 +
210 +typedef void (*fptr)(void) ;
211 +
212 +void f0(fptr f)
213 +{
214 + (*f)();
215 +}
216 +
217 +void f1()
218 +{
219 + int i ;
220 + printf("Enter an interger: ");
221 + scanf("%d", &amp;i);
222 +
223 + void f2()
224 + {
225 + printf("%d: Bouncey bouncey bounce!\n", i);
226 + }
227 +
228 +#ifdef TRAMPOLINE
229 + f0(f2);
230 +#endif
231 +}
232 +
233 +int main ()
234 +{
235 + f1() ;
236 + return 0;
237 +}
238 +</pre>
239
240 -<chapter>
241 -<title>An Introduction to PIE and SSP</title>
242 -<section>
243 -<body>
244 +<p>
245 +<b>2.</b> The second is Address Space Layout Randomization (ASLR). This provides a
246 +randomization of the memory map of a process (as reported, for example, by
247 +pmap) and thus makes it harder for an attacker to find the exploitable code
248 +within that space. Each time a process is spawned from a particular ELF
249 +executable, its memory map is different. Thus exploitable code which may
250 +live at 0x00007fff5f281000 for one running instance of an executable may
251 +find itself at 0x00007f4246b5b000 for another. While the vanilla kernel
252 +does provide some ASLR, a PaX patched kernel increases that. Furthermore,
253 +when an application is built as a Position Independent Executable (<c>PIE</c>),
254 +even the base address is randomized. Try repeatedly running the following
255 +on both a vanilla and PaX kernel, with and without PIE:
256 +</p>
257 +<pre caption="aslr-test.c: randomize base addess for PIE">
258 +/*
259 + * Contrast compiling with:
260 + * gcc -o aslr-test-withpie -fPIC -pie aslr-test.c
261 + * gcc -o aslr-test-without -fno-PIC -nopie aslr-test.c
262 + *
263 + */
264 +
265 +#include &lt;stdio.h&gt;
266 +
267 +void doit()
268 +{
269 + ;
270 + return ;
271 +}
272 +
273 +int main()
274 +{
275 + printf("main @ %p\n", main);
276 + printf("doit @ %p\n", doit);
277 + return 0;
278 +}
279 +</pre>
280
281 <p>
282 -As mentioned above, PaX is complemented by PIE. This method of building
283 -executables stores information needed to relocate parts of the executable in
284 -memory, hence the name <e>Position Independent</e>.
285 +For more information on PIE, see our documentation on the
286 +<uri link='hardened-toolchain.xml'>Hardened Toolchain</uri>.
287 </p>
288
289 <p>
290 -<e>SSP</e> (Stack Smashing Protector) is a second complementary technology we
291 -introduce at executable build time. SSP was originally introduced by IBM under
292 -the name <e>ProPolice</e>. It modifies the C compiler to insert initialization
293 -code into functions that create a buffer in memory.
294 +<b>3.</b> Finally, the PaX patches provide some miscellaneous hardening:
295 +erasing the stack frame when returning form a system call, refusing to dereference
296 +user land pointers in some contexts, detecting overflows of certain reference
297 +counters, correcting overflows of some integer counters, enforcing the size
298 +on copies between kernel and user land, and provided extra entropy.
299 </p>
300
301 -<note>
302 -In newer versions of SSP, it is possible to apply SSP to all functions,
303 -adding protection to functions whose buffer would normally be below the size
304 -limit for SSP. This is enabled via the CFLAG -fstack-protector-all.
305 -</note>
306 -
307 <p>
308 -At run time, when a buffer is created, SSP adds a secret random value, the
309 -canary, to the end of the buffer. When the function returns, SSP makes sure
310 -that the canary is still intact. If an attacker were to perform a buffer
311 -overflow, he would overwrite this value and trigger that stack smashing
312 -handler. Currently this kills the target process.
313 +More information on PaX can be found on its official homepage,
314 +<uri>http://pax.grsecurity.net</uri>.
315 </p>
316
317 +
318 +</body>
319 +</section>
320 +</chapter>
321 +
322 +<chapter>
323 +<title>Understanding PaX</title>
324 +<section>
325 +<body>
326 +
327 <p>
328 -<uri link="http://www.trl.ibm.com/projects/security/ssp/">Further reading on
329 -SSP.</uri>
330 +The first step in working with PaX is to configure and boot a PaX patched
331 +kernel. Depending on whether or not you've configured PaX for SOFTMODE or
332 +non-SOFTMODE, the kernel will automatically start enforcing memory restrictions
333 +and address space randomization on all running processes. Ideally you shouldn't
334 +have to do anything else; however, for problematic executables in non-SOFTMODE,
335 +a second step is required: you may have to relax certain PaX restrictions on a
336 +per ELF object basis. This is done by tweaking the PaX flags which are read by the
337 +kernel when the ELF is loaded into memory and execution begins. This seconds step
338 +is usually straight forward except when the ELF object that requires the relaxation
339 +is a library. In that case, the library's flags have to be back ported to the
340 +executable that links against it because when PaX enforces/relaxes its features,
341 +it does so on the basis of the executable's flags, not those of the libraries it
342 +links against. We will discuss both steps in detail below, but first we need an
343 +overview of PaX's features. We'll summarize these here, and for more details,
344 +we refer the reader to the official
345 +<uri link='http://pax.grsecurity.net/docs/index.html'>PaX documentation</uri>.
346 +</p>
347 +
348 +<p><b>SOFTMODE:</b> If this option is selected, PaX protection will not be enforced
349 +by default for those features which can be turned on or off at runtime, so this is
350 +the "permit by default" mode in contrast to the "forbid by default" which is obtained
351 +when this option is not selected. In SOFTMODE, the user must explicitly mark
352 +executables to enforce PaX protections, whereas in non-SOFTMODE, the user must explicitly
353 +mark to relax PaX protections.</p>
354 +
355 +<p><b>Enforce non-executable pages:</b></p>
356 +
357 +<dl>
358 +<dd><b>PAX_NOEXEC</b> -
359 +This option enables the protection of allocated pages of memory as
360 +non-executable if they are not part of the text segment of the running
361 +process. It is needed for PAGEEXEC, SEGMEXEC and KERNEXEC.
362 +</dd>
363 +<dd><b>PAGEEXEC</b> -
364 +The kernel will protect non-executable pages based on the paging feature
365 +of the CPU. This is sometimes called "marking pages with the <e>NX</e> bit"
366 +in other OSes. This feature can be controlled on a per ELF object basis
367 +by the PaX <c>P</c> and <c>p</c> flags.
368 +</dd>
369 +<dd><b>SEGMEXEC</b> -
370 +This is like PAGEEXEC, but based on the segmentation feature of the CPU and
371 +it is controlled by the PaX <c>S</c> and <c>s</c> flags. Note that SEGMEXEC
372 +is only available on CPUs that support memory segmentation, namely x86.
373 +</dd>
374 +<dd><b>EMUTRAMP</b> -
375 +The kernel will emulate trampolines (snippets of executable code written on
376 +the fly) for processes that need them, eg. nested functions in C and some JIT
377 +compilers. Since trampolines try to execute code written by the process itself
378 +to memory marked as non-executable by PAGEEXEC or SEGMEXEC, the PaX kernel would
379 +kill any process that tries to make use of one. EMUTRAMP allows these processes
380 +to run without having to fully disable enforcement of non-executable memory.
381 +This feature can be controlled on a per ELF object basis by PaX <c>E</c> and
382 +<c>e</c> flag.
383 +</dd>
384 +<dd><b>MPROTECT</b> -
385 +The kernel will prevent the introduction of new executable pages into the running
386 +process by various techniques: it will forbid the changing of the executable status
387 +of pages, or the creation of anonymous RWX mappings, or making RELRO data pages as
388 +writable again. It is controlled on a per ELF object basis by the PaX
389 +<c>M</c> and <c>m</c> flag.
390 +</dd>
391 +<dd><b>KERNEXEC</b> -
392 +This is the kernel land equivalent of PAGEEXEC and MPROTECT. It cannot be disabled
393 +during while the kernel is running.
394 +</dd>
395 +</dl>
396 +
397 +<p><b>Enhanced Address Space Layout Randomization (ASLR):</b></p>
398 +
399 +<dl>
400 +<dd><b>PAX_ASLR</b> -
401 +The kernel will expand the number of randomized bits for the various section of
402 +the address space. This option is needed for RANDMMAP, RANDKSTACK and RANDUSTACK.
403 +</dd>
404 +<dd><b>RANDMMAP</b> -
405 +The kernel will use a randomized base address for mmap() requests that do not
406 +specify one via the MAP_FIXED flag. It is controlled by the PaX <c>R</c> and
407 +<c>r</c> flags.
408 +</dd>
409 +<dd><b>RANDKSTACK</b> -
410 +The kernel will randomize every task's kernel stack on all system calls. It
411 +cannot be disable while the kernel is running.
412 +</dd>
413 +<dd><b>RANDUSTACK</b> -
414 +The kernel will randomize every task's userland stack. This feature can be
415 +controlled on a per ELF binary basis by the PaX <c>R</c> and <c>r</c> flags.
416 +</dd>
417 +</dl>
418 +
419 +<p><b>Miscellaneous Memory Protection:</b></p>
420 +
421 +<dl>
422 +<dd>None of the following features can be disabled while the kernel is running:</dd>
423 +<dd><b>STACKLEAK</b> -
424 +The kernel will erase its stack before it returns from a system call. This
425 +feature cannot be disabled while the kernel is running.
426 +</dd>
427 +<dd><b>UDEREF</b> -
428 +The kernel will not dereference userland pointers in contexts where the
429 +it expects only kernel pointers. This feature cannot be disabled while the
430 +kernel is running.
431 +</dd>
432 +<dd><b>REFCOUNT</b> -
433 +The kernel will detect and prevent overflowing various (but not all) kinds
434 +of object reference counters.
435 +</dd>
436 +<dd><b>USERCOPY</b> -
437 +The kernel will enforce the size of heap objects when they are copied in either
438 +direction between the kernel and userland.
439 +</dd>
440 +<dd><b>SIZE_OVERFLOW</b> -
441 +The kernel recomputes expressions of function arguments marked by a size_overflow
442 +attribute with double integer precision.
443 +</dd>
444 +<dd><b>LATENT_ENTROPY</b> -
445 +The kernel will use early boot code to generate extra entropy, which is especially
446 +useful on embedded systems.
447 +</dd>
448 +</dl>
449 +
450 +<p>
451 +As stated above, some PaX features can be enforced (in the case of SOFTMODE)
452 +or relaxed (in the case of non-SOFTMODE) on a "per ELF object" basis. These
453 +are PAGEEXEC, EMULTRAP, MPROTECT, RANDMMAP and SEGMEXEC and these are respectively
454 +controlled by the following flags: P, E, M, R, S and p, e, m, r, s.
455 +The upper case mean "enforce" in SOFTMODE and the lower case mean "relax" in
456 +non-SOFTMODE. A third possibility is that neither the enforce or relax flags are
457 +set, in which case the kernel simply uses the default for that particular protection.
458 +Eg. if neither P nor p is set on an ELF object, then the kernel will not enforce
459 +PAGEEXEC in SOFTMODE and will enforce it in non-SOFTMODE.
460 +</p>
461 +
462 +<p>
463 +Currently the PaX patches support three ways of doing PaX markings: EI_PAX, PT_PAX
464 +and XATTR_PAX. EI_PAX places the PaX flags in bytes 14 and 15 of the e_ident field
465 +of an ELF objects's header. But this is broken in recent versions of glibc and is
466 +no longer supported. (See <uri link='https://bugs.gentoo.org/365825'>bug #365825</uri>)
467 +PT_PAX places the flags in a ELF objects's program header called PAX_FLAGS.
468 +This has the advantage the that flags are in the body of the object and will
469 +always be carried with it when copied; but, it has the disadvantage that the
470 +object must have th PAX_FLAGS program header to work. Most Linux distributions
471 +don't build their executables and libraries with this program header, and adding
472 +it is problematic: there may not be enough space in the ELF object to add it
473 +or converting a GNU_STACK program header, which is not used by the PaX kernel,
474 +might later cause problems under other kernels if the object is exported. In
475 +the worst case, changing the ELF binary will break self-checking executables
476 +which detect that they have been "tampered" with.
477 +(See <uri link='https://bugs.gentoo.org/100507'>bug #100507</uri>).
478 +</p>
479 +
480 +<p>
481 +While PT_PAX is still support, the preferred approach is to use XATTR_PAX which
482 +places the PaX flags in a file system's extended attributes. This has the advantage
483 +that it does not modify the ELF object in any way, but the disadvantage that the
484 +filesystems which house these objects, and the utilities used to copy, move and archive,
485 +them, must support xattrs. In the case of Gentoo and portage, this means that
486 +tmpfs must support the user.pax.* xattr namespace in which the PaX flags are placed,
487 +not just the security.* and trusted.* namespaces. (Note: user.pax.* is the subspace
488 +of user.* which will be used for PaX related xattr information. We do not enable
489 +the entire user.* namespace in tmpfs to reduce the risk of attack vectors via that
490 +path.)
491 +</p>
492 +
493 +<p>
494 +One final caveat about the two supported methods of doing PaX markings: the PaX
495 +kernel allows you to enable both PT_PAX and XATTR_PAX, but if you do so, it will
496 +not impose the markings unless the same flags are found in both locations.
497 +For this reason, we do not recommend enabling both, even for migration which we
498 +describe below.
499 </p>
500
501 </body>
502 @@ -111,186 +396,612 @@
503 </chapter>
504
505 <chapter>
506 -<title>Building a PaX-enabled Kernel</title>
507 +<title>Building a PaX Kernel</title>
508 <section>
509 <body>
510
511 <p>
512 -Several Gentoo kernel trees are already patched with PaX.
513 +The Hardened Gentoo team maintains and supports the <c>hardened-sources</c>
514 +package, which we will cover here. Other in tree kernel sources may have
515 +PaX, and much of what we say may apply, but you will have to work through
516 +the differences yourself. The hardened-sources come with the Grsecurity
517 +patches (<uri>http://grsecurity.net/</uri>), which bundle the PaX patches.
518 +If you want only the PaX patches, these can be obtained in isolation from
519 +<uri>http://www.grsecurity.net/~paxguy1/</uri>. If you are interested in
520 +learning more about Grsecurity hardening in general, we cover that in our
521 +<uri link='grsecurity.xml'>Grsecurity Quickstart</uri>.
522 </p>
523
524 <p>
525 -For 2.4/2.6 based machines, the recommended kernels are <c>hardened-sources</c>
526 +Emerging a hardened-sources kernel places the kernel source tree at /usr/src,
527 +but it does not configure it for you. It is now up to you to make sure PaX
528 +is configured so that it enforces or relaxes what you want. Below we will
529 +concentrate on recommended configurations, but feel free to deviate. The
530 +previous section should have given you some idea as to what each of the options
531 +provide so you can make intelligent choices. We recommend tarting off with as
532 +much hardening as possible and relaxing only when there is no other workaround.
533 </p>
534
535 <p>
536 -Grab one of the recommended source trees, or apply the appropriate patch from
537 -<uri>http://pax.grsecurity.net</uri> to your own tree and configure it as you
538 -normally would for the target machine.
539 +As stated, the PaX patches are bundled with Grsecurity, so the PaX configuration
540 +options are found under that menu in <c>Security Options -&gt; Grsecurity
541 +-&gt; Customize Configuration -&gt; PaX</c>. You also have the option of selecting
542 +one of Grsecurity's preconfigured profiles at <c>Security Options -&gt; Grsecurity
543 +-&gt; Configuration Method</c>. These will give you a meaningful starting point
544 +configuration for PaX.
545 </p>
546
547 <p>
548 -In <c>Security Options -&gt; PaX</c>, apply the options as shown below.
549 +If configuring for only PT_PAX, the following should be sufficient. Note that since
550 +we are trying to show the configuration options for both x86 and amd64, we've marked
551 +where the differences lie with a <c>&gt;</c> in the left most column.
552 </p>
553
554 -<pre caption="Kernel configuration">
555 +<pre caption="Kernel configuration for PT_PAX">
556 [*] Enable various PaX features
557
558 PaX Control -&gt;
559
560 [ ] Support soft mode
561 - [*] Use legacy ELF header marking
562 + [ ] Use legacy ELF header marking
563 [*] Use ELF program header marking
564 + [ ] Use filesystem extended attributes marking
565 MAC system integration (none) ---&gt;
566
567 Non-executable page -&gt;
568
569 [*] Enforce non-executable pages
570 [*] Paging based non-executable pages
571 - [*] Segmentation based non-executable pages
572 + [*] Segmentation based non-executable pages &lt;--- Not available on amd64
573 [*] Emulate trampolines
574 [*] Restrict mprotect()
575 - [ ] Disallow ELF text relocations
576 + [ ] Use legacy/compat protection demoting (read help)
577 + [ ] Allow ELF text relocations (read help)
578 + [*] Enforce non-executable kernel pages
579 + Return Address Instrumentation Method (or) ---> &lt;--- Not available on x86
580 + (4) Minimum amount of memory reserved for module code &lt;--- Not available on amd64
581
582 Address Space Layout Randomization -&gt;
583
584 [*] Address Space Layout Randomization
585 - [*] Randomize kernel stack base
586 - [*] Randomize user stack base
587 - [*] Randomize mmap() base
588 - [*] Randomize ET_EXEC base
589 + [*] Randomize kernel stack base
590 + [*] Randomize user stack base
591 + [*] Randomize mmap() base
592 +
593 +Miscellaneous hardening features --->
594 +
595 + [*] Sanitize all freed memory
596 + [*] Sanitize kernel stack
597 + [*] Prevent invalid userland pointer dereference
598 + [*] Prevent various kernel object reference counter overflows
599 + [*] Harden heap object copies between kernel and userland
600 + [*] Prevent various integer overflows in function size parameters
601 + [*] Generate some entropy during boot
602 </pre>
603
604 <p>
605 -Build this kernel as you normally would and install it to <path>/boot</path>.
606 +Preferably, we should opt for XATTR_PAX flags. In that case, all of the above
607 +can remain in place, but we would change the PaX Control configuration:
608 </p>
609
610 -</body>
611 -</section>
612 -</chapter>
613 -
614 -<chapter>
615 -<title>Building a PIE/SSP Enabled Userland</title>
616 -<section>
617 -<body>
618 +<pre caption="Kernel configuration with XATTR_PAX flags">
619 +PaX Control -&gt;
620
621 -<p>
622 -Hardened Gentoo has added support for transparent PIE/SSP building via GCC's
623 -specfile. This means that any users upgrading an older Hardened install should
624 -remove any LDFLAGS or CFLAGS used to trigger PIE/SSP. Also, the
625 -<c>hardened-gcc</c> package is now deprecated and should be unmerged
626 -(version 5.0 is a dummy package). To get the current GCC, add
627 -<c>USE="hardened pic"</c> to <path>/etc/make.conf</path> if not using the hardened
628 -profile.
629 -</p>
630 + [ ] Support soft mode
631 + [ ] Use legacy ELF header marking
632 + [ ] Use ELF program header marking
633 + [*] Use filesystem extended attributes marking
634 + MAC system integration (none) ---&gt;
635 +</pre>
636
637 <p>
638 -To maintain a consistant toolchain, first <c>emerge binutils gcc virtual/libc</c>.
639 -Next, rebuild the entire system with <c>emerge -e world</c>. All future packages
640 -will be built with PIE/SSP.
641 +Since the PaX flags will now live on the extended attributions of your filesystems,
642 +you would need to enable xattr on those filesystems, but the PaX team has already
643 +set up a dependency. Eg. for Ext4 we have
644 </p>
645
646 -<warn>
647 -Both PIE and SSP are known to cause issues with some packages. If you come
648 -across a package that fails to compile, please file a detailed bug report including
649 -a log of the failed compile and the output of <c>emerge info</c> to
650 -<uri>http://bugs.gentoo.org/</uri>.
651 -</warn>
652 +<pre caption="Automatic selection of EXT4_FS_XATTR by XATTR_PAX_FLAGS">
653 +File systems ---&gt;
654 + &lt;*&gt; The Extended 4 (ext4) filesystem
655 + -*- Ext4 extended attributes
656 + [ ] Ext4 POSIX Access Control Lists
657 + [ ] Ext4 Security Labels
658 + [ ] EXT4 debugging support
659 +</pre>
660
661 <p>
662 -You will probably also want to merge pax-utils.
663 -Often if an ELF has executable relocations in the text segment these can cause problems for us.
664 -scanelf -BRylptq
665 +Here <c>Ext4 extended attributes</c> was automatically selected by
666 +<c>PAX_XATTR_PAX_FLAGS [=y] &amp;&amp; GRKERNSEC [=y] &amp;&amp; PAX [=y]
667 +&amp;&amp; EXT4_FS [=y]</c>. Nonetheless, in case you are using some exotic
668 +filesystem which doesn't have this this selection dependency, you may want
669 +to check and then file a bug report to have your filesystem better supported
670 +with respect to PaX.
671 </p>
672
673 -
674 </body>
675 </section>
676 </chapter>
677
678 <chapter>
679 -<title>When Things Misbehave (PaX Control)</title>
680 +<title>PaX Control</title>
681 <section>
682 <body>
683
684 <p>
685 -Some legitimate applications will attempt to generate code at run time which is
686 -executed out of memory. Naturally, PaX does not allow this and it will promptly
687 -kill the offending application.
688 +As we mentioned above, there are five PaX protections that can be enforced (in
689 +SOFTMODE) or relaxed (in non-SOFTMODE) on a per ELF object basis: PAGEEXEC,
690 +EMULTRAP, MPROTECT, RANDMMAP and SEGMEXEC. The later, SEGMEXEC, is only
691 +available on x86 CPUs which support segmentation, unlike paging which is
692 +supported on all CPUs, even x86. Since some programs break for one
693 +reason or another under full PaX enforcement, we are faced with the choice
694 +of either fixing the code to work with PaX or relaxing one or more of these
695 +protections. In practice, "fixing the code" may be very difficult
696 +and we resort to the latter. The general approach should be to try
697 +full enforcement, and if something breaks, use dmesg to obtain a report
698 +from the kernel regarding why and then relax that particular protection.
699 +Even this is not generally needed on a Gentoo system because the ebuilds
700 +should set the correct flags for you via the pax-util.eclass. If you find
701 +that you have to set your own flags, we would ask that you file a bug report.
702 +</p>
703 +
704 +<p>
705 +Generally setting the PaX flags is straightforward, but the user should keep
706 +a few things in mind:
707 +</p>
708 +
709 +<p>
710 +1) One can set either PT_PAX and/or XATTR_PAX flags on the ELF object
711 +independently of one another. Similarly, the kernel can be configured
712 +to read either, both or neither fields. It is up to you to make sure that
713 +you set the flags in the field being used by the kernel to get the desired
714 +results. For example, if you have PT_PAX="Pe---" while XATTR_PAX missing on
715 +the object, but the kernel is configured only to use XATTR_PAX, you may not
716 +get the desired result!
717 +</p>
718 +
719 +<p>
720 +2) The recommended approach is to mark both PT_PAX and XATTR_PAX fields
721 +identically on the objects whenever possible, and set the kernel to read only
722 +XATTR_PAX. The "whenever possible" is where things get complicated and the
723 +two fields may not wind up containing the same flags. If the ELF does not
724 +contain a PAX_FLAGS program header, PT_PAX marking will fail. However, the
725 +absence of this program header will not affect XATTR_PAX markings. If the ELF
726 +is busy (ie. there is a running process making use of the ELF's text), then
727 +one can read the PT_PAX flags but not set them. Again, this does not affect
728 +setting or getting XATTR_PAX flags. On the other hand, if you are using any file
729 +systems which do not support extended attributes, then XATTR_PAX marking will fail
730 +on those file systems while PT_PAX marking is uneffected, except as already stated.
731 +This can be fairly subtle because copying a file from a file system with xattrs
732 +to one without, and then back again will drop the XATTR_PAX flags. Or tarring
733 +with an older version of tar which does not preserve xattrs will again drop our
734 +flags.
735 +</p>
736 +
737 +<p>
738 +3) The PaX flags are only enforced when a process is loaded from an ELF executable.
739 +This executable in turn usually links dynamically against shared objects in memory.
740 +Using `cat /proc/&lt;pid&gt;/status | grep PaX` gives you the resulting
741 +PaX enforcement on the running process with PID=&lt;pid&gt;. But since the the
742 +executable and shared objects can have different flags, the question arises, which
743 +ones are used to determine the final running PaX enforcements? The answer is the
744 +executable for reasons of control and security. If the libraries were to set the
745 +runtime PaX enforcement, then which of the libraries would "win" if an executable
746 +linked against many? And one overly relaxed library could relax the privileges on
747 +many executables that link against it. Eg. Relaxing all PaX protection on glibc
748 +would effectively turn PaX off on one's system. Nonetheless, it may be the code
749 +in the library itself that needs the relaxation of some PaX enforcement. In that
750 +case, one has to "back port" the flags from the library to the executable that
751 +uses it.
752 +</p>
753 +
754 +<p>
755 +Below we describe the utilities provided on a Gentoo system for working PaX markings.
756 +There are several since as PaX evolved, new features were needed. Each one emphasizes
757 +a different need with respect to the above caveats.
758 +</p>
759 +
760 +<p><b>1. paxctl</b></p>
761 +<p>
762 +This it the traditional upstream package for setting PaX flags. It is limited only
763 +in that it sets PT_PAX only, not XATTR_PAX. It is provided by emerging sys-apps/paxctl.
764 +It does have one functionality that no other utility has: it can either create a PAX_FLAGS
765 +program header or convert a GNU_STACK to PAX_FLAGS. Both of these are not recommended
766 +since they can break the ELF under certain circumstances. However, in the extreme
767 +case that you cannot use XATTR_PAX (eg. you can't use file systems that support extended
768 +attributes) and you are dealing with an ELF object that wasn't build with a PAX_FLAGS
769 +program header, then these options are available to you via this utility.
770 </p>
771
772 -<note>
773 -The most notable of these applications are XFree/Xorg, mplayer and multimedia tools
774 -based on xine-lib. The easiest way around these problems are to disable PaX
775 -protections.
776 -</note>
777 -
778 <p>
779 -Luckily there is a utility to toggle protections on a per-executable basis,
780 -<e>paxctl</e>. As with any other package in Gentoo, install paxctl with the
781 -command <c>emerge paxctl</c>. Usage is show by <c>paxctl -h</c>.
782 +Here is a synopsis of its usage:
783 </p>
784
785 -<note>
786 -If you have an older version of binutils, you will need to use <e>chpax</e>,
787 -which edits the old-style PaX markings. Usage of chpax is largely the same as
788 -paxctl. This also requires legacy marking support built into your kernel.
789 -New versions of paxctl make chpax obsolete.
790 -</note>
791 -
792 <pre caption="paxctl -h">
793 +PaX control v0.7
794 +Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team &lt;pageexec@××××××××.hu&gt;
795 +
796 usage: paxctl &lt;options&gt; &lt;files&gt;
797
798 options:
799 - -p: disable PAGEEXEC -P: enable PAGEEXEC
800 - -e: disable EMUTRMAP -E: enable EMUTRMAP
801 - -m: disable MPROTECT -M: enable MPROTECT
802 - -r: disable RANDMMAP -R: enable RANDMMAP
803 - -x: disable RANDEXEC -X: enable RANDEXEC
804 - -s: disable SEGMEXEC -S: enable SEGMEXEC
805 + -p: disable PAGEEXEC -P: enable PAGEEXEC
806 + -e: disable EMUTRAMP -E: enable EMUTRAMP
807 + -m: disable MPROTECT -M: enable MPROTECT
808 + -r: disable RANDMMAP -R: enable RANDMMAP
809 + -x: disable RANDEXEC -X: enable RANDEXEC
810 + -s: disable SEGMEXEC -S: enable SEGMEXEC
811 +
812 + -v: view flags -z: restore default flags
813 + -q: suppress error messages -Q: report flags in short format
814 + -c: convert PT_GNU_STACK into PT_PAX_FLAGS (see manpage!)
815 + -C: create PT_PAX_FLAGS (see manpage!)
816 +</pre>
817
818 - -v: view flags -z: restore default flags
819 - -q: suppress error messages -Q: report flags in short format flags
820 +<p>
821 +Note that paxctl also reports on an older PaX protection called RANDEXEC.
822 +This is now deprecated --- the randomization of the base address of a processes
823 +now simply part of ASLR on all executables build ET_DYN rather than EX_EXEC.
824 +Here is paxctl in action:
825 +</p>
826 +
827 +<pre caption="paxctl in action">
828 +# <i>paxctl -v /usr/bin/python3.2</i>
829 +PaX control v0.7
830 +Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team &lt;pageexec@××××××××.hu&gt;
831 +
832 +- PaX flags: -----m-x-e-- [/usr/bin/python3.2]
833 + MPROTECT is disabled
834 + RANDEXEC is disabled
835 + EMUTRAMP is disabled
836 +
837 +# paxctl -P /usr/bin/python3.2
838 +# paxctl -v /usr/bin/python3.2
839 +PaX control v0.7
840 +Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team &lt;pageexec@××××××××.hu&gt;
841 +
842 +- PaX flags: P----m-x-e-- [/usr/bin/python3.2]
843 + PAGEEXEC is enabled &lt;--- Note: this added to the earlier flags, it didn't overwrite them.
844 + MPROTECT is disabled
845 + RANDEXEC is disabled
846 + EMUTRAMP is disabled
847 </pre>
848
849 +<p><b>2. getfattr setfattr</b></p>
850 <p>
851 -The first option we will note is <c>-v</c>, which can display flags set on a
852 -particular binary.
853 +These are not PaX specific utilities but are general utilities to set a file's
854 +extended attributes. On Gentoo, they are provided by emerging sys-apps/attr.
855 +Since XATTR_PAX uses the user.* namespace, specifically it uses "user.pax.flags",
856 +you can use set/getfattr to work with this field. However, keep in mind that
857 +setfattr and getfattr know nothing about PaX, so they will not perform any sanity
858 +checking of what you are putting into that field. Only if you set user.pax.flags
859 +to some meaningful combination of the chars PpEeMmRr will the kernel respect your
860 +choice, else it falls back on the default. The following listing gives examples.
861 </p>
862
863 -<pre caption="paxctl -v">
864 -shell user # paxctl -v /usr/bin/Xorg
865 -PaX control v0.2
866 -Copyright 2004 PaX Team &lt;pageexec@××××××××.hu&gt;
867 +<p>
868 +The following is an example of their usage for XATTR_PAX:
869 +</p>
870 +
871 +<pre caption="setfattr and getfattr in action">
872 +# <i>getfattr -n user.pax.flags /usr/bin/python3.2</i>
873 +getfattr: Removing leading '/' from absolute path names
874 +# file: usr/bin/python3.2
875 +user.pax.flags="em"
876 +
877 +# <i>setfattr -n user.pax.flags -v P /usr/bin/python3.2</i>
878 +# <i>getfattr -n user.pax.flags /usr/bin/python3.2</i>
879 +getfattr: Removing leading '/' from absolute path names
880 +# file: usr/bin/python3.2
881 +user.pax.flags="P" &lt;--- Note: this overwrote the earlier flags, it didn't add to them.
882 +
883 +# <i>setfattr -n user.pax.flags -v "Hi Mom, wish you were here." /usr/bin/python3.2</i>
884 +# <i>getfattr -n user.pax.flags /usr/bin/python3.2</i>
885 +getfattr: Removing leading '/' from absolute path names
886 +# file: usr/bin/python3.2
887 +user.pax.flags="Hi Mom, wish you were here." &lt;--- Mom appreciates it, but PaX does not. There is no sanity checking.
888 +</pre>
889 +
890 +
891 +<p><b>3. paxctl-ng</b></p>
892 +<p>
893 +paxctl-ng is the new swiss army knife of working with PT_PAX an XATTR_PAX
894 +markings. It can be built with support for just one or the other or both
895 +types of markings. When built with support for both, it can copy PT_PAX
896 +to XATTRP_PAX fields or vice versa, to make sure you have consistency.
897 +In sum, it can do everything paxctl and set/getfattr can do, except it
898 +will not try to create or convert a PAX_FLAGS program header. This is
899 +discouraged and should only be use in the corner case mentioned above.
900 +Here is a synopsis of its usage:
901 +</p>
902 +
903 +<pre caption="paxctl-ng -h">
904 +Package Name : elfix 0.7.1
905 +Bug Reports : http://bugs.gentoo.org/
906 +Program Name : paxctl-ng
907 +Description : Get or set pax flags on an ELF object
908 +
909 +Usage : paxctl-ng -PpEeMmRrSsv ELF | -Zv ELF | -zv ELF
910 + : paxctl-ng -Cv ELF | -cv ELF | -dv ELF
911 + : paxctl-ng -Fv ELF | -fv ELF
912 + : paxctl-ng -Lv ELF | -lv ELF
913 + : paxctl-ng -v ELF | -h
914 +
915 +Options : -P enable PAGEEXEC -p disable PAGEEXEC
916 + : -E enable EMUTRAMP -e disable EMUTRAMP
917 + : -M enable MPROTECT -m disable MPROTECT
918 + : -R enable RANDMMAP -r disable RANDMMAP
919 + : -S enable SEGMEXEC -s disable SEGMEXEC
920 + : -Z all secure settings -z all default settings
921 + :
922 + : -C create XATTR_PAX with most secure setting
923 + : -c create XATTR_PAX all default settings
924 + : -F copy PT_PAX to XATTR_PAX
925 + : -f copy XATTR_PAX to PT_PAX
926 + : -L set only PT_PAX flags
927 + : -l set only XATTR_PAX flags
928 + :
929 + : -v view the flags, along with any accompanying operation
930 + : -h print out this help
931
932 -- PaX flags: -p-sM--x-eR- [/usr/bin/Xorg]
933 - PAGEEXEC is disabled
934 - SEGMEXEC is disabled
935 - MPROTECT is enabled
936 - RANDEXEC is disabled
937 - EMUTRAMP is disabled
938 - RANDMMAP is enabled
939 +Note : If both enabling and disabling flags are set, the default - is used
940 </pre>
941
942 <p>
943 -This shows an XFree binary with all protections disabled.
944 +The following is an example of paxctl-ng in action:
945 </p>
946
947 +<pre caption="paxctl-ng in action">
948 +# <i>paxctl-ng -v /usr/bin/python3.2</i> &lt;--- View both PT_PAX and XATTR_PAX fields (-v)
949 +/usr/bin/python3.2:
950 + PT_PAX : Pem--
951 + XATTR_PAX: Pem--
952 +
953 +# <i>paxctl-ng -lPpv /usr/bin/python3.2</i> &lt;--- Set default '-' for PAGEEXEC (-Pp)
954 +/usr/bin/python3.2: &lt;--- For XATTR_FLAGS only (-l)
955 + PT_PAX : Pem-- &lt;--- And report the result (-v)
956 + XATTR_PAX: -em--
957 +
958 +# <i>paxctl-ng -dv /usr/bin/python3.2</i> &lt;--- Delete the XATTR_PAX field altogether (-d)
959 +/usr/bin/python3.2: &lt;--- And report the result (-v)
960 + PT_PAX : Pem--
961 + XATTR_PAX: not found
962 +
963 +# <i>paxctl-ng -lemv /usr/bin/python3.2</i> &lt;--- Set "em" flags (-em)
964 +/usr/bin/python3.2: &lt;--- For XATTR_FLAGS only (-l)
965 + PT_PAX : Pem-- &lt;--- And report the result (-v)
966 + XATTR_PAX: -em--
967 +
968 +# <i>paxctl-ng -fv /usr/bin/python3.2</i> &lt;--- Copy the XATTR_PAX to PT_PAX flags, overwriting the latter (-f)
969 +/usr/bin/python3.2: &lt;--- And report the result (-v)
970 + PT_PAX : -em--
971 + XATTR_PAX: -em--
972 +
973 +# <i>paxctl-ng -d /usr/bin/python3.2</i> &lt;--- Silently delete the XATTR_PAX field (-d but no -v)
974 +# <i>paxctl-ng -v /usr/bin/python3.2</i> &lt;--- View both PT_PAX and XATTR_PAX fields (-v)
975 +/usr/bin/python3.2:
976 + PT_PAX : -em--
977 + XATTR_PAX: not found
978 +</pre>
979 +
980 +<p><b>4.</b>Python module, <b>pax.so</b>, and a simple Python frontend, <b>pypaxctl</b>.</p>
981 <p>
982 -To set flags on a binary, the <c>-z</c> flag is useful as it restores the
983 -default flags.
984 -</p>
985 +We also provide bindings to python via a module, pax.so, which is installed
986 +by emerging dev-python/pypax. This package is a dependency of sys-apps/elfix
987 +since the both revdep-pax and migrate-pax import it. It can be compiled with
988 +either PT_PAX and/or XATTR_PAX support, like paxctl-ng, but it is not as featureful
989 +since its scope is limited to just the needs of revdep-pax and migrate-pax. This
990 +may change in the future if there is a need to better integrate PaX marking with
991 +portage which is written in python.
992 +</p>
993 +
994 +<p>
995 +Currently pax.so publicly exports the following:
996 +</p>
997 +<dl>
998 + <dt><b>pax.setstrflags(str_flags):</b></dt> <dd>This function will set both PT_PAX
999 + and XATTR_PAX flags to the same value, whenever possible. The flags are specified
1000 + as a string of the following chars: PpEeMmRrSs. If both the enable and disable
1001 + flags are given for a particular protection, then the default '-' is used.</dd>
1002 + <dt><b>pax.setbinflags(bin_flags):</b></dt> <dd>This function is the same as
1003 + pax.setstrflags but it takes the flags as a bitwise OR of the binary representation
1004 + of the flags. The PT_PAX field is stored as this way, while XATTR_PAX is stored as
1005 + a string of chars PpEeMmRrSs.</dd>
1006 + <dt><b>pax.getflags(elf):</b></dt> <dd>This function returns the PaX flags as a
1007 + tuple of both forms (str_flags, bin_flags), ie., both as a string and its equivalent
1008 + binary representation are returned. If both PT_PAX and XATTR_PAX are set, then
1009 + the XATTR_PAX flags will override the PT_PAX flags.</dd>
1010 + <dt><b>pax.deletextpax(elf):</b></dt> <dd>This function will delete the XATTR_PAX
1011 + field completely. It does not touch the PT_PAX field, which cannot be deleted (easily!).
1012 + </dd>
1013 + <dt><b>pax.PaxError:</b></dt> <dd>This exception is thrown whenever getting or setting
1014 + the flags fails, or when deleting the XATTR_PAX field fails.</dd>
1015 +</dl>
1016 +
1017 +<p>
1018 +pypaxctl is a simple front end to pax.so which just gets and sets the PaX flags using
1019 +the same logic. When getting the flags, if both PT_PAX and XATTR_PAX are present,
1020 +the latter will override the former. When setting, it will set both fields whenever
1021 +possible. Here it is in action:
1022 +</p>
1023 +
1024 +<pre caption="pypaxctl in action with both PT_PAX and XATTR_PAX">
1025 +# <i>pypaxctl -g /usr/bin/python3.2</i> &lt;--- Retrieve either PT_PAX or XATTR_PAX. The latter has priority if it exists.
1026 +-em-- &lt;--- The canonical order is PEMRS
1027 +# <i>paxctl-ng -v /usr/bin/python3.2</i> &lt;--- It turns out that XATTR_PAX didn't exist, so we got PT_PAX.
1028 +/usr/bin/python3.2:
1029 + PT_PAX: -em--
1030 + XT_PAX: not found
1031 +
1032 +# <i>paxctl-ng -lPMEv /usr/bin/python3.2</i> &lt;--- Set some XATTR_PAX flags.
1033 +/usr/bin/python3.2:
1034 + PT_PAX: -em--
1035 + XT_PAX: PEM--
1036 +
1037 +# <i>pypaxctl -g /usr/bin/python3.2</i> &lt;--- Now its reporting XATTR_PAX flags!
1038 +PEM--
1039 +# <i>pypaxctl -s me /usr/bin/python3.2</i> &lt;--- Set "me" on both PT_PAX and XATTR_PAX
1040 +# <i>paxctl-ng -v /usr/bin/python3.2</i>
1041 +/usr/bin/python3.2:
1042 + PT_PAX: -em-- &lt;--- Like paxctl and paxctl-ng, we don't overwrite flags, just add.
1043 + XT_PAX: Pem--
1044 +
1045 +# <i>pypaxctl -s Pp /usr/bin/python3.2</i> &lt;--- But what if we want PAGEEXEC off? Then set Pp for the default '-'.
1046 +# <i>paxctl-ng -v /usr/bin/python3.2</i>
1047 +/usr/bin/python3.2:
1048 + PT_PAX: -em--
1049 + XT_PAX: -em--
1050 +</pre>
1051
1052 <p>
1053 -To disable protections on Xorg, run
1054 -<c>paxctl -zpeMRxs /usr/bin/Xorg</c>.
1055 -</p>
1056 +If the logic of XATTR_PAX taking precedence over PT_PAX is not what you want,
1057 +it can be compile with just PT_PAX xor XATTR_PAX support. In this case, the
1058 +other field is not ever touched, as demonstrated below:
1059 +</p>
1060 +
1061 +<pre caption="pypaxctl in action with just PT_PAX">
1062 +# <i>paxctl-ng -v /usr/bin/python3.2</i>
1063 +/usr/bin/python3.2:
1064 + PT_PAX: -em--
1065 + XT_PAX: PEM--
1066 +
1067 +# <i>pypaxctl -g /usr/bin/python3.2</i>
1068 +-em--
1069 +# <i>pypaxctl -s p /usr/bin/python3.2</i>
1070 +# <i>paxctl-ng -v /usr/bin/python3.2</i>
1071 +/usr/bin/python3.2:
1072 + PT_PAX: pem--
1073 + XT_PAX: PEM--
1074 +
1075 +# <i>pypaxctl -s PpEem /usr/bin/python3.2</i>
1076 +# <i>paxctl-ng -v /usr/bin/python3.2</i>
1077 +/usr/bin/python3.2:
1078 + PT_PAX: --m--
1079 + XT_PAX: PEM--
1080 +</pre>
1081 +
1082
1083 +<p><b>5. revdep-pax</b></p>
1084 <p>
1085 -Play around with disabling/enabling protections to see what is the least needed
1086 -to run. Often we find that we need the -m -sp combos.
1087 +This utility is used to map out the linkings between all the ELF objects on your
1088 +system and their shared objects in both directions. It can then search for PaX
1089 +flag markings that are mismatched between the shared objects than the executables;
1090 +and optionally, allows the user to migrate the markings forwards or backwards on a per
1091 +ELF object basis. Here's a synopsis of its usage:
1092 +</p>
1093 +
1094 +<pre caption="revdep-pax -h">
1095 +Package Name : elfix
1096 +Bug Reports : http://bugs.gentoo.org/
1097 +Program Name : revdep-pax
1098 +Description : Get or set pax flags on an ELF object
1099 +
1100 +Usage : revdep-pax -f [-v] print out all forward mappings for all system binaries
1101 + : revdep-pax -r [-ve] print out all reverse mappings for all system sonames
1102 + : revdep-pax -b OBJECT [-myv] print all forward mappings only for OBJECT
1103 + : revdep-pax -s SONAME [-myve] print all reverse mappings only for SONAME
1104 + : revdep-pax -l LIBRARY [-myve] print all reverse mappings only for LIBRARY file
1105 + : revdep-pax [-h] print out this help
1106 + : -v verbose, otherwise just print mismatching objects
1107 + : -e only print out executables in shell $PATH
1108 + : -m don't just report, but mark the mismatching objects
1109 + : -y assume "yes" to all prompts for marking (USE CAREFULLY!)
1110 +</pre>
1111 +
1112 +<p>
1113 +Here's revdep-pax in action. Since the out is long, we've replaced some
1114 +of it with ellipses:
1115 </p>
1116
1117 +<pre caption="revdep-pax in action">
1118 +# <i>revdep-pax -f</i> &lt; --- Report all mismatching forward linkings
1119 + .....
1120 +/usr/bin/python3.2 ( --m-- )
1121 +
1122 + libpython3.2.so.1.0 /usr/lib64/libpython3.2.so.1.0 ( -e--- )
1123 + libpthread.so.0 /lib64/libpthread-2.16.so ( -e--- )
1124 + libc.so.6 /lib64/libc-2.16.so ( -e--- )
1125 + libdl.so.2 /lib64/libdl-2.16.so ( -e--- )
1126 + libutil.so.1 /lib64/libutil-2.16.so ( -e--- )
1127 + libm.so.6 /lib64/libm-2.16.so ( -e--- )
1128 + .....
1129 +
1130 +# <i>revdep-pax -m -b /usr/bin/python3.2</i> &lt; --- Forward port PaX flags for python3.2 only
1131 +/usr/bin/python3.2 (--m--)
1132 +
1133 + libpython3.2.so.1.0 /usr/lib64/libpython3.2.so.1.0 ( -e--- )
1134 + libpthread.so.0 /lib64/libpthread-2.16.so ( -e--- )
1135 + libc.so.6 /lib64/libc-2.16.so ( -e--- )
1136 + libdl.so.2 /lib64/libdl-2.16.so ( -e--- )
1137 + libutil.so.1 /lib64/libutil-2.16.so ( -e--- )
1138 + libm.so.6 /lib64/libm-2.16.so ( -e--- )
1139 +
1140 + Will mark libraries with --m--
1141 +
1142 + Set flags for /usr/lib64/libpython3.2.so.1.0 (y/n): <i>n</i> &lt; --- You will be prompted unless you give -y
1143 + Set flags for /lib64/libpthread-2.16.so (y/n): <i>n</i> &lt; --- We'll say 'n' to each for this demo
1144 + Set flags for /lib64/libc-2.16.so (y/n): <i>n</i>
1145 + Set flags for /lib64/libdl-2.16.so (y/n): <i>n</i>
1146 + Set flags for /lib64/libutil-2.16.so (y/n): <i>n</i>
1147 + Set flags for /lib64/libm-2.16.so (y/n): <i>n</i>
1148 +
1149 +# <i>revdep-pax -r</i> &lt; --- Report all mismatching reverse linkings
1150 + .....
1151 +libpython3.2.so.1.0 /usr/lib64/libpython3.2.so.1.0 ( -e--- ) &lt; --- The format is soname /path/to/its/elf_object (flags)
1152 +
1153 + /usr/bin/python3.2 ( --m-- ) &lt; --- There is a mismatch here as expected
1154 + ..... from the previous step
1155 +
1156 +# <i>revdep-pax -m -s libpython3.2.so.1.0</i> &lt; --- Let's migrate from the library's flags to the
1157 +libpython3.2.so.1.0 /usr/lib64/libpython3.2.so.1.0 (-e---) executable using the soname (-s). We could also have used
1158 + /usr/lib64/libpython3.2.so.1.0 with the -l flag.
1159 + /usr/bin/python3.2 ( --m-- )
1160 +
1161 + Will mark binaries with -e---
1162 +
1163 + Set flags for /usr/bin/python3.2 (y/n): <i>y</i> &lt; --- Confirm 'y' we want to do this
1164 +
1165 + /usr/bin/python3.2 ( -em-- )
1166 +
1167 +# <i>paxctl-ng -v /usr/bin/python3.2</i> &lt; --- Double check
1168 +/usr/bin/python3.2:
1169 + PT_PAX: -em--
1170 + XT_PAX: -em--
1171 +</pre>
1172 +
1173 +<p>
1174 +One final note about revdep-pax's internals. It currently uses a "mixed" approach to
1175 +finding all the ELF objects on a system and their shared objects. To get the list of
1176 +objects it uses Gentoo's portage database at /var/db/pkg, but to get the linkings, it uses
1177 +/usr/bin/ldd which is a bash script wrapper to `LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2`
1178 +on glibc, and its own program on uclibc. We are working towards two separate approaches:
1179 +1) The future revdep-pax will use /var/db/pkg for both the list of ELF objects and
1180 +their linkings to shared objects. This will be a lot faster than the current utility.
1181 +2) There will be a revdep-pax-ng which will not assume a Gentoo system, but rather
1182 +construct a list ELF objects collected from a combined $PATH for the executables and
1183 +/etc/ld.so.conf for the shared objects. This utility will work on non-Gentoo systems
1184 +and be more exhaustive than revdep-pax, but much slower. Here -ng stands for Not Gentoo.
1185 +</p>
1186 +
1187 +<p><b>6. migrate-pax</b></p>
1188 +<p>
1189 +At this point you're probably fed up with dealing with both PT_PAX and XATTR_PAX
1190 +fields and their relationship to the kernel's configuration, and you just want to
1191 +drop the older PT_PAX and get on with life! migrate-pax does only that ... it
1192 +will go through all ELF objects on your system and migrate the PT_PAX field to
1193 +XATTR_PAX. That's it.
1194 +</p>
1195 +<pre caption="migrate-pax -h">
1196 +Package Name : elfix
1197 +Bug Reports : http://bugs.gentoo.org/
1198 +Program Name : migrate
1199 +Description : Migrate PT_PAX to XATTR_PAX Flags on all system ELF objects
1200 +
1201 +Usage : migrate -v print out all system ELF objects
1202 + : migrate -m [-v] migrate flags on all system ELF objects
1203 + : migrate -d [-v] delete XATTR_PAX on all system ELF objects
1204 + : migrate [-h] print out this help
1205 + : -v be verbose when migrating
1206 +</pre>
1207 +
1208 </body>
1209 </section>
1210 </chapter>
Report Message
Find on MARC Find on Google Groups