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

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

Parent Directory | Revision Log | View Patch Patch

Revision 1.13		Revision 1.15
1	<?xml version='1.0' encoding="UTF-8"?>	1	<?xml version='1.0' encoding="UTF-8"?>
2	<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v 1.13 2012/10/28 15:21:07 swift Exp $ -->	2	<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/pax-quickstart.xml,v 1.15 2013/01/04 20:59:04 blueness Exp $ -->
3	<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">	3	<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
4		4
5	<guide>	5	<guide lang="en">
6	<title>Hardened Gentoo PaX Quickstart</title>	6	<title>Hardened Gentoo PaX Quickstart</title>
7		7
8	<author title="Author">	8	<author title="Author">
		9	<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">
9	<mail link="tseng@gentoo.org">Brandon Hale</mail>	15	<mail link="tseng@gentoo.org">Brandon Hale</mail>
10	</author>	16	</author>
11	<author title="Editor">	17	<author title="Editor">
12	<mail link="blackace@gentoo.org">Blackace</mail>	18	<mail link="blackace@gentoo.org">blackace</mail>
13	</author>	19	</author>
14	<author title="Editor">	20	<author title="Editor">
15	<mail link="solar@gentoo.org">solar</mail>	21	<mail link="solar@gentoo.org">solar</mail>
16	</author>	22	</author>
17		23
18	<abstract>	24	<abstract>
19	A quickstart covering PaX and Hardened Gentoo.	25	Understanding and working with PaX in Hardened Gentoo.
20	</abstract>	26	</abstract>
21		27
22	<!-- The content of this document is licensed under the CC-BY-SA license -->	28	<!-- The content of this document is licensed under the CC-BY-SA license -->
23	<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->	29	<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
24	<license/>	30	<license/>
25		31
26	<version>1.4</version>	32	<version>2.0</version>
27	<date>2007-09-11</date>	33	<date>2012-12-19</date>
28		34
29	<chapter>	35	<chapter>
30	<title>What is Hardened Gentoo?</title>	36	<title>What is Hardened Gentoo?</title>
31	<section>	37	<section>
32	<body>	38	<body>
33		39
34	<p>	40	<p>
35	Hardened Gentoo is a project interested in the hardening of a Gentoo system.	41	The Hardened Gentoo project focuses on adding features to a Gentoo system
36	Several different solutions are supported by us and there is a fair bit of	42	that help resist security compromises. The approach is not always systematic,
37	flexibility to create your own setup. At the heart of a common Hardened Gentoo	43	and many features that enhances security are added. Some of these compliment
38	setup is <e>PaX</e>.	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.
39	</p>	48	</p>
40		49
41	</body>	50	</body>
42	</section>	51	</section>
43	</chapter>	52	</chapter>
44		53
45	<chapter>	54	<chapter>
46	<title>What is PaX?</title>	55	<title>What is PaX?</title>
47	<section>	56	<section>
48	<body>	57	<body>
49		58
50	<p>	59	<p>
51	PaX is a patch to the Linux kernel that provides hardening in two ways.	60	PaX is a patch to the Linux kernel that provides hardening in three ways.
52	</p>
53
54	<p>	61	</p>
55	The first, <e>ASLR</e> (Address Space Layout Randomization) provides a means to	62
56	randomize the addressing scheme of all data loaded into memory. When an
57	application is built as a <e>PIE</e> (Position Independent Executable), PaX is
58	able to also randomize the addresses of the application base in addition.
59	</p>	63	<p>
60		64	<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.
61	<p>	72	</p>
62	The second protection provided by PaX is non-executable memory. This prevents a	73
63	common form of attack where executable code is inserted into memory by an
64	attacker. More information on PaX can be found throughout this guide, but the
65	homepage can be found at <uri>http://pax.grsecurity.net</uri>.
66	</p>	74	<p>
		75	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 <stdio.h>
		86	#include <stdlib.h>
		87	#include <sys/mman.h>
		88	#include <errno.h>
		89	#include <string.h>
		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
		110	<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 <stdio.h>
		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	printf("Enter an integer: ");
		138	scanf("%d", &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
		157	<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 <stdio.h>
		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
		194	<p>
		195	For more information on PIE, see our documentation on the
		196	<uri link='hardened-toolchain.xml'>Hardened Toolchain</uri>.
		197	</p>
		198
		199	<p>
		200	<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	</p>
		206
		207	<p>
		208	More information on PaX can be found on its official homepage,
		209	<uri>http://pax.grsecurity.net</uri>.
		210	</p>
		211
67		212
68	</body>	213	</body>
69	</section>	214	</section>
70	</chapter>	215	</chapter>
71		216
72	<chapter>	217	<chapter>
73	<title>An Introduction to PIE and SSP</title>	218	<title>Understanding PaX</title>
74	<section>	219	<section>
75	<body>	220	<body>
76		221
77	<p>	222	<p>
78	As mentioned above, PaX is complemented by PIE. This method of building	223	The first step in working with PaX is to configure and boot a PaX patched
79	executables stores information needed to relocate parts of the executable in	224	kernel. Depending on whether or not you've configured PaX for SOFTMODE or
80	memory, hence the name <e>Position Independent</e>.	225	non-SOFTMODE, the kernel will automatically start enforcing memory restrictions
81	</p>	226	and address space randomization on all running processes. Ideally you shouldn't
82		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	kernel when the ELF is loaded into memory and execution begins. This second step
		231	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>.
83	<p>	239	</p>
84	<e>SSP</e> (Stack Smashing Protector) is a second complementary technology we	240
85	introduce at executable build time. SSP was originally introduced by IBM under	241	<p><b>SOFTMODE:</b> If this option is selected, PaX protection will not be enforced
86	the name <e>ProPolice</e>. It modifies the C compiler to insert initialization	242	by default for those features which can be turned on or off at runtime, so this is
87	code into functions that create a buffer in memory.	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	The kernel will not dereference userland pointers in contexts where
		322	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
88	</p>	343	<p>
89		344	As stated above, some PaX features can be enforced (in the case of SOFTMODE)
90	<note>	345	or relaxed (in the case of non-SOFTMODE) on a "per ELF object" basis. These
91	In newer versions of SSP, it is possible to apply SSP to all functions,	346	are PAGEEXEC, EMULTRAP, MPROTECT, RANDMMAP and SEGMEXEC and these are respectively
92	adding protection to functions whose buffer would normally be below the size	347	controlled by the following flags: P, E, M, R, S and p, e, m, r, s.
93	limit for SSP. This is enabled via the CFLAG -fstack-protector-all.	348	The upper case mean "enforce" in SOFTMODE and the lower case mean "relax" in
94	</note>	349	non-SOFTMODE. A third possibility is that neither the enforce or relax flags are
95		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.
96	<p>	353	</p>
97	At run time, when a buffer is created, SSP adds a secret random value, the	354
98	canary, to the end of the buffer. When the function returns, SSP makes sure
99	that the canary is still intact. If an attacker were to perform a buffer
100	overflow, he would overwrite this value and trigger that stack smashing
101	handler. Currently this kills the target process.
102	</p>	355	<p>
103		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>).
104	<p>	371	</p>
105	<uri link="http://www.trl.ibm.com/projects/security/ssp/">Further reading on	372
106	SSP.</uri>	373	<p>
		374	While PT_PAX is still supported, the preferred approach is to use XATTR_PAX which
		375	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.
