aboutsummaryrefslogtreecommitdiff
blob: 67980e1d2e974fd0301469a56c26e12d85ff0b8a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css">
<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives">
<title>Gentoo Linux Documentation
--
  Gentoo Grsecurity v2 Guide</title>
</head>
<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr>
<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr>
<td width="99%" class="content" valign="top" align="left">
<br><h1>Gentoo Grsecurity v2 Guide</h1>
<form name="contents" action="http://www.gentoo.org">
<b>Content</b>:
        <select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. About Grsecurity</option>
<option value="#doc_chap2">2. PaX</option>
<option value="#doc_chap3">3. RBAC</option>
<option value="#doc_chap4">4. Filesystem Protection</option>
<option value="#doc_chap5">5. Kernel Auditing</option>
<option value="#doc_chap6">6. Process Restrictions</option>
<option value="#doc_chap7">7. The Hardened Toolchain</option>
<option value="#doc_chap8">8. Resources</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
            </span>About Grsecurity</p>
<p class="secthead"><a name="doc_chap1_sect1">The Grsecurity Project</a></p>
<p>
The grsecurity project, hosted on <a href="http://www.grsecurity.org">http://www.grsecurity.org</a>, provides
various patches to the Linux kernel which enhance your system's overall
security. The various features brought by grsecurity are discussed in the next
chapter; a comprehensive list is maintained on the <a href="http://www.grsecurity.org/features.php">grsecurity features page</a>
itself.
</p>
<p>
As grsecurity's features are mostly kernel-based, the majority of this document
explains the various kernel features and their respective sysctl operands (if
applicable). 
</p>
<p class="secthead"><a name="doc_chap1_sect2">Gentoo Hardened Integration</a></p>
<p>
The <a href="http://hardened.gentoo.org">Gentoo Hardened Project</a>
maintains security-enhancement features for Gentoo, including but not limited to
grsecurity.
</p>
<p class="secthead"><a name="doc_chap1_sect3">Kernel Configuration</a></p>
<p>
Throughout this document we will talk about kernel configuration using the
kernel variables like <span class="code" dir="ltr">CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS</span>. These are the
variables that the kernel build process uses to determine if a certain feature
needs to be compiled.
</p>
<p>
When you configure your kernel through <span class="code" dir="ltr">make menuconfig</span> or similar, you
receive a user interface through which you can select the various kernel
options. If you select the <span class="emphasis">Help</span> button at a certain kernel feature you
will see at the top that it lists such a kernel variable.
</p>
<p>
You can therefore still configure your kernel as you like - with a bit of
thinking. And if you can't find a certain option, there's always the possibility
to edit <span class="path" dir="ltr">/usr/src/linux/.config</span> by hand :)
</p>
<p>
Of course, to be able to select the various grsecurity kernel options, you must
enable grsecurity in your kernel:
</p>
<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Activating grsecurity</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2.
            </span>PaX</p>
<p class="secthead"><a name="doc_chap2_sect1">Fighting the Exploitation of Software Bugs</a></p>
<p>
PaX introduces a couple of security mechanisms that make it harder for attackers
to exploit software bugs that involve memory corruption (so don't treat PaX as
if it protects against all possible software bugs).  The <a href="http://pax.grsecurity.net/docs/pax.txt">PaX introduction document</a>
talks about three possible exploit techniques:
</p>
<ol>
  <li>introduce/execute arbitrary code</li>
  <li>execute existing code out of original program order</li>
  <li>execute existing code in original program order with arbitrary data</li>
</ol>
<p>
One prevention method disallows executable code to be stored in writable 
memory. When we look at a process, it requires five memory regions:
</p>
<ol>
  <li>
    a <span class="emphasis">data section</span> which contains the statically allocated and global
    data
  </li>
  <li>
    a <span class="emphasis">BSS region</span> (Block Started by Symbol) which contains information
    about the zero-initialized data of the process
  </li>
  <li>
    a <span class="emphasis">code region</span>, also called the <span class="emphasis">text segment</span>, which contains
    the executable instructions
  </li>
  <li>
    a <span class="emphasis">heap</span> which contains the dynamically allocated memory
  </li>
  <li>
    a <span class="emphasis">stack</span> which contains the local variables
  </li>
