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
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
|
<?xml version="1.0" encoding="UTF-8"?>
<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="xccdf_org.gentoo.dev.swift_benchmark_gentoo-20140326-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0">
<status date="2014-03-26">draft</status>
<title>Gentoo Security Benchmark</title>
<description>
This benchmarks helps people in improving their system configuration to be
more resilient against attacks and vulnerabilities.
</description>
<platform idref="cpe:/o:gentoo:linux"/>
<version>20140326.1</version>
<model system="urn:xccdf:scoring:default" />
<model system="urn:xccdf:scoring:flat" />
<model system="urn:xccdf:scoring:flat-unweighted" />
<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default">
<title>Intensive validation profile</title>
<description>
This profile extends the default server profile by including tests that
are more intensive to run on a system. Tests such as full file system
scans to find world-writable files or directories have an otherwise too
large impact on the performance of a server. Tests include scripted
validationn.
</description>
</Profile>
<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
<title>Intensive validation profile (non-scripted)</title>
<description>
This profile extends the default server profile by including tests that
are more intensive to run on a system. Tests such as full file system
scans to find world-writable files or directories have an otherwise too
large impact on the performance of a server. Tests do not include
scripted validation.
</description>
</Profile>
<Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval">
<title>Default server setup settings (non-scripted)</title>
<description>
In this profile, we verify common settings for Gentoo Linux
configurations. The tests that are enabled in this profile can be ran
without visibly impacting the performance of the system. No scripted
checks are executed.
</description>
<!-- The /tmp location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" />
<!-- The /var location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" />
<!-- The /var/log location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" />
<!-- The /var/log/audit location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" />
<!-- The /home location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" />
<!-- The /var/tmp location is a separate file system -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" />
<!-- The /var partition is mounted with nodev -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" />
<!-- The /var/log partition is mounted with nodev -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" />
<!-- The /var/log/audit partition is mounted with nodev -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" />
<!-- The /home partition is moounted with nodev -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" />
<!-- The /tmp partition is mounted with nodev -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" />
<!-- The /tmp partition is mounted with nosuid -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" />
<!-- The /home partition is mounted with nosuid -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" />
<!-- The /dev/shm partition is mounted with nosuid -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" />
<!-- The /tmp partition is mounted with noexec -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" />
<!-- The /dev/shm partition is mounted with noexec -->
<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" />
<!-- Kernel quota support must be enabled -->
<select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" />
<!-- /var is mounted with usrquota or grpquota -->
<select idref="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="true" />
<!-- /home is mounted with usrquota or grpquota -->
<select idref="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="true" />
<!-- No telnetd process is running -->
<select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" />
<!-- No ftpd process is running -->
<select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" />
<!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) -->
<select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" />
<!-- sulogin is used as shell for single user boot (definition /etc/inittab) -->
<select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" />
<!-- Verify that /etc/hosts.allow exists -->
<select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" />
<!-- Verify that /etc/at/at.allow exists -->
<select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" />
<!-- Make sure USE=pam is set -->
<select idref="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="true" />
<!-- Make sure USE=tcpd is set -->
<select idref="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="true" />
<!-- Make sure USE=ssl is set -->
<select idref="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="true" />
<!-- Make sure FEATURES=webrsync-gpg is set -->
<select idref="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="true" />
<!-- Make sure PORTAGE_GPG_DIR is set -->
<select idref="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="true" />
<!-- Make sure /etc/securetty only contains console and tty's -->
<select idref="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="true" />
</Profile>
<Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
<title>Default server setup settings</title>
<description>
In this profile, common settings for Gentoo Linux configurations are validated.
The tests can be ran without visibly impacting the performance of the system, and
also includes the scripted evaluation checks (SCE).
</description>
<!-- The hardened toolchain must be installated and used -->
<select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" />
</Profile>
<Group id="xccdf_org.gentoo.dev.swift_group_intro">
<title>Introduction</title>
<description>
<h:p>
Since years, Gentoo Linux has a Gentoo Security Handbook
which provides a good insight in secure system
configuration for a Gentoo systems. Although this is important, an
improved method for describing and tuning a systems' security state has
emerged: SCAP, or the <h:em>Security Content Automation Protocol</h:em>.
</h:p>
<h:p>
As such, this benchmark is an update on the security
handbook, including both the in-depth explanation of settings as well as
the means to validate if a system complies with this or not. Now, during
the development of this benchmark document, not include all
information from the Gentoo Security Handbook is included as some of the
settings are specific to a service that is not all that default on a
Gentoo Linux system or sufficiently separate that can benefit other
distributions as well. Although these settings are important as well, it is
best done in separate benchmarks for those services instead.
</h:p>
<h:p>
Where applicable, this benchmark will refer to a different hardening guide
for specific purposes (such as the Hardening OpenSSH benchmark).
</h:p>
</description>
<reference href="http://www.gentoo.org/doc/en/security/security-handbook.xml">Gentoo
Security Handbook</reference>
<Group id="xccdf_org.gentoo.dev.swift_group_intro-security">
<title>This is no security policy</title>
<description>
<h:p>
It is <h:em>very important</h:em> to realize that this document is not a
policy. There is no obligation to follow this to make a secure system
nor should everything in this document be agreed upon. This document is
a set of common best practices with the explanation (why is it a best practice)
and method (how to implement the best practice).
</h:p>
<h:p>
The purpose of this document is to guide readers in their quest to hardening
their systems. It will provide pointers that could help in deciding
particular configuration settings and will do this hopefully using
sufficient background information to allow readers to make a good choice.
</h:p>
<h:p>
Readers might find settings they don't agree with. That's fine, but
if there is disagreement about <h:em>why</h:em> it is documented, we would
like to hear it so we can update the guide accordingly.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_intro-scap">
<title>A little more about SCAP and OVAL</title>
<description>
<h:p>
Within SCAP, NIST has defined some new standards of which XCCDF and OVAL
are notably important in light of this guide.
</h:p>
<h:ul>
<h:li>
XCCDF (Extensible Configuration Checklist Description Format) is
a specification language for writing security checklists and benchmarks
</h:li>
<h:li>
OVAL (Open Vulnerability and Assessment Language) is a standard to describe
and validate system settings
</h:li>
</h:ul>
<h:p>
Thanks to the OVAL and XCCDF standards, a security engineer can now describe
how the state of a system should be configured, how this can be checked
automatically and even report on these settings. Furthermore, within the
description, the engineer can make "profiles" of different states (such as
a profile for a workstation, server (generic), webserver, LDAP server,
...) and reusing the states (rules) identified in a more global scope.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_intro-using">
<title>Using this guide</title>
<description>
<h:p>
This guide is generated from SCAP content (more specifically, the XCCDF document)
using <h:b>openscap</h:b>, a free software implementation for handling SCAP content.
Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools,
and the following command is used to generate the HTML output:
</h:p>
<h:pre>
# <h:b>oscap xccdf generate guide gentoo-xccdf.xml > output.html</h:b></h:pre>
<h:p>
Secondly, together with this XCCDF XML, an OVAL XML file is made available.
The two files combined allow OVAL interpreters to automatically validate
various settings as documented in the benchmark.
</h:p>
<h:p>
Finally, if certain tests are not available in OVAL yet, scripts are provided
that can be executed through the SCE (Script Check Engine) support in openscap.
As scripts are not guaranteed to have no impact on the system (or leave traces),
<h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE)
checks.
</h:p>
<h:p>
To validate the tests, the following commands can be used:
</h:p>
<h:pre>
# <h:b>export PROFILE="xccdf_org.gentoo.dev.swift_profile_default"</h:b>
# <h:b>oscap xccdf eval --profile ${PROFILE} gentoo-xccdf.xml</h:b></h:pre>
<h:p>
To generate a full report in HTML as well, use the next command:
</h:p>
<h:pre>
# <h:b>oscap xccdf eval --profile ${PROFILE} --results xccdf-results.xml \
--report report.html gentoo-xccdf.xml</h:b></h:pre>
<h:p>
Finally, this benchmark will suggest some settings that do not reflect the
will of the reader. That is perfectly fine - even more, some settings might even
raise eyebrows left and right. This document will explain the reasoning behind
the settings but deviations are always possible. If that is the case,
disable the rules in the XCCDF document or, better yet, create a new profile
and only refer to the tests that are required.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles">
<title>Available XCCDF Profiles</title>
<description>
<h:p>
As mentioned earlier, the XCCDF document supports multiple profiles. For the time
being, two profiles are defined:
</h:p>
<h:ul>
<h:li>
The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains
tests that are quick to validate
</h:li>
<h:li>
The <h:em>default-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default-oval)
is like the default one, but does not call any other checker than OVAL
(so no scripts).
</h:li>
<h:li>
The <h:em>intensive</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive)
contains all tests, including those that take a while (for instance because they
perform full file system scans)
</h:li>
<h:li>
The <h:em>intensive-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive-oval)
is like the intensive one, but does not call any other checker than OVAL
(so no scripts).
</h:li>
</h:ul>
<h:p>
Substitute the profile information in the commands above with the required profile.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_intro-weights">
<title>About the rule weights</title>
<description>
<h:p>
Within this guide, weights are assigned to tests to give some importance to
the rule (higher weight is more important) as well as a severity.
</h:p>
<h:p>
The severity is one of the following:
</h:p>
<h:ul>
<h:li>
<h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity
<h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily
exploitable and could lead to full system compromise.
</h:li>
<h:li>
<h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity
<h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily
exploitable.
</h:li>
<h:li>
<h:em>low</h:em> reflects a non-serious problem. A rule with this severity
has detected a misconfiguration but its influence on the overall system security
is minor (if other compliance rules are followed).
</h:li>
<h:li>
<h:em>info</h:em> reflects an informational rule. Failure to comply with this rule
does not mean failure to comply with the document itself.
</h:li>
</h:ul>
<h:p>
It is important to understand though that rules with a low severity can still lead to
grave security problems if they are not met. Chaining of vulnerabilities or
misconfiguration can still lead to full system compromise.
</h:p>
<h:p>
For this reason, weights are added to rules as well. A higher weight has a more
severe potential impact.
</h:p>
<h:p>
Weights are the CVSS (or CCSS) score that is thought to be the case for a misconfiguration.
They are calculated by NVD's CVSS calculator. Each rule is scored individually; a
"chain" of misconfigurations might lead to a significantly higher issue, but this would
make it very hard to make proper scoring.
</h:p>
<h:p>
As an example, take the rule that says <h:code>/var</h:code> has to be on its own
partition. The metrics we fill in in the calculator are currently based on the risk
that the root file system is filled (no more free space), which can halt the system.
</h:p>
<h:ul>
<h:li>
The <h:em>related exploit range</h:em> (access vector) is "Local", because this is
by itself not exploitable remotely - unless of course certain services are running
that can fill up <h:code>/var</h:code>, but such assumptions are not taken.
</h:li>
<h:li>
The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is
needed is a local account and we can find the necessary ways to fill up
<h:code>/var</h:code>.
</h:li>
<h:li>
The <h:em>level of authentication needed</h:em> (authentication) is "Single"
as the attacker needs one authentication step (local access) to exploit.
</h:li>
<h:li>
The <h:em>confidentiality impact</h:em> is "None" (no data leakage)
</h:li>
<h:li>
The <h:em>integrity impact</h:em> is "None" (no data manipulation)
</h:li>
<h:li>
The <h:em>availability impact</h:em> is "Complete" (system crash or halt).
</h:li>
</h:ul>
<h:p>
This results in the CVSS base score of 4.6. The environmental score metrics and
temporal score metrics are ignored as those are too specific for environments
and organizations.
</h:p>
</description>
<reference href="https://nvd.nist.gov/cvss.cfm?calculator&version=2">NVD CVSS calculator</reference>
<reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation">
<title>Before starting</title>
<description>
Before starting to deploy Gentoo Linux and start hardening it, it is wise
to take a step back and think about what to accomplish. Setting
up a more secured Gentoo Linux isn't a goal, but a means to reach
something. Most likely the system will become a Gentoo Linux powered server.
What is this server for? Where will it be hosted? What services are scheduled to run
on this operating system? Etc.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-architecturing">
<title>Infrastructure architecturing</title>
<description>
<h:p>
When considering the entire IT architecture, many architecturing
frameworks exist to write down and further design infrastructure.
There are very elaborate ones, like TOGAF (The Open Group Architecture
Framework), but smaller ones exist as well.
</h:p>
<h:p>
A well written and maintained infrastructure architecture helps to
position new services or consider the impact of changes on existing
components.
</h:p>
<h:p>
Security is about reducing risks, not about harassing people or making
work for a system administrator harder. And reducing risks also means
that a clear eye needs to be kept on the architecture and all its
components. If there is no knowledge as to what is being integrated, where
it is going to be installed or why, then hardening by itself will probably not
do much to the secure state of the system.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements">
<title>Mapping requirements</title>
<description>
<h:p>
When designing a service, we need to take both functional and
non-functional requirements into account. That does sound like
overshooting for a simple server installation, but it is not. Is
auditing considered? Where should the audit logs be sent to? What
about authentication? Centrally managed, or manually set? And the server,
will it only host a particular service, or will it provide several services?
</h:p>
<h:p>
When hosting multiple services on the same server, make sure that the
server is positioned within the network on an acceptable segment. It is
not safe to host central LDAP infrastructure on the same system as
a web server that is facing the Internet.
</h:p>
</description>
<reference href="https://www.ibm.com/developerworks/rational/library/4706.html">IBM DeveloperWorks article on "Capturing Architectural Requirements"</reference>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware">
<title>Non-software security concerns</title>
<description>
From the next chapter onwards, the focus will be on the software side
hardening. There are of course also non-software concerns that need to be
taken care of.
</description>
<reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-physical">
<title>Physical security</title>
<description>
<h:p>
Make sure that the system is only accessible (physically) by trusted
people. Fully hardening a system, only to have a malicious person
take out the harddisk and run away with the confidential data is not
something fun to experience.
</h:p>
<h:p>
When physical security cannot be guaranteed (like with laptops), make
sure that theft of the device only results in the loss of the hardware
and not of the data and software on it (take backups!), and also that the
data on it cannot be read by unauthorized people.
</h:p>
</description>
<reference
href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-policies">
<title>Policies and contractual agreements</title>
<description>
<h:p>
Create or validate the security policies in the organization. This is
not only as a stick (against internal people who might want to abuse
their powers) but also to document and describe why certain decisions
are made (both architecturally as otherwise).
</h:p>
<h:p>
Make sure that the reasoning for the guidelines is clear. If the policies ever
need to be adjusted towards new environments or concepts (like "bring your own
device") having the reasons for the (old) guidelines documented will make it much
easier to write new ones.
</h:p>
</description>
<reference
href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference>
<reference
href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference>
</Group>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_installation">
<title>Installation configuration</title>
<description>
Gentoo Linux allows us to update various parts of the system after installation,
but it might be interesting to consider the following aspects during (or before)
installation to not risk a huge migration project later.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage">
<title>Storage configuration</title>
<description>
Storage is of utmost importance in any environment. It needs to be
sufficiently fast (performance), but also secure and
manageable while remaining flexible to handle future changes.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning">
<title>Partitioning</title>
<description>
Know which locations in the file system structure need to be on a
different partition or logical volume. Separate locations allow for a
more distinct segregation (for instance, no hard links between different
file systems) and low-level protection (file system corruption impact,
but also putting the right data on the right storage media).
</description>
<reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy
Standard</reference>
<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning-separate">
<title>Separate file systems for important locations</title>
<description>
<h:p>
Having a separate file system for important locations has several advantages, but
those advantages need to be weighted against the disadvantages of separate file
systems.
</h:p>
<h:p>
These disadvantages are:
</h:p>
<h:ul>
<h:li>
Separate file systems mean that better disk space control is needed
(governing free space). A file system that is given too much free space
means that disk space is being wasted, but a file system that is not given
enough free disk space will need to be grown quickly - if possibile. This
also means that creating a proper partitioning setup with many different
partitions (file systems) will take some time and calculations; many users
have no good idea how much space they need to make available for a file system.
</h:li>
<h:li>
Some file system locations need to be available early in the boot process.
If those locations reside on different file systems, special precautions need
to be taken to make those file systems available when the system is booted
(such as creating an initial ram file system).
</h:li>
</h:ul>
<h:p>
The advantages on the other hand:
</h:p>
<h:ul>
<h:li>
A sudden disk space growth will eventually be stopped by the limits of the
file system. If a non-critical file system is full, the impact on the overall
system is limited. Without separate file systems, a full file system might
jeopardise the availability of the entire system.
</h:li>
<h:li>
Specific mount options can be enabled on the file systems that improve the
security of the file system (permissions) as well as performance. Such mount
options include ownership details, allowing (or disallowing) setuid binaries,
device files and more.
</h:li>
<h:li>
Different file systems can be hosted on different devices (or even on network
shares), allowing administrators to pick the most efficient storage device
for a particular file system.
</h:li>
</h:ul>
<h:p>
Considering these pros and cons, it is recommended to have at least the following
file system locations to be on a different file system:
</h:p>
<h:ul>
<h:li>
<h:code>/tmp</h:code> as this is a world-writable location and requires
specific mount options. When possible, this location can be made a
<h:em>tmpfs</h:em> file system. This is to protect the root file system
from being flooded.
</h:li>
<h:li>
<h:code>/var</h:code> as this contains variable data (and thus is prone
to grow extensively depending on the installed services). This is to protect
the root file system from being flooded.
</h:li>
<h:li>
<h:code>/var/log</h:code> as this contains logging data (and thus is prone
to grow extensively depending on the services). This is to protect the
<h:code>/var</h:code> file system from being flooded, as this might impact
various services (like databases, web servers, etc.).
</h:li>
<h:li>
<h:code>/var/log/audit</h:code> as this contains (potentially sensitive)
logging data. Some services refuse to continue if the audit target location
is full. Having the location separate from <h:code>/var/log</h:code> protects
the audit file system when <h:code>/var/log</h:code> would be flooded.
</h:li>
<h:li>
<h:code>/home</h:code> as this is completely under the control of end users.
It needs to be mounted with more secure settings (more about that later) and
should be separate both to protect the root file system, but also to allow
the <h:code>/home</h:code> location to be either shared or used elsewhere.
</h:li>
<h:li>
<h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> location,
but where the content is preserved after a reboot. Still, it is world-writable
and requires specific mount options, and should be on a different file system
to prevent <h:code>/var</h:code> to be flooded which might impact the
availability of services.
</h:li>
</h:ul>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6">
<title>/tmp is a separate file system</title>
<fixtext>
Create a file system for <h:code>/tmp</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6">
<title>/var is a separate file system</title>
<fixtext>
Create a file system for <h:code>/var</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1">
<title>/var/log is a separate file system</title>
<fixtext>
Create a file system for <h:code>/var/log</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1">
<title>/var/log/audit is a separate file system</title>
<fixtext>
Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6">
<title>/home is a separate file system</title>
<fixtext>
Create a file system for <h:code>/home</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1">
<title>/var/tmp is a separate file system</title>
<fixtext>
Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in
the <h:code>/etc/fstab</h:code> file and reboot the system.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain">
<title>Use a Hardened Toolchain</title>
<description>
<h:p>
When Gentoo is installed, use the hardened stages and hardened toolchain.
The hardened toolchain includes additional security patches, such as
support for non-executable program stacks and buffer overflow detection.
</h:p>
<h:ul>
<h:li>
<h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent
Code (PIC)</h:em> implements a memory hardening approach where the application
(or library), when loaded to memory, does not have hard requirements where in
memory it is loaded. Together with ASLR this makes it more difficult for exploits
to know at which memory region certain data will be available.
</h:li>
<h:li>
<h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas
to detect buffer overflow attacks, killing the application rather than effectively
having the overflow succeed.
</h:li>
</h:ul>
<h:p>
During installation, make sure that the <h:em>default</h:em> hardened
toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as
those are toolchains where specific settings are disabled. The
<h:code>-vanilla</h:code> one is a toolchain with no hardened patches.
</h:p>
<h:pre>
# <h:b>gcc-config -l</h:b>
[1] x86_64-pc-linux-gnu-4.4.5 *
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopie.gcc-config-ref
[4] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
[5] x86_64-pc-linux-gnu-4.4.5-hardenednossp
[6] x86_64-pc-linux-gnu-4.4.5-vanilla</h:pre>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0">
<title>The hardened toolchain is used</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened">
Use a hardened Gentoo profile and select the default compiler (not vanilla
nor any of the hardenedno* ones).
</fixtext>
<check system="http://open-scap.org/page/SCE">
<check-import import-name="stdout" />
<check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" />
</check>
</Rule>
</Group> <!-- installation-toolchain -->
</Group> <!-- installation -->
<Group id="xccdf_org.gentoo.dev.swift_group_system">
<title>System settings</title>
<description>
Within this chapter, the (recommended) settings that can be adjusted relatively easily
are presented, even when a Gentoo installation has already been performed. This is the
bulk of the security settings.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fs">
<title>File system related settings</title>
<description>
Servers and systems are about manipulating data. In this chapter, the security settings
for file systems are explained.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-mountoptions">
<title>Using no* mount options for the file systems</title>
<description>
<h:p>
Non-root file systems should be mounted with the <h:em>nodev</h:em> mount option.
This mount option ensures that device files are not allowed on these file systems
(and if they are there, they are ignored by the Linux kernel for any device
operation).
</h:p>
<h:p>
Having device files on non-root file systems could allow unauthorized people access
to sensitive data (for instance when having a readable raw disk device files) or
even manipulate the system.
</h:p>
<h:p>
The privilege to create special device files (beyond regular sockets) such as
character and block device files is handled through the CAP_MKNOD capability
which is not granted to regular users. As such, the risk is when more privileged
users or processes are tricked to create such device files.
</h:p>
<h:p>
This setting is appropriate for file systems such as (non-exhaustive list):
</h:p>
<h:ul>
<h:li>
<h:code>/var</h:code> (as it is recommended to be a separate file system)
</h:li>
<h:li>
<h:code>/var/log</h:code> (as it is recommended to be a separate file system)
</h:li>
<h:li>
<h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system)
</h:li>
<h:li>
<h:code>/home</h:code> (as it is recommended to be a separate file system)
</h:li>
<h:li>
<h:code>/tmp</h:code> (as it is recommended to be a separate file system)
</h:li>
</h:ul>
<h:p>
Specific file systems should also be mounted with the <h:em>nosuid</h:em> mount
option. This prevents setuid binaries to run as a different user when hosted
on this file system. As there are several locations where setuid binaries might
be needed, this only affects particular file systems:
</h:p>
<h:ul>
<h:li>
The <h:code>/tmp</h:code> file system should not be used for setuid binaries
as this is a world-writable location and often target storage for attacks.
</h:li>
<h:li>
The <h:code>/home</h:code> file system should not be used for setuid binaries
as this is the home location for non-root users.
</h:li>
<h:li>
The <h:code>/dev/shm</h:code> file system should not be used for any binaries
(shared memory region).
</h:li>
</h:ul>
<h:p>
Specific file systems should also be mounted with the <h:em>noexec</h:em> mount
option. This prevents some automated attacks to execute certain payload (exploits)
from these locations.
</h:p>
<h:p>
This is just one of the many "layers" though, as executing payload can still be
done using different methods. For instance, scripts can be invoked through the
shell itself (rather than directly) and in the past, binaries could even be
executed through the <h:code>ld-linux.so</h:code> binary (although this has
been fixed).
</h:p>
<h:p>
File systems for which <h:em>noexec</h:em> is recommended are:
</h:p>
<h:ul>
<h:li>
The <h:code>/tmp</h:code> file system as it is a popular target to store exploit
code in.
</h:li>
<h:li>
The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory
location and is becoming a popular target to store exploit code in.
</h:li>
</h:ul>
</description>
<!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs
to be created first and is then only exploitable after local access.
Multiple authentication (one to create device file, one to log on)
-->
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9">
<title>/var is mounted with nodev</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9">
<title>/var/log is mounted with nodev</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var/log
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9">
<title>/var/log/audit is mounted with nodev</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var/log/audit
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9">
<title>/home is mounted with nodev</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /home
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" />
</check>
</Rule>
<!-- Higher severity due to more best practices and world writeable,
also more likely that exploit of process is done towards /tmp -->
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9">
<title>/tmp is mounted with nodev</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /tmp
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9">
<title>/tmp is mounted with nosuid</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /tmp
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9">
<title>/home is mounted with nosuid</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /home
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9">
<title>/dev/shm is mounted with nosuid</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /dev/shm
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" />
</check>
</Rule>
<!-- Weight is 0 as this is a means to exploit, not exploitable by
itself -->
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0">
<title>/tmp is mounted with noexec</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,noexec /tmp
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0">
<title>/dev/shm is mounted with noexec</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,noexec /dev/shm
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" />
</check>
</Rule>
</Group> <!-- system-fs-mountoptions -->
<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas">
<title>Disk quota support</title>
<description>
<h:p>
Most file systems support the notion of <h:em>quotas</h:em> - limits
on the amount of data / files that are allowed on that particular file system.
</h:p>
<h:p>
To enable quotas, first configure the Linux kernel to include
<h:code>CONFIG_QUOTA</h:code>.
</h:p>
<h:p>
Next, install the <h:code>sys-fs/quota</h:code> package.
</h:p>
<h:pre>
# <h:b>emerge quota</h:b></h:pre>
<h:p>
Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be
enabled on. For instance, the following snippet from
<h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code>
and <h:code>/home</h:code>.
</h:p>
<h:pre>
/dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b> 0 0
/dev/mapper/volgrp-var /var ext4 noatime,<h:b>usrquota,grpquota</h:b> 0 0</h:pre>
<h:p>
Finally, add the <h:code>quota</h:code> service to the boot runlevel.
</h:p>
<h:pre>
# <h:b>rc-update add quota boot</h:b></h:pre>
<h:p>
Reboot the system so that the partitions are mounted with the correct
mount options and that the quota service is running. Then the quotas for
users and groups can be set up.
</h:p>
</description>
<reference
href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing
Disk Usage with Quotas (LinuxHomeNetworking)</reference>
<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference>
<Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7">
<title>The kernel supports quota (CONFIG_QUOTA)</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="false" severity="low" weight="1.7">
<title>The /var file system is mounted with usrquota or grpquota</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_var-quota">Mount /var with usrquota and/or grpquota</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-quota"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,usrquota,grpquota /var
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:25" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="false" severity="low" weight="1.7">
<title>The /home file system is mounted with usrquota or grpquota</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_home-quota">Mount /home with usrquota and/or grpquota</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-quota"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,usrquota,grpquota /home
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:26" href="gentoo-oval.xml" />
</check>
</Rule>
</Group> <!-- system-fs-quotas -->
<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-hidepid">
<title>Hiding process information through hidepid</title>
<description>
<h:p>
In order to hide process information from other users, the <h:code>/proc</h:code> file system needs to be
mounted with the <h:code>hidepid</h:code> option. With value 0, the default behavior is used, meaning that
all process information is world readable.
</h:p>
<h:p>
When the value 1 is passed, the process information is not readable, but process directories are still shown
in the <h:code>/proc</h:code> mount. In order to truly hide this information, pass on the value 2.
</h:p>
<h:p>
In order to allow a particular group of people to see other people's processes, the <h:code>gid=</h:code>
option can be used to exempt this group from the PID hiding.
</h:p>
</description>
<reference href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201">Kernel commit introducing
the hidepid support</reference>
</Group>
</Group> <!-- system-fs -->
<Group id="xccdf_org.gentoo.dev.swift_group_system-services">
<title>System services</title>
<description>
<h:p>
Services (daemons) are the primary reason for a server to exist.
They represent the function of the server. For instance, a web server
will run the apache2 or lighttpd service. A name server will run the
named service.
</h:p>
<h:p>
In this benchmark, the focus is on a limited set of system services. For
the other services it is wise to consult other hardening guides specific
for those services.
</h:p>
</description>
<reference href="http://www.cisecurity.org">Center for Internet Security,
host of many service benchmarks</reference>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable">
<title>Disable unsafe services</title>
<description>
<h:p>
It is recommended to disable (or even uninstall) the following services unless
absolutely necessary. These services use plain-text protocols and are as such unsafe
to use on (untrusted) networks.
</h:p>
<h:ul>
<h:li>Telnet service</h:li>
<h:li>FTP Service</h:li>
</h:ul>
<h:p>
It is recommended to substitute these services with their more secure
counterparts (like sFTP, SSH, ...).
</h:p>
</description>
<!-- Max score: password in clear text and your system is compromised (if it is root) -->
<Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0">
<title>No telnet daemons are running</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
for service in /etc/init.d/*telnet*;
do
test -f ${service} && run_init rc-service ${service##*/} stop;
done
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" />
</check>
</Rule>
<!-- Partial breach, assuming accounts are not system accounts -->
<Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5">
<title>No FTP daemons are running</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
for service in /etc/init.d/*ftp*;
do
test -f ${service} && run_init rc-service ${service##*/} stop;
done
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin">
<title>Require single-user boot to give root password</title>
<description>
<h:p>
When a system is booted in single user mode, some users might find it
handy to immediately get a root prompt; many even have a specific
bootloader entry to boot in single user mode.
</h:p>
<h:p>
It is important that, for a more secure server environment, even
booting in single user mode requires the user to enter the root
password. This is already done by default in Gentoo through the
<h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>.
</h:p>
<h:p>
Administrators should also make sure that no direct shells are provided
in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's
<h:code>/etc/inittab</h:code> definition should look like so:
</h:p>
<h:pre>
su0:S:wait:/sbin/rc single
<h:b>su1:S:wait:/sbin/sulogin</h:b></h:pre>
</description>
<!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) -->
<Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0">
<title>sulogin is used for single-user boot (/etc/rc.conf)</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext>
<fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin"
system="urn:xccdf:fix:system:commands"
platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0">
<title>sulogin is used for single-user boot (/etc/inittab)</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin">
Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers">
<title>Properly Configure TCP Wrappers</title>
<description>
<h:p>
With TCP wrappers, services that support TCP wrappers (or those
started through <h:b>xinetd</h:b>) should be configured to only accept
communication with trusted hosts. With the use of
<h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>,
proper access control lists can be created.
</h:p>
<h:p>
More information on the format of these files can be obtained through
<h:b>man 5 hosts_access</h:b>.
</h:p>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0">
<title>/etc/hosts.allow exists</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists">
Create and properly configure /etc/hosts.allow
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh">
<title>SSH service</title>
<description>
<h:p>
The SSH service is used for secure remote access towards a system, but
also to provide secure file transfers. It is very commonly found on Unix/Linux
systems so proper hardening is definitely in place.
</h:p>
<h:p>
Please use the "Hardening OpenSSH" guide for the necessary instructions.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron">
<title>Cron service</title>
<description>
A cron service is used to schedule tasks and processes on predefined
times. Cron is most often used for regular maintenance tasks.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl">
<title>Only allow trusted accounts cron access</title>
<description>
<h:p>
Only allow trusted accounts to use cron. How to achieve this depends on the cron service
installed.
</h:p>
<h:p>
If vixie-cron or cronie is installed, then have (only) those users that need cron access
take part in the <h:em>cron</h:em> unix group.
</h:p>
<h:p>
If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by
root and the cron unix group, and make sure (only) those users that need cron access take part
in the <h:em>cron</h:em> unix group.
</h:p>
</description>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at">
<title>At service</title>
<description>
The at service allows users to execute a task once on a given time.
Unlike cron, this is not scheduled repeatedly - once executed, the
task is considered completed and at will not invoke it again.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl">
<title>Only allow trusted accounts at access</title>
<description>
<h:p>
Only allow trusted accounts to use at. Unlike cron access, at access is governed through
the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not
exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in
the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code>
method.
</h:p>
<h:p>
The format of these files is one username per line.
</h:p>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0">
<title>/etc/at/at.allow exists</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists">
Create and properly configure /etc/at/at.allow
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp">
<title>NTP service</title>
<description>
<h:p>
With NTP, systems can synchronise their clocks, ensuring correct date
and time information. This is important as huge clock drift could
cause misinterpretation of log files or even unwanted execution of
commands.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync">
<title>Synchronise the system clock</title>
<description>
<h:p>
Synchronise the systems' clock with an authorative NTP server, and
use the same NTP service for all other systems.
</h:p>
<h:p>
This can be accomplished by regularly executing <h:b>ntpdate</h:b>,
but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s
<h:b>ntpd</h:b>.
</h:p>
</description>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog">
<title>Syslog service</title>
<description>
<h:p>
The system logger handles all non-audit related logging generated by applications
and daemons. In order to ensure proper forensic analysis if it would ever be needed,
the system logger should be properly configured.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-logintervals">
<title>Configure the system logger to log intervals</title>
<description>
<h:p>
Have the system logger log every 10 minutes or so. Without interval logging,
administrators might think nothing is wrong although in reality the system
logger is malfunctioning and not writing any log events.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-remotelogging">
<title>Enable remote logging</title>
<description>
<h:p>
If possible, have vital (or all) logs sent to a remote system logger as well.
In home deployments, off-the-shelf (wifi) routers often have a logging daemon
that can receive syslog events. For larger environments, a dedicated centralized
log server is recommended.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-terminal">
<title>Decide which events to send to user terminals</title>
<description>
<h:p>
On Linux and Unix systems, events can be sent to user terminals to
make those users immediately aware of what is happening. It is
recommended to send emergency-level events to everyone and have
alerts sent to specific administrative user terminals.
</h:p>
</description>
</Group>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-portage">
<title>Portage settings</title>
<description>
<h:p>
The package manager of any system is a very important tool. It is
responsible for handling proper software deployments, but also offers
features that should not be neglected, like security patch roll-out.
</h:p>
<h:p>
For Gentoo, the package manager offers a great deal of flexibility (as
that is the goal of Gentoo anyhow). As such, good settings for a more
secure environment within Portage (assuming that Portage is used as
package manager) are important.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use">
<title>USE flags</title>
<description>
<h:p>
USE flags in Gentoo are used to tune the functionality of many
components and enable or disable features.
</h:p>
<h:p>
For a well secured environment, there are a couple of USE flags that
should be set in a global manner. These USE flags are
</h:p>
<h:ul>
<h:li>
<h:code>pam</h:code> to enable Pluggable Authentication
Modules support
</h:li>
<h:li>
<h:code>tcpd</h:code> for TCP wrappers support
</h:li>
<h:li>
<h:code>ssl</h:code> for SSL/TLS support
</h:li>
</h:ul>
<h:p>
<h:b>Pluggable Authentication Modules</h:b> are a powerful mechanism
to manage authentication, authorization and user sessions.
Applications that support PAM can be tuned to the liking of the
organization, leveraging central authentication, password policies,
auditing and more.
</h:p>
<h:p>
With <h:b>TCP wrappers</h:b>, services can be shielded from
unauthorized access on host level. It is an access control level
mechanism which allows configuring allowed (and denied) hosts or
network segments on application level.
</h:p>
<h:p>
Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the
standardized <h:b>Transport Layer Security</h:b>) allows applications
to encrypt network communication or even implement a
client-certificate based authentication mechanism.
</h:p>
<h:p>
Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code>
so they are applicable to all installed software.
</h:p>
<h:pre>
USE="... pam tcpd ssl"</h:pre>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="false" severity="low" weight="0.0">
<title>USE="pam" is set</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-pam">
Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:27" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="false" severity="low" weight="0.0">
<title>USE="tcpd" is set</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-tcpd">
Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:28" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="false" severity="low" weight="0.0">
<title>USE="ssl" is set</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-ssl">
Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:29" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync">
<title>Fetching signed portage tree</title>
<description>
<h:p>
Gentoo Portage supports fetching signed tree snapshots using
<h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook,
but as it is quite easy, here are the instructions again:
</h:p>
<h:pre>
# <h:b>mkdir -p /etc/portage/gpg</h:b>
# <h:b>chmod 0700 /etc/portage/gpg</h:b>
# <h:b>export SRV="subkeys.pgp.net"</h:b>
# <h:b>export KEY="0x96D8BF6D"</h:b>
# <h:b>gpg --homedir /etc/portage/gpg --keyserver ${SRV} --recv-keys ${KEY}</h:b>
# <h:b>gpg --homedir /etc/portage/gpg --edit-key ${KEY} trust</h:b></h:pre>
<h:p>
After this, edit <h:code>/etc/portage/make.conf</h:code>:
</h:p>
<h:pre>
FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/etc/portage/gpg"
</h:pre>
<h:p>
In the repository configuration (<h:code>/etc/portage/repos.conf</h:code> or a
file inside it) <h:code>sync-uri</h:code> has to be commented out, or set to an
empty value.
</h:p>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="false" severity="low" weight="0.0">
<title>FEATURES="webrsync-gpg" is set</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_FEATURES-webrsync-gpg">
Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:30" href="gentoo-oval.xml" />
</check>
</Rule>
<Rule id="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="false" severity="low" weight="0.0">
<title>PORTAGE_GPG_DIR is set</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_PORTAGE_GPG_DIR-nonempty">
Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:31" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-kernel">
<title>Kernel configuration</title>
<description>
<h:p>
The Linux kernel should be configured using a sane security standard in
mind. When using grSecurity, additional security-enhancing settings can
be enabled.
</h:p>
<h:p>
For further details, please refer to the "Hardening the Linux kernel" guide.
</h:p>
</description>
<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader">
<title>Bootloader configuration</title>
<description>
<h:p>
The bootloader (be it GRUB or another tool) is responsible for loading
the Linux kernel and handing over system control to the kernel. But boot
loaders also allow for a flexible approach on kernel loading, which can
be (ab)used to work around security mechanisms.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub2pass">
<title>Password protect GRUB 2</title>
<description>
<h:p>
It is recommended to password-protect the GRUB configuration so that the
boot options cannot be modified during a boot without providing the valid
password.
</h:p>
<h:p>
TODO looks like this has become a lot more difficult to obtain
</h:p>
</description>
<reference href="https://help.ubuntu.com/community/Grub2/Passwords">GRUB2 Passwords (Ubuntu wiki)</reference>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass">
<title>Password protect GRUB (legacy)</title>
<description>
<h:p>
It is recommended to password-protect the GRUB configuration so that
the boot options cannot be modified during a boot without providing the
valid password.
</h:p>
<h:p>
This can be accomplished by inserting <h:code>password abc123</h:code>
in <h:code>/boot/grub/grub.conf</h:code> (which will set the password
to "abc123"). But as clear-text passwords in the configuration file are insecure as well,
hash the passwords. Just start <h:b>grub</h:b>
and, in the grub-shell, type <h:b>md5crypt</h:b>.
</h:p>
<h:pre>
# <h:b>grub</h:b>
GRUB version 0.92 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. ... ]
grub> <h:b>md5crypt</h:b>
Password: <h:em>abc123</h:em>
Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
grub> <h:b>quit</h:b></h:pre>
<h:p>
This hashed password can now be used in <h:code>grub.conf</h:code>
using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass">
<title>Password protect LILO</title>
<description>
<h:p>
It is recommended to password-protect the LILO configuration so that
modifying the boot options during a boot without providing the
valid password is not possible.
</h:p>
<h:p>
This can be accomplished by inserting <h:code>password=abc123</h:code>
followed by <h:code>restricted</h:code> in the
<h:code>/etc/lilo.conf</h:code> file. It is also possible to do this
on a per-image level.
</h:p>
<h:pre>
password=abc123
restricted
delay=3
image=/boot/bzImage
read-only
password=def456
restricted</h:pre>
<h:p>
The <h:code>restricted</h:code> keyword is needed to have LILO only
ask for the password if a modification is given. If the defaults are
used, then no password needs to be provided.
</h:p>
<h:p>
Rerun <h:code>lilo</h:code> after updating the configuration file.
</h:p>
</description>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth">
<title>Authentication and authorization settings</title>
<description>
<h:p>
An important part in a servers' security is its authentication and
authorization support. We have already described how to build in PAM
support (through the Portage USE flags), but proper authentication and
authorization settings are mode than just compiling in the necessary
functionality.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty">
<title>Restrict root system logon</title>
<description>
<h:p>
To restrict where the root user can directly log on, edit
<h:code>/etc/securetty</h:code> and specify the supported terminals
for the root user.
</h:p>
<h:p>
When properly configured, any attempt to log on as the root user from
a non-defined terminal will result in logon failure.
</h:p>
<h:p>
A recommended setting is to only allow root user login through the
console and the physical terminals (<h:code>tty0-tty12</h:code>).
</h:p>
<h:pre>
console
tty0
tty1
...
tty12</h:pre>
</description>
<Rule id="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="false" severity="low" weight="0.0">
<title>/etc/securetty is limited to console and tty's</title>
<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_securetty-limitentries">
Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined.
</fixtext>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-content-ref name="oval:org.gentoo.dev.swift:def:32" href="gentoo-oval.xml" />
</check>
</Rule>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin">
<title>Allow only known users to login</title>
<description>
<h:p>
When PAM is enabled, the <h:code>/etc/security/access.conf</h:code>
file is used to check which users are allowed to log on and not
(through the <h:b>login</h:b> application). These limits are based on
username, group and host, network or tty that the user is trying to
log on from.
</h:p>
<h:p>
By enabling these settings, the risk is reduced that a functional
account (say <h:code>apache</h:code>) is abused to log on with, or
that a new account is created as part of an exploit.
</h:p>
<h:p>
The following example setting allows only local root logins on tty1,
and only the <h:em>swift</h:em> account to log on on the system.
</h:p>
<h:pre>
+ : root : tty1
- : ALL EXCEPT swift : ALL
</h:pre>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources">
<title>Restrict user resources</title>
<description>
<h:p>
When facing a DoS (Denial-of-Service) attack, reducing the impact of
the attack can be done by limited resource consumption. Although the
component that is under attack will even more quickly fail, the impact
towards the other services on the system (including remote logon to
fix things) is more limited.
</h:p>
<h:p>
In Gentoo Linux, the following methods are available to limit
resources.
</h:p>
<h:ul>
<h:li>
<h:code>/etc/security/limits.conf</h:code> defines the
resource limits for logins that are done through a PAM-aware
component (default in our setup)
</h:li>
<h:li>
<h:code>/etc/limits</h:code> defines the resource limits for
logins that are done through login programs that are not
PAM-aware.
</h:li>
</h:ul>
<h:p>
Generally, it should suffice to set up
<h:code>/etc/security/limits.conf</h:code>, which is the configuration
file used by the <h:code>pam_limits.so</h:code> module.
</h:p>
<h:p>
Note that the settings are applicable on a <h:em>per login
session</h:em> basis.
</h:p>
<h:p>
More information on these files and their syntax can be obtained
through their manual pages.
</h:p>
<h:pre>
# <h:b>man limits.conf</h:b>
# <h:b>man limits</h:b></h:pre>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password">
<title>Enforce password policy</title>
<description>
<h:p>
Usually most organizations have a password policy, telling their users
how long their passwords should be and how often the passwords should
be changed. Most users see this as an annoying aspect, so it might be
best to enforce this policy.
</h:p>
<h:p>
Enforcing password policies is (partially) part of the
<h:code>sys-apps/shadow</h:code> package (which is installed by
default) and can be configured through the
<h:code>/etc/login.defs</h:code> file. This file is well documented
(using comments) and it has a full manual page as well.
</h:p>
<h:p>
A second important player when dealing with password policies is the
<h:code>pam_cracklib.so</h:code> library. This can be used in the
appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the
<h:code>/etc/pam.d/passwd</h:code> definition:
</h:p>
<h:pre>
auth required pam_unix.so shadow nullok
account required pam_unix.so
<h:b>password required pam_cracklib.so difok=3 retry=3 \
minlen=8 dcredit=-2 \
ocredit=-2</h:b>
password required pam_unix.so md5 use_authok
session required pam_unix.so</h:pre>
<h:p>
In the above example, the password is required to be at least 8
characters long, differ more than 3 characters from the previous
password, contain 2 digits and 2 non-alphanumeric characters.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper">
<title>Review password strength regularly</title>
<description>
<h:p>
Regularly check the strength of the users' passwords. There are tools
out there, like <h:code>app-crypt/johntheripper</h:code> which, given
a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try
to find the passwords for the users.
</h:p>
<h:p>
When such a tool can guess a users' password, that users' password
should be expired and the user should be notified and asked to change
his password.
</h:p>
</description>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-session">
<title>Session settings</title>
<description>
<h:p>
Unlike authentication and authorization settings, a <h:em>session</h:em>
setting is one that is applicable to an authenticated and authorized
user when he is logged on to the system.
</h:p>
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg">
<title>Disable access to user terminals</title>
<description>
<h:p>
By default, user terminals are accessible by others to write messages
to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is
adviseable to disable this unless explicitly necessary.
</h:p>
<h:p>
Messages can confuse users and trick them into performing malicious
actions.
</h:p>
<h:p>
This can be disabled by setting <h:code>mesg n</h:code> in
<h:code>/etc/profile</h:code>. A user-friendly method for doing so in
Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which
contains this command.
</h:p>
</description>
</Group>
</Group>
<Group id="xccdf_org.gentoo.dev_group_system-fileprivileges">
<title>File and directory privileges and integrity</title>
<description>
Proper privileges on files makes it far more difficult to malicious
users to obtain sensitive information or write/update files they should
not have access to.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw">
<title>Limit world writable files and locations</title>
<description>
<h:p>
Limit (or even remove) the use of world writable files and locations.
If a directory is world writable, it makes sense to have the
sticky bit set on it as well (like with <h:code>/tmp</h:code>).
</h:p>
<h:p>
Use <h:code>find</h:code> to locate such files or directories.
</h:p>
<h:pre>
# <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
<h:p>
The above command shows world writable files and locations, unless it
is a directory with the sticky bit set, or a symbolic link (whose
world writable privilege is not accessible anyhow).
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid">
<title>Limit setuid and setgid file and directory usage</title>
<description>
<h:p>
The <h:em>setuid</h:em> and <h:em>setgid</h:em> flags for files and
directories can be used to work around authentication and
authorization measures taken on the system. So their use should be
carefully guarded.
</h:p>
<h:p>
In case of files, the setuid or setgid bit causes the application (if
the file is marked as executable) to run with the privileges of the
file owner (setuid) or group owner (setgid). It is necessary for
applications that need elevated privileges, like <h:b>su</h:b> or
<h:b>sudo</h:b>.
</h:p>
<h:p>
In case of directories, the setgit bit causes newly created
files in that directory to automatically be owned by the same group as
the mentioned (parent) directory.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-caps">
<title>Limit capability enabled files</title>
<description>
<h:p>
Capabilities within Linux allow users to perform certain privileged tasks.
</h:p>
<h:p>
Unlike <h:em>setuid</h:em> flags, the allowed privileges can be defined
in a more granular approach (although one can still add in all possible
capabilities and thus gain similar privileges as through <h:em>setuid</h:em>
binaries).
</h:p>
<h:p>
Files with particular capabilities set (through the <h:b>setcap</h:b>
application) should be regularly reviewed. Capability-enabled files
can be found through the following command:
</h:p>
<h:pre>
# <h:b>getcap -r /</h:b>
</h:pre>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs">
<title>Logs only readable by proper group</title>
<description>
No log file in <h:code>/var/log</h:code> should be world readable. Log
files should be limited by particular groups (either the group
representing the service, like <h:code>apache</h:code> or
<h:code>portage</h:code>, or a specific administrative group like
<h:code>wheel</h:code>).
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly">
<title>Files only used by root should be root-only</title>
<description>
<h:p>
Some files, like <h:code>/etc/shadow</h:code>, are meant to be read
(and perhaps modified) by root only. These files should never have
privileges for group- or others.
</h:p>
<h:p>
A nonexhaustive list of such files is:
</h:p>
<h:ul>
<h:li>
<h:code>/etc/shadow</h:code> which contains account password
information (including password hashes)
</h:li>
<h:li>
<h:code>/etc/securetty</h:code> which contains the list of
terminals where root is allowed to log on from
</h:li>
</h:ul>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids">
<title>Review file integrity regularly</title>
<description>
Deploy intrusion detection tool(s) to validate the integrity and
privileges on important files. <h:code>app-forensics/aide</h:code> is
an example of such a tool.
</description>
</Group>
</Group>
</Group> <!-- system -->
<Group id="xccdf_org.gentoo.dev.swift_group_data">
<title>Data flows</title>
<description>
Clearly map out how data flows in and out of the server (and which data
this is). This will be needed anyhow when firewalls are configured, but it
also improves integration of the server in a larger infrastructure.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backup">
<title>Backup the data</title>
<description>
Make sure that the data is backed up. This is not only in case of
server loss, but also to protect against accidental file removal or an
awkward bug in a service that deleted important information.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate">
<title>Automated backups</title>
<description>
<h:p>
Automate backups on the system. If the backups are performed manually
then they are done wrong and someone will eventually forget it.
</h:p>
<h:p>
Use scheduling software like <h:code>cron</h:code> to
automatically take backups on regular intervals, or use a central
backup solution like <h:code>bacula</h:code>.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage">
<title>Full data coverage</title>
<description>
Many users that do take backups only do this on what they seem as
important files. However, it is wise to make full system backups too
as recreating an entire system from scratch could otherwise take days
or even weeks.
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history">
<title>Retention</title>
<description>
<h:p>
Ensure that the backups use a long enough retention. It is not wise
to take a single backup and overwrite this one over and over again, as
there will be a time that a file needs to be recovered that was corrupted
long before the last backup was taken.
</h:p>
<h:p>
There is no perfect retention period however, as the more backups are
kept, the more storage is required and the more money or time needs to be invested in
managing the backups.
</h:p>
<h:p>
In most cases, introduce a "layered" approach on retention. For instance:
</h:p>
<h:ul>
<h:li>keep daily backups for a week</h:li>
<h:li>
keep weekly backups (say each monday backup) for a month
</h:li>
<h:li>
keep monthly backups (say each first monday) for a year
</h:li>
<h:li>
keep yearly backups for 30 years
</h:li>
</h:ul>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location">
<title>Off-site backups</title>
<description>
<h:p>
Keep the backups off-site in case of disaster. But consider this
location carefully. Investigate how fast the backup can be put there,
but also how fast it can be retrieved it in case of need. Also investigate if this
location is juridically sane (is it allowed to put the data on this location
and is this off-site location trusted).
</h:p>
<h:p>
Also ensure that the backups are stored securely. If necessary,
encrypt the backups.
</h:p>
</description>
</Group>
<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate">
<title>Validate and test</title>
<description>
Validate that the backup system works. Try recovering files (for
instance on a second server or different location) or even entire
systems (virtualization is a great help here) and do this regularly.
</description>
</Group>
</Group>
</Group> <!-- Data flows -->
<Group id="xccdf_org.gentoo.dev.swift_group_removal">
<title>Decommissioning servers</title>
<description>
When a server needs to be decommissioned, make sure that its data
is safeguarded from future extraction.
</description>
<Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk">
<title>Wipe disks</title>
<description>
<h:p>
Clear all data from the disks on the server in a secure manner.
Applications like <h:b>shred</h:b> (part of
<h:code>sys-apps/coreutils</h:code>) can be used to security wipe data
or even entire partitions or disks.
</h:p>
<h:p>
It is recommended to perform full disk wipes rather than file wipes.
If this needs to be done on file level, see if the file system
journaling can be disabled during the wipe session as journaling might "buffer" the
secure writes and only write the end result to the disk.
</h:p>
</description>
<reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference>
</Group>
</Group> <!-- Removal -->
</Benchmark>
|