107	</p>	392	</p>
108		393
109	</body>	394	</body>
110	</section>	395	</section>
111	</chapter>	396	</chapter>
112		397
113	<chapter>	398	<chapter>
114	<title>Building a PaX-enabled Kernel</title>	399	<title>Building a PaX Kernel</title>
115	<section>	400	<section>
116	<body>	401	<body>
117		402
118	<p>	403	<p>
119	Several Gentoo kernel trees are already patched with PaX.	404	The Hardened Gentoo team maintains and supports the <c>hardened-sources</c>
120	</p>	405	package, which we will cover here. Other in tree kernel sources may have
121		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>.
122	<p>	413	</p>
123	For 2.4/2.6 based machines, the recommended kernels are <c>hardened-sources</c>	414
124	</p>	415	<p>
125		416	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.
126	<p>	423	</p>
127	Grab one of the recommended source trees, or apply the appropriate patch from	424
128	<uri>http://pax.grsecurity.net</uri> to your own tree and configure it as you
129	normally would for the target machine.
130	</p>	425	<p>
131		426	As stated, the PaX patches are bundled with Grsecurity, so the PaX configuration
		427	options are found under that menu in <c>Security Options -> Grsecurity
		428	-> Customize Configuration -> PaX</c>. You also have the option of selecting
		429	one of Grsecurity's preconfigured profiles at <c>Security Options -> Grsecurity
		430	-> Configuration Method</c>. These will give you a meaningful starting point
		431	configuration for PaX.