</ol>
<p>
The first PaX prevention method, called <b>NOEXEC</b>, is meant to give control
over the runtime code generation. It marks memory pages that do not contain 
executable code as non-executable. This means that the heap and the stack, 
which only contain variable data and shouldn't contain executable
code, are marked as non-executable. Exploits that place code in these areas with
the intention of running it will fail.
</p>
<p>
NOEXEC does more than this actually, interested readers should focus their
attention to the <a href="http://pax.grsecurity.net/docs/noexec.txt">PaX
NOEXEC documentation</a>.
</p>
<p>
The second PaX prevention method, called <b>ASLR</b> (Address Space Layout
Randomization), randomize the addresses given to memory requests. Where
previously memory was assigned contiguously (which means exploits know where
the tasks' memory regions are situated) ASLR randomizes this allocation,
rendering techniques that rely on this information useless.
</p>
<p>
More information about ASLR can be found <a href="http://pax.grsecurity.net/docs/aslr.txt">online</a>.
</p>
<p class="secthead"><a name="doc_chap2_sect2">Enabling PaX</a></p>
<p>
The recommended kernel setting for PaX is:
</p>
<a name="doc_chap2_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.1: Recommended PaX Kernel Configuration</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">#
# PaX Control
#
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set</span>
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
<span class="code-comment"># CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set

#
# Address Space Protection
#</span>
CONFIG_GRKERNSEC_PAX_NOEXEC=y
<span class="code-comment"># CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set</span>
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
CONFIG_GRKERNSEC_PAX_MPROTECT=y
<span class="code-comment"># CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set</span>
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y
<span class="code-comment"># CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set</span>
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_HIDESYM=y
</pre></td></tr>
</table>
<p>
If you are running a non-x86 system you will observe that there is no
CONFIG_GRKERNSEC_PAX_NOEXEC. You should select CONFIG_GRKERNSEC_PAX_PAGEEXEC 
instead as it is the only non-exec implementation around.
</p>
<p class="secthead"><a name="doc_chap2_sect3">Controlling PaX</a></p>
<p>
Not all Linux applications are happy with the PaX security restrictions. These
tools include xorg-x11, java, mplayer, xmms and others. If you plan on using
them you can elevate the protections for these applications using <span class="code" dir="ltr">chpax</span>
and <span class="code" dir="ltr">paxctl</span>.
</p>
<a name="doc_chap2_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.2: Installing the chpax and paxctl tools</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge sys-apps/chpax</span>
# <span class="code-input">emerge sys-apps/paxctl</span>
</pre></td></tr>
</table>
<p>
chpax provides an init script that handles most known application settings for
you:
</p>
<a name="doc_chap2_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.3: Adding the chpax init script to the default runlevel</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">rc-update add chpax default</span>
</pre></td></tr>
</table>
<p>
<span class="code" dir="ltr">pax-utils</span> is a small toolbox which contains useful applications to
administrate a PaX aware server. 
</p>
<a name="doc_chap2_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.4: Installing pax-utils</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge pax-utils</span>
</pre></td></tr>
</table>
<p>
Interesting tools include <span class="code" dir="ltr">scanelf</span> and <span class="code" dir="ltr">pspax</span>:
</p>
<ul>
  <li>
    With <span class="code" dir="ltr">scanelf</span> you can scan over library and binary directories and
    list the various permissions and ELF types that pertain to running an ideal
    pax/grsec setup
  </li>
  <li>
    With <span class="code" dir="ltr">pspax</span> you can display PaX flags/capabilities/xattr from the
    kernel's perspective
  </li>
</ul>
<p class="secthead"><a name="doc_chap2_sect4">Verifying the PaX Settings</a></p>
<p>
Peter Busser has written a regression test suite called <span class="code" dir="ltr">paxtest</span>. This
tool will check various cases of possible attack vectors and inform you of the
result. When you run it, it will leave a logfile called <span class="path" dir="ltr">paxtest.log</span>
in the current working directory.
</p>
<a name="doc_chap2_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.5: Installing and running paxtest</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge paxtest</span>

# <span class="code-input">paxtest</span>
Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 25 bits (guessed)
Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
Main executable randomisation (ET_DYN)   : 17 bits (guessed)
Shared library randomisation test        : 16 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : No randomisation
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
</pre></td></tr>
</table>
<p>
In the above example run you notice that:
</p>
<ul>
  <li>
    strcpy and memcpy are listed as <span class="emphasis">Vulnerable</span>. This is expected and
    normal - it is simply showing the need for a technology such as ProPolice/SSP
  </li>
  <li>
    there is no randomization for PAGEEXEC. This is normal since our recommended
    x86 kernel configuration didn't activate the PAGEEXEC setting. However, on
    arches that support a true NX (non-executable) bit (most of them do,
    including x86_64), PAGEEXEC is the only method available for NOEXEC and 
    has no performance hit.
  </li>
</ul>
<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3.
            </span>RBAC</p>
<p class="secthead"><a name="doc_chap3_sect1">Role Based Access Control</a></p>
<p>
There are two basic types of access control mechanisms used to prevent
unauthorized access to files (or information in general): DAC (Discretionary
Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC
mechanism: the creator of the file can define who has access to the file. A MAC
system however forces everyone to follow rules set by the administrator.
</p>
<p>
The MAC implementation grsecurity supports is called Role Based Access
Control. RBAC associates <span class="emphasis">roles</span> with each user. Each role defines what
operations can be performed on certain objects. Given a well-written collection
of roles and operations your users will be restricted to perform only those
tasks that you tell them they can do. The default "deny-all" ensures you that a
user cannot perform an action you haven't thought of.
</p>
<p class="secthead"><a name="doc_chap3_sect2">Configuring the Kernel</a></p>
<p>
The recommended kernel setting for RBAC is:
</p>
<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.1: Recommended RBAC Kernel Configuration</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">#
# Role Based Access Control Options
#</span>
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
</pre></td></tr>
</table>
<p class="secthead"><a name="doc_chap3_sect3">Working with gradm</a></p>
<p>
<span class="code" dir="ltr">gradm</span> is a tool which allows you to administer and maintain a policy for
your system. With it, you can enable or disable the RBAC system, reload 
the RBAC roles, change your role, set a password for admin mode, etc.
</p>
<p>
When you install <span class="code" dir="ltr">gradm</span> a default policy will be installed in
<span class="path" dir="ltr">/etc/grsec/policy</span>:
</p>
<a name="doc_chap3_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.2: Installing gradm</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge gradm</span>
</pre></td></tr>
</table>
<p>
By default, the RBAC policies are not activated. It is the sysadmin's job to
determine when the system should have an RBAC policy enforced and not Gentoo's.
Before activating the RBAC system you should set an admin password.
</p>
<a name="doc_chap3_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.3: Activating the RBAC system</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">gradm -P</span>
Setting up grsecurity RBAC password
Password: <span class="code-comment">(Enter a well-chosen password)</span>
Re-enter Password: <span class="code-comment">(Enter the same password for confirmation)</span>
Password written in /etc/grsec/pw
# <span class="code-input">gradm -E</span>
</pre></td></tr>
</table>
<p>
To disable the RBAC system, run <span class="code" dir="ltr">gradm -D</span>. If you are not allowed to, you
first need to switch to the admin role:
</p>
<a name="doc_chap3_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.4: Disabling the RBAC system</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">gradm -a admin</span>
Password: <span class="code-comment">(Enter your admin role password)</span>
# <span class="code-input">gradm -D</span>
</pre></td></tr>
</table>
<p>
If you want to leave the admin role, run <span class="code" dir="ltr">gradm -u admin</span>:
</p>
<a name="doc_chap3_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.5: Dropping the admin role</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">gradm -u admin</span>
</pre></td></tr>
</table>
<p class="secthead"><a name="doc_chap3_sect4">Generating a Policy</a></p>
<p>
The RBAC system comes with a great feature called "learning mode". The learning
mode can generate an anticipatory least privilege policy for your system. This
allows for time and money savings by being able to rapidly deploy multiple
secure servers.
</p>
<p>
To use the learning mode, activate it using <span class="code" dir="ltr">gradm</span>:
</p>
<a name="doc_chap3_pre6"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.6: Activating the RBAC learning mode</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">gradm -F -L /etc/grsec/learning.log</span>
</pre></td></tr>
</table>
<p>
Now use your system, do the things you would normally do. Try to avoid rsyncing,
running locate of any other heavy file i/o operation as this can really slow
down the processing time.
</p>
<p>
When you believe you have used your system sufficiently to obtain a good policy,
let <span class="code" dir="ltr">gradm</span> process them and propose roles under 
<span class="path" dir="ltr">/etc/grsec/learning.roles</span>:
</p>
<a name="doc_chap3_pre7"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.7: Processing learning mode logs</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles</span>
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>Note: </b>
You will need to disable the RBAC learning mode before doing this. You can use
<span class="code" dir="ltr">gradm -D</span> for this.
</p></td></tr></table>
<p>
Audit the <span class="path" dir="ltr">/etc/grsec/learning.roles</span> and save it as
<span class="path" dir="ltr">/etc/grsec/policy</span> (mode 0600) when you are finished.
</p>
<a name="doc_chap3_pre8"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.8: Saving the policies</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">mv /etc/grsec/learning.roles /etc/grsec/policy</span>
# <span class="code-input">chmod 0600 /etc/grsec/policy</span>
</pre></td></tr>
</table>
<p>
You will now be able to enable the RBAC system with your new learned policy.
</p>
<p class="secthead"><a name="doc_chap3_sect5">Tweaking your Policy</a></p>
<p>
An interesting feature of grsecurity 2.x is <span class="emphasis">Set Operation Support</span> for the
configuration file. Currently it supports unions, intersections and differences
of sets (of objects in this case).
</p>
<a name="doc_chap3_pre9"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.9: Example sets</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
define objset1 {
/root/blah rw
/root/blah2 r
/root/blah3 x
}

define somename2 {
/root/test1 rw
/root/blah2 rw
/root/test3 h
}
</pre></td></tr>
</table>
<p>
Here is an example of its use, and the resulting objects that will be added to
your subject:
</p>
<a name="doc_chap3_pre10"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.10: &amp; Example</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
$objset1 &amp; $somename2
</pre></td></tr>
</table>
<p>
The above would expand to:
</p>
<a name="doc_chap3_pre11"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.11: Resulting subject settings</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
/root/blah2 r
</pre></td></tr>
</table>
<p>
This is the result of the &amp; operator which takes both sets and returns the
files that exist in both sets and the permission for those files that exist
in both sets.
</p>
<a name="doc_chap3_pre12"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.12: | Example</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
$objset1 | $somename2
</pre></td></tr>
</table>
<p>
This example would expand to:
</p>
<a name="doc_chap3_pre13"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.13: Resulting subject settings</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
/root/blah rw
/root/blah2 rw
/root/blah3 x
/root/test1 rw
/root/test3 h
</pre></td></tr>
</table>
<p>
This is the result of the | operator which takes both sets and returns the
files that exist in either set.  If a file exists in both sets, it is returned
as well and the mode contains the flags that exist in either set.
</p>
<a name="doc_chap3_pre14"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.14: - Example</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
$objset1 - $somename2
</pre></td></tr>
</table>
<p>
This example would expand to:
</p>
<a name="doc_chap3_pre15"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.15: Resulting subject settings</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
subject /somebinary o
/root/blah rw
/root/blah2 h
/root/blah3 x
</pre></td></tr>
</table>
<p>
This is the result of the - operator which takes both sets and returns the
files that exist in the set on the left but not in the match of the file in
set on the right. If a file exists on the left and a match is found on the
right (either the filenames are the same, or a parent directory exists in
the right set), the file is returned and the mode of the second set is
removed from the first set, and that file is returned.
</p>
<p>
In some obscure pseudo-language you could see this as:
</p>
<a name="doc_chap3_pre16"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.16: Pseudo-language explanation</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
if ( (<span class="code-input">$objset1</span> contained <span class="code-input">/tmp/blah rw</span>) and
     (<span class="code-input">$objset2</span> contained <span class="code-input">/tmp/blah r</span>) )
then
  <span class="code-input">$objset1 - $objset2</span> would contain <span class="code-input">/tmp/blah w</span>

if ( (<span class="code-input">$objset1</span> contained <span class="code-input">/tmp/blah rw</span>) and
     (<span class="code-input">$objset2</span> contained <span class="code-input">/ rwx</span>) )
then 
  <span class="code-input">$objset1 - $objset2</span> would contain <span class="code-input">/tmp/blah h</span>
</pre></td></tr>
</table>
<p>
As for order of precedence (from highest to lowest): "-, &amp; |".
</p>
<p>
If you do not want to bother remembering precedence, parenthesis support
is also included, so you can do things like:
</p>
<a name="doc_chap3_pre17"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.17: Parenthesis example</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(($set1 - $set2) | $set3) &amp; $set4
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4.
            </span>Filesystem Protection</p>
<p class="secthead"><a name="doc_chap4_sect1">Fighting Chroot and Filesystem Abuse</a></p>
<p>
Grsecurity2 includes many patches that prohibits users from gaining unnecessary
knowledge about the system. This includes restrictions on <span class="path" dir="ltr">/proc</span>
usage, chrooting, linking, etc.
</p>
<p class="secthead"><a name="doc_chap4_sect2">Kernel Configuration</a></p>
<p>
We recommend the following grsecurity kernel configuration for filesystem
protection:
</p>
<a name="doc_chap4_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.1: Activating Filesystem Protection</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">#
# Filesystem Protections
#</span>
CONFIG_GRKERNSEC_PROC=y
<span class="code-comment"># CONFIG_GRKERNSEC_PROC_USER is not set</span>
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
</pre></td></tr>
</table>
<p class="secthead"><a name="doc_chap4_sect3">Triggering the Security Mechanism</a></p>
<p>
When you're using a kernel compiled with the above (or similar) settings, you
will get the option to enable/disable many of the options through the
<span class="path" dir="ltr">/proc</span> filesystem or via <span class="code" dir="ltr">sysctl</span>.
</p>
<p>
The example below shows an excerpt of a typical <span class="path" dir="ltr">/etc/sysctl.conf</span>:
</p>
<a name="doc_chap4_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.2: Example settings inside /etc/sysctl.conf</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_execlog = 0
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_shmat = 1
</pre></td></tr>
</table>
<p>
You can enable or disable settings at will using the <span class="code" dir="ltr">sysctl</span> command:
</p>
<a name="doc_chap4_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.3: Enabling sysctl settings</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">(Toggling the exec_logging feature ON)</span>
# <span class="code-input">sysctl -w kernel.grsecurity.exec_logging = 1</span>
<span class="code-comment">(Toggling the exec_logging feature OFF)</span>
# <span class="code-input">sysctl -w kernel.grsecurity.exec_logging = 0</span>
</pre></td></tr>
</table>
<p>
There is a very important sysctl setting pertaining to grsecurity, namely
<span class="code" dir="ltr">kernel.grsecurity.grsec_lock</span>. When set, you are not able to change any
setting anymore. 
</p>
<a name="doc_chap4_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.4: Locking the sysctl interface</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">sysctl -w kernel.grsecurity.grsec_lock = 1</span>
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5.
            </span>Kernel Auditing</p>
<p class="secthead"><a name="doc_chap5_sect1">Extend your System's Logging Facilities</a></p>
<p>
grsecurity adds extra functionality to the kernel pertaining the logging. With
grsecurity's <span class="emphasis">Kernel Auditing</span> the kernel informs you when applications are
started, devices (un)mounted, etc.
</p>
<p class="secthead"><a name="doc_chap5_sect2">The various Kernel Audit Settings</a></p>
<p>
The following kernel configuration section can be used to enable grsecurity's
Kernel Audit Settings:
</p>
<a name="doc_chap5_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.1: Activating Kernel Auditing</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set</span>
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_AUDIT_IPC=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6.
            </span>Process Restrictions</p>
<p class="secthead"><a name="doc_chap6_sect1">Executable Protection</a></p>
<p>
With grsecurity you can restrict executables. Since most exploits work through
one or more running processes this protection can save your system's health.
</p>
<p class="secthead"><a name="doc_chap6_sect2">Network Protection</a></p>
<p>
Linux' TCP/IP stack is vulnerable to prediction-based attacks. grsecurity
includes randomization patches to counter these attacks. Apart from these you
can also enable socket restrictions, disallowing certain groups network access
alltogether.
</p>
<p class="secthead"><a name="doc_chap6_sect3">Kernel Settings</a></p>
<p>
The following kernel settings enable various executable and network protections:
</p>
<a name="doc_chap6_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing6.1: Kernel setting</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">#
# Executable Protections
#</span>
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
CONFIG_GRKERNSEC_TPE_GID=100

<span class="code-comment">#
# Network Protections
#</span>
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
<span class="code-comment"># CONFIG_GRKERNSEC_SOCKET is not set</span>
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap7"></a><span class="chapnum">7.
            </span>The Hardened Toolchain</p>
<p>
Although it is outside the scope of this document we mention the use of the
hardened toolchain which completes the grsec/PaX model from userspace. As a
quickstart you can do:
</p>
<a name="doc_chap7_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing7.1: Using the hardened toolchain</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">eselect profile list</span>
[1]   default/linux/amd64/10.0
[2]   default/linux/amd64/10.0/desktop
[3]   default/linux/amd64/10.0/desktop/gnome *
[4]   default/linux/amd64/10.0/desktop/kde
[5]   default/linux/amd64/10.0/developer
[6]   default/linux/amd64/10.0/no-multilib
[7]   default/linux/amd64/10.0/server
[8]   hardened/linux/amd64
[9]   hardened/linux/amd64/no-multilib
[10]  selinux/2007.0/amd64
[11]  selinux/2007.0/amd64/hardened
[12]  selinux/v2refpolicy/amd64
[13]  selinux/v2refpolicy/amd64/desktop
[14]  selinux/v2refpolicy/amd64/developer
[15]  selinux/v2refpolicy/amd64/hardened
[16]  selinux/v2refpolicy/amd64/server
# <span class="code-input">eselect profile set 8</span> <span class="code-comment">(replace 8 with the desired hardened profile)</span>
# <span class="code-input">emerge --oneshot binutils gcc virtual/libc</span>
# <span class="code-input">emerge -e system</span>
# <span class="code-input">emerge -e world</span>
</pre></td></tr>
</table>
<p>
If you don't want to use this profile, add these <span class="code" dir="ltr">hardened pic</span> USE flags to your
USE variable in <span class="path" dir="ltr">/etc/make.conf</span>. 
</p>
<p class="chaphead"><a name="doc_chap8"></a><span class="chapnum">8.
            </span>Resources</p>
<ul>
  <li><a href="http://grsecurity.net/">Grsecurity Homepage</a></li>
  <li><a href="http://forums.grsecurity.net/">Grsecurity Forums</a></li>
  <li>
    <a href="http://grsecurity.net/researchpaper.pdf">Increasing Performance 
    and Granularity in Role-Based Access Control Systems</a>

  </li>
  <li>
    <a href="capabilities.html">
    Capability Names and Descriptions</a>
  </li>
  <li>
    <a href="http://grsecurity.net/quickstart.pdf">Grsecurity Quick-Start 
    Guide</a> (NEW .pdf)
  </li>

  <li>
    <a href="pax-quickstart.html">Using PaX with 
    Gentoo QuickStart</a> (NEW)
  </li>
  <li>
    <a href="http://hardened.gentoo.org/grsecurity.xml">Grsecurity with 
    Gentoo 1.9.x MAC system</a> (OLD)
  </li>
  <li>
    <a href="http://grsecurity.net/PaX-presentation_files/frame.htm">PaX: The 
    Guaranteed End of Arbitrary Code Execution</a>

  </li>
  <li>
    <a href="http://pax.grsecurity.net">PaX HomePage and Documentation</a>
  </li>
  <li>
    <a href="http://www.gentoo.org/proj/en/infrastructure/tenshi">Tenshi</a>
  </li>
</ul>
<br><br>
</td>
<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="grsecurity.xml?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Updated May 10, 2010</p></td></tr>
<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>
This document features the grsecurity 2.x security patches, supported kernel
configuration options and tools provided by the grsecurity project to lift your
system's security to higher standards.
</p></td></tr>
<tr><td align="left" class="topsep"><p class="alttext">
  <a href="mailto:solar@gentoo.org" class="altlink"><b>solar</b></a>
<br><i>Author</i><br><br>
  <a href="mailto:sven.vermeulen@siphos.be" class="altlink"><b>Sven Vermeulen</b></a>
<br><i>Author</i><br></p></td></tr>
<tr lang="en"><td align="center" class="topsep">
<p class="alttext"><b>Donate</b> to support our development efforts.
        </p>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo">
</form>
</td></tr>
<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr>
</table></td>
</tr></table></td></tr>
<tr><td colspan="2" align="right" class="infohead">
Copyright 2001-2011 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>.
</td></tr>
</table></body>
</html>