/[gentoo]/xml/htdocs/proj/en/hardened/pax-quickstart.xml
Gentoo

Contents of /xml/htdocs/proj/en/hardened/pax-quickstart.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.15 - (hide annotations) (download) (as text)
Fri Jan 4 20:59:04 2013 UTC (5 years, 11 months ago) by blueness
Branch: MAIN
Changes since 1.14: +22 -22 lines
File MIME type: application/xml
Fix some typos, bug #450268

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

  ViewVC Help
Powered by ViewVC 1.1.20