132	<p>	432	</p>
133	In <c>Security Options -> PaX</c>, apply the options as shown below.	433
134	</p>	434	<p>
		435	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>></c> in the left most column.
		438	</p>
135		439
136	<pre caption="Kernel configuration">	440	<pre caption="Kernel configuration for PT_PAX">
137	[*] Enable various PaX features	441	[*] Enable various PaX features
138		442
139	PaX Control ->	443	PaX Control ->
140		444
141	[ ] Support soft mode	445	[ ] Support soft mode
142	[*] Use legacy ELF header marking	446	[ ] Use legacy ELF header marking
143	[*] Use ELF program header marking	447	[*] Use ELF program header marking
		448	[ ] Use filesystem extended attributes marking
144	MAC system integration (none) --->	449	MAC system integration (none) --->
145		450
146	Non-executable page ->	451	Non-executable page ->
147		452
148	[*] Enforce non-executable pages	453	[*] Enforce non-executable pages
149	[*] Paging based non-executable pages	454	[*] Paging based non-executable pages
150	[*] Segmentation based non-executable pages	455	[*] Segmentation based non-executable pages <--- Not available on amd64.
151	[*] Emulate trampolines	456	[*] Emulate trampolines
152	[*] Restrict mprotect()	457	[*] Restrict mprotect()
		458	[ ] Use legacy/compat protection demoting (read help)
153	[ ] Disallow ELF text relocations	459	[ ] Allow ELF text relocations (read help)
		460	[*] Enforce non-executable kernel pages
		461	Return Address Instrumentation Method (or) ---> <--- Not available on x86.
		462	(4) Minimum amount of memory reserved for module code <--- Not available on amd64.
154		463
155	Address Space Layout Randomization ->	464	Address Space Layout Randomization ->
156		465
157	[*] Address Space Layout Randomization	466	[*] Address Space Layout Randomization
158	[*] Randomize kernel stack base	467	[*] Randomize kernel stack base
159	[*] Randomize user stack base	468	[*] Randomize user stack base
160	[*] Randomize mmap() base	469	[*] Randomize mmap() base
161	[*] Randomize ET_EXEC base
162	</pre>
163		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	</pre>
		481
		482	<p>
		483	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:
164	<p>	485	</p>
165	Build this kernel as you normally would and install it to <path>/boot</path>.	486
		487	<pre caption="Kernel configuration with XATTR_PAX flags">
		488	PaX Control ->
		489
		490	[ ] 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) --->
		495	</pre>
		496
		497	<p>
		498	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	</p>
		502
		503	<pre caption="Automatic selection of EXT4_FS_XATTR by XATTR_PAX_FLAGS">
		504	File systems --->
		505	<*> 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
		512	<p>
		513	Here <c>Ext4 extended attributes</c> was automatically selected by
		514	<c>PAX_XATTR_PAX_FLAGS [=y] && GRKERNSEC [=y] && PAX [=y]
		515	&& 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.
166	</p>	519	</p>
167		520
168	</body>	521	</body>
169	</section>	522	</section>
170	</chapter>	523	</chapter>
171		524
172	<chapter>	525	<chapter>
173	<title>Building a PIE/SSP Enabled Userland</title>	526	<title>PaX Control</title>
174	<section>	527	<section>
175	<body>	528	<body>
176		529
177	<p>	530	<p>
178	Hardened Gentoo has added support for transparent PIE/SSP building via GCC's	531	As we mentioned above, there are five PaX protections that can be enforced (in
179	specfile. This means that any users upgrading an older Hardened install should	532	SOFTMODE) or relaxed (in non-SOFTMODE) on a per ELF object basis: PAGEEXEC,
180	remove any LDFLAGS or CFLAGS used to trigger PIE/SSP. Also, the	533	EMULTRAP, MPROTECT, RANDMMAP and SEGMEXEC. The later, SEGMEXEC, is only
181	<c>hardened-gcc</c> package is now deprecated and should be unmerged	534	available on x86 CPUs which support segmentation, unlike paging which is
182	(version 5.0 is a dummy package). To get the current GCC, add	535	supported on all CPUs, even x86. Since some programs break for one
183	<c>USE="hardened pic"</c> to <path>/etc/make.conf</path> if not using the hardened	536	reason or another under full PaX enforcement, we are faced with the choice
184	profile.	537	of either fixing the code to work with PaX or relaxing one or more of these
185	</p>	538	protections. In practice, "fixing the code" may be very difficult
186		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.
187	<p>	545	</p>
188	To maintain a consistant toolchain, first <c>emerge binutils gcc virtual/libc</c>.	546
189	Next, rebuild the entire system with <c>emerge -e world</c>. All future packages
190	will be built with PIE/SSP.
191	</p>	547	<p>
192		548	Generally setting the PaX flags is straightforward, but the user should keep
193	<warn>	549	a few things in mind:
194	Both PIE and SSP are known to cause issues with some packages. If you come
195	across a package that fails to compile, please file a detailed bug report including
196	a log of the failed compile and the output of <c>emerge info</c> to
197	<uri>http://bugs.gentoo.org/</uri>.
198	</warn>
199
200	<p>	550	</p>
201	You will probably also want to merge pax-utils.	551
202	Often if an ELF has executable relocations in the text segment these can cause problems for us.
203	scanelf -BRylptq
204	</p>	552	<p>
205		553	1) One can set either PT_PAX and/or XATTR_PAX flags on the ELF object
206		554	independently of one another. Similarly, the kernel can be configured
207	</body>	555	to read either, both or neither fields. It is up to you to make sure that
208	</section>	556	you set the flags in the field being used by the kernel to get the desired
209	</chapter>	557	results. For example, if you have PT_PAX="Pe---" while XATTR_PAX missing on
210		558	the object, but the kernel is configured only to use XATTR_PAX, you may not
211	<chapter>	559	get the desired result!
212	<title>When Things Misbehave (PaX Control)</title>
213	<section>
214	<body>
215
216	<p>	560	</p>
217	Some legitimate applications will attempt to generate code at run time which is	561
218	executed out of memory. Naturally, PaX does not allow this and it will promptly
219	kill the offending application.
220	</p>	562	<p>
221		563	2) The recommended approach is to mark both PT_PAX and XATTR_PAX fields
222	<note>	564	identically on the objects whenever possible, and set the kernel to read only
223	The most notable of these applications are XFree/Xorg, mplayer and multimedia tools	565	XATTR_PAX. The "whenever possible" is where things get complicated and the
224	based on xine-lib. The easiest way around these problems are to disable PaX	566	two fields may not wind up containing the same flags. If the ELF does not
225	protections.	567	contain a PAX_FLAGS program header, PT_PAX marking will fail. However, the
226	</note>	568	absence of this program header will not affect XATTR_PAX markings. If the ELF
227		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.
228	<p>	578	</p>
229	Luckily there is a utility to toggle protections on a per-executable basis,	579
230	<e>paxctl</e>. As with any other package in Gentoo, install paxctl with the
231	command <c>emerge paxctl</c>. Usage is show by <c>paxctl -h</c>.
232	</p>	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/<pid>/status \| grep PaX` gives you the resulting
		584	PaX enforcement on the running process with PID=<pid>. But since the
		585	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>
233		596
234	<note>	597	<p>
235	If you have an older version of binutils, you will need to use <e>chpax</e>,	598	Below we describe the utilities provided on a Gentoo system for working PaX markings.
236	which edits the old-style PaX markings. Usage of chpax is largely the same as	599	There are several since as PaX evolved, new features were needed. Each one emphasizes
237	paxctl. This also requires legacy marking support built into your kernel.	600	a different need with respect to the above caveats.
238	New versions of paxctl make chpax obsolete.	601	</p>
239	</note>	602
		603	<p><b>1. paxctl</b></p>
		604	<p>
		605	This is the traditional upstream package for setting PaX flags. It is limited only
		606	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	</p>
		614
		615	<p>
		616	Here is a synopsis of its usage:
		617	</p>
240		618
241	<pre caption="paxctl -h">	619	<pre caption="paxctl -h">
		620	PaX control v0.7
		621	Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu>
		622
242	usage: paxctl <options> <files>	623	usage: paxctl <options> <files>
243		624
244	options:	625	options:
245	-p: disable PAGEEXEC -P: enable PAGEEXEC	626	-p: disable PAGEEXEC -P: enable PAGEEXEC
246	-e: disable EMUTRMAP -E: enable EMUTRMAP	627	-e: disable EMUTRAMP -E: enable EMUTRAMP
247	-m: disable MPROTECT -M: enable MPROTECT	628	-m: disable MPROTECT -M: enable MPROTECT
248	-r: disable RANDMMAP -R: enable RANDMMAP	629	-r: disable RANDMMAP -R: enable RANDMMAP
249	-x: disable RANDEXEC -X: enable RANDEXEC	630	-x: disable RANDEXEC -X: enable RANDEXEC
250	-s: disable SEGMEXEC -S: enable SEGMEXEC	631	-s: disable SEGMEXEC -S: enable SEGMEXEC
251		632
252	-v: view flags -z: restore default flags	633	-v: view flags -z: restore default flags
253	-q: suppress error messages -Q: report flags in short format 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!)
254	</pre>	637	</pre>
255		638
256	<p>
257	The first option we will note is <c>-v</c>, which can display flags set on a
258	particular binary.
259	</p>	639	<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>
260		645
261	<pre caption="paxctl -v">	646	<pre caption="paxctl in action">
262	shell user # paxctl -v /usr/bin/Xorg	647	# <i>paxctl -v /usr/bin/python3.2</i>
263	PaX control v0.2	648	PaX control v0.7
264	Copyright 2004 PaX Team <pageexec@freemail.hu>	649	Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu>
265		650
266	- PaX flags: -p-sM--x-eR- [/usr/bin/Xorg]	651	- PaX flags: -----m-x-e-- [/usr/bin/python3.2]
267	PAGEEXEC is disabled	652	MPROTECT is disabled
268	SEGMEXEC is disabled
269	MPROTECT is enabled
270	RANDEXEC is disabled	653	RANDEXEC is disabled
271	EMUTRAMP is disabled	654	EMUTRAMP is disabled
272	RANDMMAP is enabled
273	</pre>
274		655
275	<p>	656	# paxctl -P /usr/bin/python3.2
276	This shows an XFree binary with all protections disabled.	657	# paxctl -v /usr/bin/python3.2
		658	PaX control v0.7
		659	Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu>
		660
		661	- PaX flags: P----m-x-e-- [/usr/bin/python3.2]
		662	PAGEEXEC is enabled <--- 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	</pre>
		667
		668	<p><b>2. getfattr setfattr</b></p>
277	</p>	669	<p>
278		670	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.
279	<p>	678	</p>
280	To set flags on a binary, the <c>-z</c> flag is useful as it restores the	679
281	default flags.
282	</p>	680	<p>
283		681	The following is an example of their usage for XATTR_PAX:
284	<p>	682	</p>
285	To disable protections on Xorg, run	683
286	<c>paxctl -zpeMRxs /usr/bin/Xorg</c>.	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" <--- 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." <--- Mom appreciates it, but PaX does not. There is no sanity checking.
		701	</pre>
		702
		703
		704	<p><b>3. paxctl-ng</b></p>
287	</p>	705	<p>
288		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:
289	<p>	714	</p>
290	Play around with disabling/enabling protections to see what is the least needed	715
291	to run. Often we find that we need the -m -sp combos.	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
		745	Note : If both enabling and disabling flags are set, the default - is used
		746	</pre>
		747
292	</p>	748	<p>
		749	The following is an example of paxctl-ng in action:
		750	</p>
		751
		752	<pre caption="paxctl-ng in action">
		753	# <i>paxctl-ng -v /usr/bin/python3.2</i> <--- 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> <--- Set default '-' for PAGEEXEC (-Pp)
		759	/usr/bin/python3.2: <--- For XATTR_FLAGS only (-l)
		760	PT_PAX : Pem-- <--- And report the result (-v)
		761	XATTR_PAX: -em--
		762
		763	# <i>paxctl-ng -dv /usr/bin/python3.2</i> <--- Delete the XATTR_PAX field altogether (-d)
		764	/usr/bin/python3.2: <--- 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> <--- Set "em" flags (-em)
		769	/usr/bin/python3.2: <--- For XATTR_FLAGS only (-l)
		770	PT_PAX : Pem-- <--- And report the result (-v)
		771	XATTR_PAX: -em--
		772
		773	# <i>paxctl-ng -fv /usr/bin/python3.2</i> <--- Copy the XATTR_PAX to PT_PAX flags, overwriting the latter (-f)
		774	/usr/bin/python3.2: <--- And report the result (-v)
		775	PT_PAX : -em--
		776	XATTR_PAX: -em--
		777
		778	# <i>paxctl-ng -d /usr/bin/python3.2</i> <--- Silently delete the XATTR_PAX field (-d but no -v)
		779	# <i>paxctl-ng -v /usr/bin/python3.2</i> <--- 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> <--- Retrieve either PT_PAX or XATTR_PAX. The latter has priority if it exists.
		828	-em-- <--- The canonical order is PEMRS.
		829	# <i>paxctl-ng -v /usr/bin/python3.2</i> <--- 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> <--- 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> <--- Now its reporting XATTR_PAX flags!
		840	PEM--
		841	# <i>pypaxctl -s me /usr/bin/python3.2</i> <--- Set "me" on both PT_PAX and XATTR_PAX.
		842	# <i>paxctl-ng -v /usr/bin/python3.2</i>
		843	/usr/bin/python3.2:
		844	PT_PAX: -em-- <--- 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> <--- 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	it can be compiled with just PT_PAX xor XATTR_PAX support. In this case, the
		857	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	<p>
		884	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
		909	<p>
		910	Here's revdep-pax in action. Since the out is long, we've replaced some
		911	of it with ellipses:
		912	</p>
		913
		914	<pre caption="revdep-pax in action">
		915	# <i>revdep-pax -f</i> < --- Report all mismatching forward linkings.
		916	.....
		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	# <i>revdep-pax -m -b /usr/bin/python3.2</i> < --- Forward port PaX flags for python3.2 only.
		928	/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	Set flags for /usr/lib64/libpython3.2.so.1.0 (y/n): <i>n</i> < --- You will be prompted unless you give -y.
		940	Set flags for /lib64/libpthread-2.16.so (y/n): <i>n</i> < --- We'll say 'n' to each for this demo.
		941	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	# <i>revdep-pax -r</i> < --- Report all mismatching reverse linkings.
		947	.....
		948	libpython3.2.so.1.0 /usr/lib64/libpython3.2.so.1.0 ( -e--- ) < --- The format is soname /path/to/its/elf_object (flags).
		949
		950	/usr/bin/python3.2 ( --m-- ) < --- There is a mismatch here as expected
		951	..... from the previous step.
		952
		953	# <i>revdep-pax -m -s libpython3.2.so.1.0</i> < --- 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	Set flags for /usr/bin/python3.2 (y/n): <i>y</i> < --- Confirm 'y' we want to do this.
		961
		962	/usr/bin/python3.2 ( -em-- )
		963
		964	# <i>paxctl-ng -v /usr/bin/python3.2</i> < --- Double check.
		965	/usr/bin/python3.2:
		966	PT_PAX: -em--
		967	XT_PAX: -em--
		968	</pre>
		969
		970	<p>
		971	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>
293		1004
294	</body>	1005	</body>
295	</section>	1006	</section>
296	</chapter>	1007	</chapter>
297	</guide>	1008	</guide>

 Legend:



Removed from v.1.13
 


changed lines


 
Added in v.1.15
 Legend:



Removed from v.1.13
 


changed lines


 
Added in v.1.15
-Removed from v.1.13
+Added in v.1.15

	ViewVC Help
Powered by ViewVC 1.1.13