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
|
[ Note: the installation instructions in this document are somewhat
out of date - the package now uses GNU autoconf and is configured
just like most GNU packages: run ./configure then make. --marekm ]
Linux Shadow Password HOWTO
Michael H. Jackson, mhjack@tscnet.com
v1.3, 3 April 1996
This document aims to describe how to obtain, install, and configure
the Linux password Shadow Suite. It also discusses obtaining, and
reinstalling other software and network daemons that require access to
user passwords. This other software is not actually part of the
Shadow Suite, but these programs will need to be recompiled to support
the Shadow Suite. This document also contains a programming example
for adding shadow support to a program. Answers to some of the more
frequently asked questions are included near the end of this document.
1. Introduction.
This is the Linux Shadow-Password-HOWTO. This document describes why
and how to add shadow password support on a Linux system. Some
examples of how to use some of the Shadow Suite's features is also
included.
When installing the Shadow Suite and when using many of the utility
programs, you must be logged in as root. When installing the Shadow
Suite you will be making changes to system software, and it is highly
recommended that you make backup copies of programs as indicated. I
also recommend that you read and understand all the instructions
before you begin.
1.1. Changes from the previous release.
Additions:
Added a sub-section on why you might not want to install shadow
Added a sub-section on updating the xdm program
Added a section on how to put Shadow Suite features to work
Added a section containing frequently asked questions
Corrections/Updates:
Corrected html references on Sunsite
Corrected section on wu-ftp to reflect adding -lshadow to the Makefile
Corrected minor spelling and verbiage errors
Changed section on wu-ftpd to support ELF
Updated to reflect security problems in various login programs
Updated to recommend the Linux Shadow Suite by Marek Michalkiewicz
1.2. New versions of this document.
The latest released version of this document can always be retrieved
by anonymous FTP from:
sunsite.unc.edu
/pub/Linux/docs/HOWTO/Shadow-Password-HOWTO
or:
/pub/Linux/docs/HOWTO/other-formats/Shadow-Password-HOWTO{-html.tar,ps,dvi}.gz
or via the World Wide Web from the Linux Documentation Project Web
Server <http://sunsite.unc.edu/mdw/linux.html>, at page: Shadow-
Password-HOWTO <http://sunsite.unc.edu/linux/HOWTO/Shadow-Password-
HOWTO.html> or directly from me, <mhjack@tscnet.com>. It will also be
posted to the newsgroup: comp.os.linux.answers
This document is now packaged with the Shadow-YYDDMM packages.
1.3. Feedback.
Please send any comments, updates, or suggestions to me: Michael H.
Jackson <mhjack@tscnet.com> The sooner I get feedback, the sooner I
can update and correct this document. If you find any problems with
it, please mail me directly as I very rarely stay up-to-date on the
newsgroups.
2. Why shadow your passwd file?
By default, most current Linux distributions do not contain the Shadow
Suite installed. This includes Slackware 2.3, Slackware 3.0, and
other popular distributions. One of the reasons for this is that the
copyright notices in the original Shadow Suite were not clear on
redistribution if a fee was charged. Linux uses a GNU Copyright
(sometimes refereed to as a Copyleft) that allows people to package it
into a convenient package (like a CD-ROM distribution) and charge a
fee for it.
The current maintainer of the Shadow Suite, Marek Michalkiewicz
<marekm@i17linuxb.ists.pwr.wroc.pl> received the source code from the
original author under a BSD style copyright that allowed
redistribution. Now that the copyright issues are resolved, it is
expected that future distributions will contain password shadowing by
default. Until then, you will need to install it yourself.
If you installed your distribution from a CD-ROM, you may find that,
even though the distribution did not have the Shadow Suite installed,
some of the files you need to install the Shadow Suite may be on the
CD-ROM.
However, Shadow Suite versions 3.3.1, 3.3.1-2, and shadow-mk all have
security problems with their login program and several other suid root
programs that came with them, and should no longer be used.
All of the necessary files may be obtained via anonymous FTP or
through the World Wide Web.
On a Linux system without the Shadow Suite installed, user information
including passwords is stored in the /etc/passwd file. The password
is stored in an encrypted format. If you ask a cryptography expert,
however, he or she will tell you that the password is actually in an
encoded rather than encrypted format because when using crypt(3), the
text is set to null and the password is the key. Therefore, from here
on, I will use the term encoded in this document.
The algorithm used to encode the password field is technically
referred to as a one way hash function. This is an algorithm that is
easy to compute in one direction, but very difficult to calculate in
the reverse direction. More about the actual algorithm used can be
found in section 2.4 or your crypt(3) manual page.
When a user picks or is assigned a password, it is encoded with a
randomly generated value called the salt. This means that any
particular password could be stored in 4096 different ways. The salt
value is then stored with the encoded password.
When a user logs in and supplies a password, the salt is first
retrieved from the stored encoded password. Then the supplied
password is encoded with the salt value, and then compared with the
encoded password. If there is a match, then the user is
authenticated.
It is computationally difficult (but not impossible) to take a
randomly encoded password and recover the original password. However,
on any system with more than just a few users, at least some of the
passwords will be common words (or simple variations of common words).
System crackers know all this, and will simply encrypt a dictionary of
words and common passwords using all possible 4096 salt values. Then
they will compare the encoded passwords in your /etc/passwd file with
their database. Once they have found a match, they have the password
for another account. This is referred to as a dictionary attack, and
is one of the most common methods for gaining or expanding
unauthorized access to a system.
If you think about it, an 8 character password encodes to 4096 * 13
character strings. So a dictionary of say 400,000 common words,
names, passwords, and simple variations would easily fit on a 4GB hard
drive. The attacker need only sort them, and then check for matches.
Since a 4GB hard drive can be had for under $1000.00, this is well
within the means of most system crackers.
Also, if a cracker obtains your /etc/passwd file first, they only need
to encode the dictionary with the salt values actually contained in
your /etc/passwd file. This method is usable by your average teenager
with a couple of hundred spare Megabytes and a 486 class computer.
Even without lots of drive space, utilities like crack(1) can usually
break at least a couple of passwords on a system with enough users
(assuming the users of the system are allowed to pick their own
passwords).
The /etc/passwd file also contains information like user ID's and
group ID's that are used by many system programs. Therefore, the
/etc/passwd file must remain world readable. If you were to change
the /etc/passwd file so that nobody can read it, the first thing that
you would notice is that the ls -l command now displays user ID's
instead of names!
The Shadow Suite solves the problem by relocating the passwords to
another file (usually /etc/shadow). The /etc/shadow file is set so
that it cannot be read by just anyone. Only root will be able to read
and write to the /etc/shadow file. Some programs (like xlock) don't
need to be able to change passwords, they only need to be able to
verify them. These programs can either be run suid root or you can
set up a group shadow that is allowed read only access to the
/etc/shadow file. Then the program can be run sgid shadow.
By moving the passwords to the /etc/shadow file, we are effectively
keeping the attacker from having access to the encoded passwords with
which to perform a dictionary attack.
Additionally, the Shadow Suite adds lots of other nice features:
� A configuration file to set login defaults (/etc/login.defs)
� Utilities for adding, modifying, and deleting user accounts and
groups
� Password aging and expiration
� Account expiration and locking
� Shadowed group passwords (optional)
� Double length passwords (16 character passwords) NOT RECOMMENDED
� Better control over user's password selection
� Dial-up passwords
� Secondary authentication programs NOT RECOMMENDED
Installing the Shadow Suite contributes toward a more secure system,
but there are many other things that can also be done to improve the
security of a Linux system, and there will eventually be a series of
Linux Security HOWTO's that will discuss other security measures and
related issues.
For current information on other Linux security issues, including
warnings on known vulnerabilities see the Linux Security home page.
<http://bach.cis.temple.edu/linux/linux-security/>
2.1. Why you might NOT want to shadow your passwd file.
There are a few circumstances and configurations in which installing
the Shadow Suite would NOT be a good idea:
� The machine does not contain user accounts.
� Your machine is running on a LAN and is using NIS (Network
Information Services) to get or supply user names and passwords to
other machines on the network. (This can actually be done, but is
beyond the scope of this document, and really won't increase
security much anyway)
� Your machine is being used by terminal servers to verify users via
NFS (Network File System), NIS, or some other method.
� Your machine runs other software that validates users, and there is
no shadow version available, and you don't have the source code.
2.2. Format of the /etc/passwd file
A non-shadowed /etc/passwd file has the following format:
username:passwd:UID:GID:full_name:directory:shell
Where:
username
The user (login) name
passwd
The encoded password
UID
Numerical user ID
GID
Numerical default group ID
full_name
The user's full name - Actually this field is called the GECOS
(General Electric Comprehensive Operating System) field and can
store information other than just the full name. The Shadow
commands and manual pages refer to this field as the comment
field.
directory
User's home directory (Full pathname)
shell
User's login shell (Full Pathname)
For example:
username:Npge08pfz4wuk:503:100:Full Name:/home/username:/bin/sh
Where Np is the salt and ge08pfz4wuk is the encoded password. The
encoded salt/password could just as easily have been kbeMVnZM0oL7I and
the two are exactly the same password. There are 4096 possible encod�
ings for the same password. (The example password in this case is
'password', a really bad password).
Once the shadow suite is installed, the /etc/passwd file would instead
contain:
username:x:503:100:Full Name:/home/username:/bin/sh
The x in the second field in this case is now just a place holder.
The format of the /etc/passwd file really didn't change, it just no
longer contains the encoded password. This means that any program
that reads the /etc/passwd file but does not actually need to verify
passwords will still operate correctly.
The passwords are now relocated to the shadow file (usually
/etc/shadow file).
2.3. Format of the shadow file
The /etc/shadow file contains the following information:
username:passwd:last:may:must:warn:expire:disable:reserved
Where:
username
The User Name
passwd
The Encoded password
last
Days since Jan 1, 1970 that password was last changed
may
Days before password may be changed
must
Days after which password must be changed
warn
Days before password is to expire that user is warned
expire
Days after password expires that account is disabled
disable
Days since Jan 1, 1970 that account is disabled
reserved
A reserved field
The previous example might then be:
username:Npge08pfz4wuk:9479:0:10000::::
2.4. Review of crypt(3).
From the crypt(3) manual page:
"crypt is the password encryption function. It is based on the Data
Encryption Standard algorithm with variations intended (among other
things) to discourage use of hardware implementations of a key search.
The key is a user's typed password. The encoded string is all NULLs
The salt is a two-character string chosen from the set a-zA-Z0-9./.
This string is used to perturb the algorithm in one of 4096 different
ways.
By taking the lowest 7 bits of each character of the key, a 56-bit key
is obtained. This 56-bit key is used to encrypt repeatedly a constant
string (usually a string consisting of all zeros). The returned value
points to the encrypted password, a series of 13 printable ASCII
characters (the first two characters represent the salt itself). The
return value points to static data whose content is overwritten by
each call.
Warning: The key space consists of 2**56 equal 7.2e16 possible values.
Exhaustive searches of this key space are possible using massively
parallel computers. Software, such as crack(1), is available which
will search the portion of this key space that is generally used by
humans for passwords. Hence, password selection should, at minimum,
avoid common words and names. The use of a passwd(1) program that
checks for crackable passwords during the selection process is
recommended.
The DES algorithm itself has a few quirks which make the use of the
crypt(3) interface a very poor choice for anything other than password
authentication. If you are planning on using the crypt(3) interface
for a cryptography project, don't do it: get a good book on encryption
and one of the widely available DES libraries."
Most Shadow Suites contain code for doubling the length of the
password to 16 characters. Experts in des recommend against this, as
the encoding is simply applied first to the left half and then to the
right half of the longer password. Because of the way crypt works,
this may make for a less secure encoded password then if double length
passwords were not used in the first place. Additionally, it is less
likely that a user will be able to remember a 16 character password.
There is development work under way that would allow the
authentication algorithm to be replaced with something more secure and
with support for longer passwords (specifically the MD5 algorithm) and
retain compatibility with the crypt method.
If you are looking for a good book on encryption, I recommend:
"Applied Cryptography: Protocols, Algorithms, and Source Code in C"
by Bruce Schneier <schneier@chinet.com>
ISBN: 0-471-59756-2
3. Getting the Shadow Suite.
3.1. History of the Shadow Suite for Linux
DO NOT USE THE PACKAGES IN THIS SECTION, THEY HAVE SECURITY PROBLEMS
The original Shadow Suite was written by Julianne F. Haugh
There are several versions that have been used on Linux systems:
� shadow-3.3.1 is the original.
� shadow-3.3.1-2 is Linux specific patch made by Florian La Roche
<flla@stud.uni-sb.de> and contains some further enhancements.
� shadow-mk was specifically packaged for Linux.
The shadow-mk package contains the shadow-3.3.1 package distributed by
Julianne F. Haugh with the shadow-3.3.1-2 patch installed, a few fixes
made by Mohan Kokal <magnus@texas.net> that make installation a lot
easier, a patch by Joseph R.M. Zbiciak for login1.c (login.secure)
that eliminates the -f, -h security holes in /bin/login, and some
other miscellaneous patches.
The shadow.mk package was the previously recommended package, but
should be replaced due to a security problem with the login program.
There are security problems with Shadow versions 3.3.1, 3.3.1-2, and
shadow-mk involving the login program. This login bug involves not
checking the length of a login name. This causes the buffer to
overflow causing crashes or worse. It has been rumored that this
buffer overflow can allow someone with an account on the system to use
this bug and the shared libraries to gain root access. I won't
discuss exactly how this is possible because there are a lot of Linux
systems that are affected, but systems with these Shadow Suites
installed, and most pre-ELF distributions without the Shadow Suite are
vulnerable!
For more information on this and other Linux security issues, see the
Linux Security home page (Shared Libraries and login Program
Vulnerability) <http://bach.cis.temple.edu/linux/linux-security/Linux-
Security-FAQ/Linux-telnetd.html>
3.2. Where to get the Shadow Suite.
The only recommended Shadow Suite is still in BETA testing, however
the latest versions are safe in a production environment and don't
contain a vulnerable login program.
The package uses the following naming convention:
shadow-YYMMDD.tar.gz
where YYMMDD is the issue date of the Suite.
This version will eventually be Version 3.3.3 when it is released from
Beta testing, and is maintained by Marek Michalkiewicz
<marekm@i17linuxb.ists.pwr.wroc.pl>. It's available as: shadow-
current.tar.gz
<ftp://i17linuxb.ists.pwr.wroc.pl/pub/linux/shadow/shadow-
current.tar.gz>.
The following mirror sites have also been established:
� ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz
� ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz
� ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz
� ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz
You should use the currently available version.
You should NOT use a version older than shadow-960129 as they also
have the login security problem discussed above.
When this document refers to the Shadow Suite I am referring to the
this package. It is assumed that this is the package that you are
using.
For reference, I used shadow-960129 to make these installation
instructions.
If you were previously using shadow-mk, you should upgrade to this
version and rebuild everything that you originally compiled.
3.3. What is included with the Shadow Suite.
The Shadow Suite contains replacement programs for:
su, login, passwd, newgrp, chfn, chsh, and id
The package also contains the new programs:
chage, newusers, dpasswd, gpasswd, useradd, userdel, usermod,
groupadd, groupdel, groupmod, groups, pwck, grpck, lastlog, pwconv,
and pwunconv
Additionally, the library: libshadow.a is included for writing and/or
compiling programs that need to access user passwords.
Also, manual pages for the programs are also included.
There is also a configuration file for the login program which will be
installed as /etc/login.defs.
4. Compiling the programs.
4.1. Unpacking the archive.
The first step after retrieving the package is unpacking it. The
package is in the tar (tape archive) format and compressed using gzip,
so first move it to /usr/src, then type:
tar -xzvf shadow-current.tar.gz
This will unpack it into the directory: /usr/src/shadow-YYMMDD
4.2. Configuring with the config.h file
The first thing that you need to do is to copy over the Makefile and
the config.h file:
cd /usr/src/shadow-YYMMDD
cp Makefile.linux Makefile
cp config.h.linux config.h
You should then take a look at the config.h file. This file contains
definitions for some of the configuration options. If you are using
the recommended package, I recommend that you disable group shadow
support for your first time around.
By default shadowed group passwords are enabled. To disable these
edit the config.h file, and change the #define SHADOWGRP to #undef
SHADOWGRP. I recommend that you disable them to start with, and then
if you really want group passwords and group administrators that you
enable it later and recompile. If you leave it enabled, you must
create the file /etc/gshadow.
Enabling the long passwords option is NOT recommended as discussed
above.
Do NOT change the setting: #undef AUTOSHADOW
The AUTOSHADOW option was originally designed so that programs that
were shadow ignorant would still function. This sounds good in
theory, but does not work correctly. If you enable this option, and
the program runs as root, it may call getpwnam() as root, and later
write the modified entry back to the /etc/passwd file (with the no-
longer-shadowed password). Such programs include chfn and chsh. (You
can't get around this by swapping real and effective uid before
calling getpwnam() because root may use chfn and chsh too.)
The same warning is also valid if you are building libc, it has a
SHADOW_COMPAT option which does the same thing. It should NOT be
used! If you start getting encoded passwords back in your /etc/passwd
file, this is the problem.
If you are using a libc version prior to 4.6.27, you will need to make
a couple more changes to config.h and the Makefile. To config.h edit
and change:
#define HAVE_BASENAME
to:
#undef HAVE_BASENAME
And then in the Makefile, change:
SOBJS = smain.o env.o entry.o susetup.o shell.o \
sub.o mail.o motd.o sulog.o age.o tz.o hushed.o
SSRCS = smain.c env.c entry.c setup.c shell.c \
pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
tz.c hushed.c
SOBJS = smain.o env.o entry.o susetup.o shell.o \
sub.o mail.o motd.o sulog.o age.o tz.o hushed.o basename.o
SSRCS = smain.c env.c entry.c setup.c shell.c \
pwent.c sub.c mail.c motd.c sulog.c shadow.c age.c pwpack.c rad64.c \
tz.c hushed.c basename.c
These changes add the code contained in basename.c which is contained
in libc 4.6.27 and later.
4.3. Making backup copies of your original programs.
It would also be a good idea to track down and make backup copies of
the programs that the shadow suite will replace. On a Slackware 3.0
system these are:
� /bin/su
� /bin/login
� /usr/bin/passwd
� /usr/bin/newgrp
� /usr/bin/chfn
� /usr/bin/chsh
� /usr/bin/id
The BETA package has a save target in the Makefile, but it's commented
out because different distributions place the programs in different
places.
You should also make a backup copy of your /etc/passwd file, but be
careful to name it something else if you place it in the same
directory so you don't overwrite the passwd command.
4.4. Running make
You need to be logged as root to do most of the installation.
Run make to compile the executables in the package:
make all
You may see the warning: rcsid defined but not used. This is fine, it
just happens because the author is using a version control package.
5. Installing
5.1. Have a boot disk handy in case you break anything.
If something goes terribly wrong, it would be handy to have a boot
disk. If you have a boot/root combination from your installation,
that will work, otherwise see the Bootdisk-HOWTO
<http://sunsite.unc.edu/mdw/HOWTO/Bootdisk-HOWTO.html>, which
describes how to make a bootable disk.
5.2. Removing duplicate man pages
You should also move the manual pages that are about to be replaced.
Even if you are brave enough install the Shadow Suite without making
backups, you will still want to remove the old manual pages. The new
manual pages won't normally overwrite the old ones because the old
ones are probably compressed.
You can use a combination of: man -aW command and locate command to
locate the manual pages that need to be (re)moved. It's generally
easier to figure out which are the older pages before you run make
install.
If you are using the Slackware 3.0 distribution, then the manual pages
you want to remove are:
� /usr/man/man1/chfn.1.gz
� /usr/man/man1/chsh.1.gz
� /usr/man/man1/id.1.gz
� /usr/man/man1/login.1.gz
� /usr/man/man1/passwd.1.gz
� /usr/man/man1/su.1.gz
� /usr/man/man5/passwd.5.gz
There may also be man pages of the same name in the /var/man/cat[1-9]
subdirectories that should also be deleted.
5.3. Running make install
You are now ready to type: (do this as root)
make install
This will install the new and replacement programs and fix-up the file
permissions. It will also install the man pages.
This also takes care of installing the Shadow Suite include files in
the correct places in /usr/include/shadow.
Using the BETA package you must manually copy the file login.defs to
the /etc subdirectory and make sure that only root can make changes to
it.
cp login.defs /etc
chmod 700 /etc/login.defs
This file is the configuration file for the login program. You should
review and make changes to this file for your particular system. This
is where you decide which tty's root can login from, and set other
security policy settings (like password expiration defaults).
5.4. Running pwconv
The next step is to run pwconv. This must also be done as root, and
is best done from the /etc subdirectory:
cd /etc
/usr/sbin/pwconv
pwconv takes your /etc/passwd file and strips out the fields to create
two files: /etc/npasswd and /etc/nshadow.
A pwunconv program is also provided if you need to make a normal
/etc/passwd file out of an /etc/passwd and /etc/shadow combination.
5.5. Renaming npasswd and nshadow
Now that you have run pwconv you have created the files /etc/npasswd
and /etc/nshadow. These need to be copied over to /etc/passwd and
/etc/shadow. We also want to make a backup copy of the original
/etc/passwd file, and make sure only root can read it. We'll put the
backup in root's home directory:
cd /etc
cp passwd ~passwd
chmod 600 ~passwd
mv npasswd passwd
mv nshadow shadow
You should also ensure that the file ownerships and permissions are
correct. If you are going to be using X-Windows, the xlock and xdm
programs need to be able to read the shadow file (but not write it).
There are two ways that this can be done. You can set xlock to suid
root (xdm is usually run as root anyway). Or you can make the shadow
file owned by root with a group of shadow, but before you do this,
make sure that you have a shadow group (look in /etc/group). None of
the users on the system should actually be in the shadow group.
chown root.root passwd
chown root.shadow shadow
chmod 0644 passwd
chmod 0640 shadow
Your system now has the password file shadowed. You should now pop
over to another virtual terminal and verify that you can login.
Really, do this now!
If you can't, then something is wrong! To get back to a non-shadowed
state, do the following the following:
cd /etc
cp ~passwd passwd
chmod 644 passwd
You would then restore the files that you saved earlier to their
proper locations.
6. Other programs you may need to upgrade or patch
Even though the shadow suite contains replacement programs for most
programs that need to access passwords, there are a few additional
programs on most systems that require access to passwords.
If you are running a Debian Distribution (or even if you are not), you
can obtain Debian sources for the programs that need to be rebuild
from: ftp://ftp.debian.org/debian/stable/source/
The remainder of this section discusses how to upgrade adduser,
wu_ftpd, ftpd, pop3d, xlock, xdm and sudo so that they support the
shadow suite.
See the section ``Adding Shadow Support to a C program'' for a
discussion on how to put shadow support into any other program that
needs it (although the program must then be run SUID root or SGID
shadow to be able to actually access the shadow file).
6.1. Slackware adduser program
Slackware distributions (and possibly some others) contain a
interactive program for adding users called /sbin/adduser. A shadow
version of this program can be obtained from
ftp://sunsite.unc.edu/pub/Linux/
system/Admin/accounts/adduser.shadow-1.4.tar.gz.
I would encourage you to use the programs that are supplied with the
Shadow Suite (useradd, usermod, and userdel) instead of the slackware
adduser program. They take a little time to learn how to use, but
it's well worth the effort because you have much more control and they
perform proper file locking on the /etc/passwd and /etc/shadow file
(adduser doesn't).
See the section on ``Putting the Shadow Suite to use'' for more
information.
But if you gotta have it, here is what you do:
tar -xzvf adduser.shadow-1.4.tar.gz
cd adduser
make clean
make adduser
chmod 700 adduser
cp adduser /sbin
6.2. The wu_ftpd Server
Most Linux systems some with the wu_ftpd server. If your distribution
does not come with shadow installed, then your wu_ftpd will not be
compiled for shadow. wu_ftpd is launched from inetd/tcpd as a root
process. If you are running an old wu_ftpd daemon, you will want to
upgrade it anyway because older ones had a bug that would allow the
root account to be compromised (For more info see the Linux security
home page <http://bach.cis.temple.edu/linux/linux-security/Linux-
Security-FAQ/Linux-wu.ftpd-2.4-Update.html>).
Fortunately, you only need to get the source code and recompile it
with shadow enabled.
If you are not running an ELF system, The wu_ftp server can be found
on Sunsite as wu-ftp-2.4-fixed.tar.gz
<ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/wu-
ftpd-2.4-fixed.tar.gz>
Once you retrieve the server, put it in /usr/src, then type:
cd /usr/src
tar -xzvf wu-ftpd-2.4-fixed.tar.gz
cd wu-ftpd-2.4-fixed
cp ./src/config/config.lnx.shadow ./src/config/config.lnx
Then edit ./src/makefiles/Makefile.lnx, and change the line:
LIBES = -lbsd -support
to:
LIBES = -lbsd -support -lshadow
Now you are ready to run the build script and install:
cd /usr/src/wu-ftpd-2.4-fixed
/usr/src/wu-ftp-2.4.fixed/build lnx
cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
cp ./bin/ftpd /usr/sbin/wu.ftpd
This uses the Linux shadow configuration file, compiles and installs
the server.
On my Slackware 2.3 system I also had to do the following before
running build:
cd /usr/include/netinet
ln -s in_systm.h in_system.h
cd -
Problems have been reported compiling this package under ELF systems,
but the Beta version of the next release works fine. It can be found
as wu-ftp-2.4.2-beta-10.tar.gz
<ftp://tscnet.com/pub/linux/network/ftp/wu-ftpd-2.4.2-beta-10.tar.gz>
Once you retrieve the server, put it in /usr/src, then type:
cd /usr/src
tar -xzvf wu-ftpd-2.4.2-beta-9.tar.gz
cd wu-ftpd-beta-9
cd ./src/config
Then edit config.lnx, and change:
#undef SHADOW.PASSWORD
to:
#define SHADOW.PASSWORD
Then,
cd ../Makefiles
and edit the file Makefile.lnx and change:
LIBES = -lsupport -lbsd # -lshadow
to:
LIBES = -lsupport -lbsd -lshadow
Then build and install:
cd ..
build lnx
cp /usr/sbin/wu.ftpd /usr/sbin/wu.ftpd.old
cp ./bin/ftpd /usr/sbin/wu.ftpd
Note that you should check your /etc/inetd.conf file to make sure that
this is where your wu.ftpd server really lives. It has been reported
that some distributions place the server daemons in different places,
and then wu.ftpd in particular may be named something else.
6.3. Standard ftpd
If you are running the standard ftpd server, I would recommend that
you upgrade to the wu_ftpd server. Aside from the known bug discussed
above, it's generally thought to be more secure.
If you insist on the standard one, or you need NIS support, Sunsite
has ftpd-shadow-nis.tgz
<ftp://sunsite.unc.edu/pub/Linux/system/Network/file-transfer/ftpd-
shadow-nis.tgz>
6.4. pop3d (Post Office Protocol 3)
If you need to support the third Post Office Protocol (POP3), you will
need to recompile a pop3d program. pop3d is normally run by
inetd/tcpd as root.
There are two versions available from Sunsite:
pop3d-1.00.4.linux.shadow.tar.gz
<ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d-1.00.4.linux.shadow.tar.gz>
and pop3d+shadow+elf.tar.gz
<ftp://sunsite.unc.edu/pub/Linux/system/Mail/pop/pop3d+shadow+elf.tar.gz>
Both of these are fairly straight forward to install.
6.5. xlock
If you install the shadow suite, and then run X Windows System and
lock the screen without upgrading your xlock, you will have to use
CNTL-ALT-Fx to switch to another tty, login, and kill the xlock
process (or use CNTL-ALT-BS to kill the X server). Fortunately it's
fairly easy to upgrade your xlock program.
If you are running XFree86 Versions 3.x.x, you are probably using
xlockmore (which is a great screen-saver in addition to a lock). This
package supports shadow with a recompile. If you have an older xlock,
I recommend that you upgrade to this one.
xlockmore-3.5.tgz is available at:
<ftp://sunsite.unc.edu/pub/Linux/X11/xutils/screensavers/xlockmore-3.7.tgz>
Basically, this is what you need to do:
Get the xlockmore-3.7.tgz file and put it in /usr/src unpack it:
tar -xzvf xlockmore-3.7.tgz
Edit the file: /usr/X11R6/lib/X11/config/linux.cf, and change the
line:
#define HasShadowPasswd NO
to
#define HasShadowPasswd YES
Then build the executables:
cd /usr/src/xlockmore
xmkmf
make depend
make
Then move everything into place and update file ownerships and
permissions:
cp xlock /usr/X11R6/bin/
cp XLock /var/X11R6/lib/app-defaults/
chown root.shadow /usr/X11R6/bin/xlock
chmod 2755 /usr/X11R6/bin/xlock
chown root.shadow /etc/shadow
chmod 640 /etc/shadow
Your xlock will now work correctly.
6.6. xdm
xdm is a program that presents a login screen for X-Windows. Some
systems start xdm when the system is told to goto a specified run
level (see /etc/inittab.
With the Shadow Suite install, xdm will need to be updated.
Fortunately it's fairly easy to upgrade your xdm program.
xdm.tar.gz is available at:
<ftp://sunsite.unc.edu/pub/Linux/X11/xutils/xdm.tar.gz>
Get the xdm.tar.gz file and put it in /usr/src, then to unpack it:
tar -xzvf xdm.tar.gz
Edit the file: /usr/X11R6/lib/X11/config/linux.cf, and change the
line:
#define HasShadowPasswd NO
to
#define HasShadowPasswd YES
Then build the executables:
cd /usr/src/xdm
xmkmf
make depend
make
Then move everything into place:
cp xdm /usr/X11R6/bin/
xdm is run as root so you don't need to change it file permissions.
6.7. sudo
The program sudo allows a system administrator to let users run
programs that would normally require root access. This is handy
because it lets the administrator limit access to the root account
itself while still allowing users to do things like mounting drives.
sudo needs to read passwords because it verifies the users password
when it's invoked. sudo already runs SUID root, so accessing the
/etc/shadow file is not a problem.
sudo for the shadow suite, is available as at:
<ftp://sunsite.unc.edu/pub/Linux/system/Admin/sudo-1.2-shadow.tgz>
Warning: When you install sudo your /etc/sudoers file will be replaced
with a default one, so you need to make a backup of it if you have
added anything to the default one. (you could also edit the Makefile
and remove the line that copies the default file to /etc).
The package is already setup for shadow, so all that's required is to
recompile the package (put it in /usr/src):
cd /usr/src
tar -xzvf sudo-1.2-shadow.tgz
cd sudo-1.2-shadow
make all
make install
6.8. imapd (E-Mail pine package)
imapd is an e-mail server similar to pop3d. imapd comes with the Pine
E-mail package. The documentation that comes with the package states
that the default for Linux systems is to include support for shadow.
However, I have found that this is not true. Furthermore, the build
script / Makefile combination on this package is makes it very
difficult to add the libshadow.a library at compile time, so I was
unable to add shadow support for imapd.
If anyone has this figured out, please E-mail me, and I'll include the
solution here.
6.9. pppd (Point-to-Point Protocol Server)
The pppd server can be setup to use several types of authentication:
Password Authentication Protocol (PAP) and Cryptographic Handshake
Authentication Protocol (CHAP). The pppd server usually reads the
password strings that it uses from /etc/ppp/chap-secrets and/or
/etc/ppp/pap-secrets. If you are using this default behavior of pppd,
it is not necessary to reinstall pppd.
pppd also allows you to use the login parameter (either on the command
line, or in the configuration or options file). If the login option
is given, then pppd will use the /etc/passwd file for the username and
passwords for the PAP. This, of course, will no longer work now that
our password file is shadowed. For pppd-1.2.1d this requires adding
code for shadow support.
The example given in the next section is adding shadow support to
pppd-1.2.1d (an older version of pppd).
pppd-2.2.0 already contains shadow support.
7. Putting the Shadow Suite to use.
This section discusses some of the things that you will want to know
now that you have the Shadow Suite installed on your system. More
information is contained in the manual pages for each command.
7.1. Adding, Modifying, and deleting users
The Shadow Suite added the following command line oriented commands
for adding, modifying, and deleting users. You may also have
installed the adduser program.
7.1.1. useradd
The useradd command can be used to add users to the system. You also
invoke this command to change the default settings.
The first thing that you should do is to examine the default settings
and make changes specific to your system:
useradd -D
______________________________________________________________________
GROUP=1
HOME=/home
INACTIVE=0
EXPIRE=0
SHELL=
SKEL=/etc/skel
______________________________________________________________________
The defaults are probably not what you want, so if you started adding
users now you would have to specify all the information for each user.
However, we can and should change the default values.
On my system:
� I want the default group to be 100
� I want passwords to expire every 60 days
� I don't want to lock an account because the password is expired
� I want to default shell to be /bin/bash
To make these changes I would use:
useradd -D -g100 -e60 -f0 -s/bin/bash
Now running useradd -D will give:
______________________________________________________________________
GROUP=100
HOME=/home
INACTIVE=0
EXPIRE=60
SHELL=/bin/bash
SKEL=/etc/skel
______________________________________________________________________
Just in case you wanted to know, these defaults are stored in the file
/etc/default/useradd.
Now you can use useradd to add users to the system. For example, to
add the user fred, using the defaults, you would use the following:
useradd -m -c "Fred Flintstone" fred
This will create the following entry in the /etc/passwd file:
fred:*:505:100:Fred Flintstone:/home/fred:/bin/bash
And the following entry in the /etc/shadow file:
fred:!:0:0:60:0:0:0:0
fred's home directory will be created and the contents of /etc/skel
will be copied there because of the -m switch.
Also, since we did not specify a UID, the next available one was used.
fred's account is created, but fred still won't be able to login until
we unlock the account. We do this by changing the password.
passwd fred
______________________________________________________________________
Changing password for fred
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New Password: *******
Re-enter new password: *******
______________________________________________________________________
Now the /etc/shadow will contain:
fred:J0C.WDR1amIt6:9559:0:60:0:0:0:0
And fred will now be able to login and use the system. The nice thing
about useradd and the other programs that come with the Shadow Suite
is that they make changes to the /etc/passwd and /etc/shadow files
atomically. So if you are adding a user, and another user is changing
their password at the same time, both operations will be performed
correctly.
You should use the supplied commands rather than directly editing
/etc/passwd and /etc/shadow. If you were editing the /etc/shadow
file, and a user were to change his password while you are editing,
and then you were to save the file you were editing, the user's
password change would be lost.
Here is a small interactive script that adds users using useradd and
passwd:
______________________________________________________________________
#!/bin/bash
#
# /sbin/newuser - A script to add users to the system using the Shadow
# Suite's useradd and passwd commands.
#
# Written my Mike Jackson <mhjack@tscnet.com> as an example for the Linux
# Shadow Password Howto. Permission to use and modify is expressly granted.
#
# This could be modified to show the defaults and allow modification similar
# to the Slackware Adduser program. It could also be modified to disallow
# stupid entries. (i.e. better error checking).
#
##
# Defaults for the useradd command
##
GROUP=100 # Default Group
HOME=/home # Home directory location (/home/username)
SKEL=/etc/skel # Skeleton Directory
INACTIVE=0 # Days after password expires to disable account (0=never)
EXPIRE=60 # Days that a passwords lasts
SHELL=/bin/bash # Default Shell (full path)
##
# Defaults for the passwd command
##
PASSMIN=0 # Days between password changes
PASSWARN=14 # Days before password expires that a warning is given
##
# Ensure that root is running the script.
##
WHOAMI=`/usr/bin/whoami`
if [ $WHOAMI != "root" ]; then
echo "You must be root to add news users!"
exit 1
fi
##
# Ask for username and fullname.
##
echo ""
echo -n "Username: "
read USERNAME
echo -n "Full name: "
read FULLNAME
#
echo "Adding user: $USERNAME."
#
# Note that the "" around $FULLNAME is required because this field is
# almost always going to contain at least on space, and without the "'s
# the useradd command would think that you we moving on to the next
# parameter when it reached the SPACE character.
#
/usr/sbin/useradd -c"$FULLNAME" -d$HOME/$USERNAME -e$EXPIRE \
-f$INACTIVE -g$GROUP -m -k$SKEL -s$SHELL $USERNAME
##
# Set password defaults
##
/bin/passwd -n $PASSMIN -w $PASSWARN $USERNAME >/dev/null 2>&1
##
# Let the passwd command actually ask for password (twice)
##
/bin/passwd $USERNAME
##
# Show what was done.
##
echo ""
echo "Entry from /etc/passwd:"
echo -n " "
grep "$USERNAME:" /etc/passwd
echo "Entry from /etc/shadow:"
echo -n " "
grep "$USERNAME:" /etc/shadow
echo "Summary output of the passwd command:"
echo -n " "
passwd -S $USERNAME
echo ""
______________________________________________________________________
Using a script to add new users is really much more preferable than
editing the /etc/passwd or /etc/shadow files directly or using a
program like the Slackware adduser program. Feel free to use and
modify this script for your particular system.
For more information on the useradd see the online manual page.
7.1.2. usermod
The usermod program is used to modify the information on a user. The
switches are similar to the useradd program.
Let's say that you want to change fred's shell, you would do the
following:
usermod -s /bin/tcsh fred
Now fred's /etc/passwd file entry would be change to this:
fred:*:505:100:Fred Flintstone:/home/fred:/bin/tcsh
Let's make fred's account expire on 09/15/97:
usermod -e 09/15/97 fred
Now fred's entry in /etc/shadow becomes:
fred:J0C.WDR1amIt6:9559:0:60:0:0:10119:0
For more information on the usermod command see the online manual
page.
7.1.3. userdel
userdel does just what you would expect, it deletes the user's
account. You simply use:
userdel -r username
The -r causes all files in the user's home directory to be removed
along with the home directory itself. Files located in other file
system will have to be searched for and deleted manually.
If you want to simply lock the account rather than delete it, use the
passwd command instead.
7.2. The passwd command and passwd aging.
The passwd command has the obvious use of changing passwords.
Additionally, it is used by the root user to:
� Lock and unlock accounts (-l and -u)
� Set the maximum number of days that a password remains valid (-x)
� Set the minimum days between password changes (-n)
� Sets the number of days of warning that a password is about to
expire (-w)
� Sets the number of days after the password expires before the
account is locked (-i)
� Allow viewing of account information in a clearer format (-S)
For example, let look again at fred
passwd -S fred
fred P 03/04/96 0 60 0 0
This means that fred's password is valid, it was last changed on
03/04/96, it can be changed at any time, it expires after 60 days,
fred will not be warned, and and the account won't be disabled when
the password expires.
This simply means that if fred logs in after the password expires, he
will be prompted for a new password at login.
If we decide that we want to warn fred 14 days before his password
expires and make his account inactive 14 days after he lets it expire,
we would need to do the following:
passwd -w14 -i14 fred
Now fred is changed to:
fred P 03/04/96 0 60 14 14
For more information on the passwd command see the online manual page.
7.3. The login.defs file.
The file /etc/login is the configuration file for the login program
and also for the Shadow Suite as a whole.
/etc/login contains settings from what the prompts will look like to
what the default expiration will be when a user changes his password.
The /etc/login.defs file is quite well documented just by the comments
that are contained within it. However, there are a few things to
note:
� It contains flags that can be turned on or off that determine the
amount of logging that takes place.
� It contains pointers to other configuration files.
� It contains defaults assignments for things like password aging.
From the above list you can see that this is a rather important file,
and you should make sure that it is present, and that the settings are
what you desire for your system.
7.4. Group passwords.
The /etc/groups file may contain passwords that permit a user to
become a member of a particular group. This function is enabled if
you define the constant SHADOWGRP in the /usr/src/shadow-
YYMMDD/config.h file.
If you define this constant and then compile, you must create an
/etc/gshadow file to hold the group passwords and the group
administrator information.
When you created the /etc/shadow, you used a program called pwconv,
there no equivalent program to create the /etc/gshadow file, but it
really doesn't matter, it takes care of itself.
To create the initial /etc/gshadow file do the following:
touch /etc/gshadow
chown root.root /etc/gshadow
chmod 700 /etc/gshadow
Once you create new groups, they will be added to the /etc/group and
the /etc/gshadow files. If you modify a group by adding or removing
users or changing the group password, the /etc/gshadow file will be
changed.
The programs groups, groupadd, groupmod, and groupdel are provided as
part of the Shadow Suite to modify groups.
The format of the /etc/group file is as follows:
groupname:!:GID:member,member,...
Where:
groupname
The name of the group
! The field that normally holds the password, but that is now
relocated to the /etc/gshadow file.
GID
The numerical group ID number
member
List of group members
The format of the /etc/gshadow file is as follows:
groupname:password:admin,admin,...:member,member,...
Where:
groupname
The name of the group
password
The encoded group password.
admin
List of group administrators
member
List of group members
The command gpasswd is used only for adding or removing administrators
and members to or from a group. root or someone in the list of
administrators may add or remove group members.
The groups password can be changed using the passwd command by root or
anyone listed as an administrator for the group.
Despite the fact that there is not currently a manual page for
gpasswd, typing gpasswd without any parameters gives a listing of
options. It's fairly easy to grasp how it all works once you
understand the file formats and the concepts.
7.5. Consistency checking programs
7.5.1. pwck
The program pwck is provided to provide a consistency check on the
/etc/passwd and /etc/shadow files. It will check each username and
verify that it has the following:
� the correct number of fields
� unique user name
� valid user and group identifier
� valid primary group
� valid home directory
� valid login shell
It will also warn of any account that has no password.
It's a good idea to run pwck after installing the Shadow Suite. It's
also a good idea to run it periodically, perhaps weekly or monthly.
If you use the -r option, you can use cron to run it on a regular
basis and have the report mailed to you.
7.5.2. grpck
grpck is the consistency checking program for the /etc/group and
/etc/gshadow files. It performs the following checks:
� the correct number of fields
� unique group name
� valid list of members and administrators
It also has the -r option for automated reports.
7.6. Dial-up passwords.
Dial-up passwords are another optional line of defense for systems
that allow dial-in access. If you have a system that allows many
people to connect locally or via a network, but you want to limit who
can dial in and connect, then dial-up passwords are for you. To
enable dial-up passwords, you must edit the file /etc/login.defs and
ensure that DIALUPS_CHECK_ENAB is set to yes.
Two files contain the dial-up information, /etc/dialups which contains
the ttys (one per line, with the leading "/dev/" removed). If a tty
is listed then dial-up checks are performed.
The second file is the /etc/d_passwd file. This file contains the
fully qualified path name of a shell, followed by an optional
password.
If a user logs into a line that is listed in /etc/dialups, and his
shell is listed in the file /etc/d_passwd he will be allowed access
only by suppling the correct password.
Another useful purpose for using dial-up passwords might be to setup a
line that only allows a certain type of connect (perhaps a PPP or UUCP
connection). If a user tries to get another type of connection (i.e.
a list of shells), he must know a password to use the line.
Before you can use the dial-up feature, you must create the files.
The command dpasswd is provided to assign passwords to the shells in
the /etc/d_passwd file. See the manual page for more information.
8. Adding shadow support to a C program
Adding shadow support to a program is actually fairly straightforward.
The only problem is that the program must be run by root (or SUID
root) in order for the the program to be able to access the
/etc/shadow file.
This presents one big problem: very careful programming practices must
be followed when creating SUID programs. For instance, if a program
has a shell escape, this must not occur as root if the program is SUID
root.
For adding shadow support to a program so that it can check passwords,
but otherwise does need to run as root, it's a lot safer to run the
program SUID shadow instead. The xlock program is an example of this.
In the example given below, pppd-1.2.1d already runs SUID as root, so
adding shadow support should not make the program any more vulnerable.
8.1. Header files
The header files should reside in /usr/include/shadow. There should
also be a /usr/include/shadow.h, but it will be a symbolic link to
/usr/include/shadow/shadow.h.
To add shadow support to a program, you need to include the header
files:
#include <shadow/shadow.h>
#include <shadow/pwauth.h>
It might be a good idea to use compiler directives to conditionally
compile the shadow code (I do in the example below).
8.2. libshadow.a library
When you installed the Shadow Suite the libshadow.a file was created
and installed in /usr/lib.
When compiling shadow support into a program, the linker needs to be
told to include the libshadow.a library into the link.
This is done by:
gcc program.c -o program -lshadow
However, as we will see in the example below, most large programs use
a Makefile, and usually have a variable called LIBS=... that we will
modify.
8.3. Shadow Structure
The libshadow.a library uses a structure called spwd for the
information it retrieves from the /etc/shadow file. This is the
definition of the spwd structure from the /usr/include/shadow/shadow.h
header file:
______________________________________________________________________
struct spwd
{
char *sp_namp; /* login name */
char *sp_pwdp; /* encrypted password */
sptime sp_lstchg; /* date of last change */
sptime sp_min; /* minimum number of days between changes */
sptime sp_max; /* maximum number of days between changes */
sptime sp_warn; /* number of days of warning before password
expires */
sptime sp_inact; /* number of days after password expires
until the account becomes unusable. */
sptime sp_expire; /* days since 1/1/70 until account expires
*/
unsigned long sp_flag; /* reserved for future use */
};
______________________________________________________________________
The Shadow Suite can put things into the sp_pwdp field besides just
the encoded passwd. The password field could contain:
username:Npge08pfz4wuk;@/sbin/extra:9479:0:10000::::
This means that in addition to the password, the program /sbin/extra
should be called for further authentication. The program called will
get passed the username and a switch that indicates why it's being
called. See the file /usr/include/shadow/pwauth.h and the source code
for pwauth.c for more information.
What this means is that we should use the function pwauth to perform
the actual authentication, as it will take care of the secondary
authentication as well. The example below does this.
The author of the Shadow Suite indicates that since most programs in
existence don't do this, and that it may be removed or changed in
future versions of the Shadow Suite.
8.4. Shadow Functions
The shadow.h file also contains the function prototypes for the
functions contained in the libshadow.a library:
______________________________________________________________________
extern void setspent __P ((void));
extern void endspent __P ((void));
extern struct spwd *sgetspent __P ((__const char *__string));
extern struct spwd *fgetspent __P ((FILE *__fp));
extern struct spwd *getspent __P ((void));
extern struct spwd *getspnam __P ((__const char *__name));
extern int putspent __P ((__const struct spwd *__sp, FILE *__fp));
______________________________________________________________________
The function that we are going to use in the example is: getspnam
which will retrieve for us a spwd structure for the supplied name.
8.5. Example
This is an example of adding shadow support to a program that needs
it, but does not have it by default.
This example uses the Point-to-Point Protocol Server (pppd-1.2.1d),
which has a mode in which it performs PAP authentication using user
names and passwords from the /etc/passwd file instead of the PAP or
CHAP files. You would not need to add this code to pppd-2.2.0 because
it's already there.
This feature of pppd probably isn't used very much, but if you
installed the Shadow Suite, it won't work anymore because the
passwords are no longer stored in /etc/passwd.
The code for authenticating users under pppd-1.2.1d is located in the
/usr/src/pppd-1.2.1d/pppd/auth.c file.
The following code needs to be added to the top of the file where all
the other #include directives are. We have surrounded the #includes
with conditional directives (i.e. only include if we are compiling for
shadow support).
______________________________________________________________________
#ifdef HAS_SHADOW
#include <shadow.h>
#include <shadow/pwauth.h>
#endif
______________________________________________________________________
The next thing to do is to modify the actual code. We are still
making changes to the auth.c file.
Function auth.c before modifications:
______________________________________________________________________
/*
* login - Check the user name and password against the system
* password database, and login the user if OK.
*
* returns:
* UPAP_AUTHNAK: Login failed.
* UPAP_AUTHACK: Login succeeded.
* In either case, msg points to an appropriate message.
*/
static int
login(user, passwd, msg, msglen)
char *user;
char *passwd;
char **msg;
int *msglen;
{
struct passwd *pw;
char *epasswd;
char *tty;
if ((pw = getpwnam(user)) == NULL) {
return (UPAP_AUTHNAK);
}
/*
* XXX If no passwd, let them login without one.
*/
if (pw->pw_passwd == '\0') {
return (UPAP_AUTHACK);
}
epasswd = crypt(passwd, pw->pw_passwd);
if (strcmp(epasswd, pw->pw_passwd)) {
return (UPAP_AUTHNAK);
}
syslog(LOG_INFO, "user %s logged in", user);
/*
* Write a wtmp entry for this user.
*/
tty = strrchr(devname, '/');
if (tty == NULL)
tty = devname;
else
tty++;
logwtmp(tty, user, ""); /* Add wtmp login entry */
logged_in = TRUE;
return (UPAP_AUTHACK);
}
______________________________________________________________________
The user's password is placed into pw->pw_passwd, so all we really
need to do is add the function getspnam. This will put the password
into spwd->sp_pwdp.
We will add the function pwauth to perform the actual authentication.
This will automatically perform secondary authentication if the shadow
file is setup for it.
Function auth.c after modifications to support shadow:
______________________________________________________________________
/*
* login - Check the user name and password against the system
* password database, and login the user if OK.
*
* This function has been modified to support the Linux Shadow Password
* Suite if USE_SHADOW is defined.
*
* returns:
* UPAP_AUTHNAK: Login failed.
* UPAP_AUTHACK: Login succeeded.
* In either case, msg points to an appropriate message.
*/
static int
login(user, passwd, msg, msglen)
char *user;
char *passwd;
char **msg;
int *msglen;
{
struct passwd *pw;
char *epasswd;
char *tty;
#ifdef USE_SHADOW
struct spwd *spwd;
struct spwd *getspnam();
#endif
if ((pw = getpwnam(user)) == NULL) {
return (UPAP_AUTHNAK);
}
#ifdef USE_SHADOW
spwd = getspnam(user);
if (spwd)
pw->pw_passwd = spwd->sp-pwdp;
#endif
/*
* XXX If no passwd, let NOT them login without one.
*/
if (pw->pw_passwd == '\0') {
return (UPAP_AUTHNAK);
}
#ifdef HAS_SHADOW
if ((pw->pw_passwd && pw->pw_passwd[0] == '@'
&& pw_auth (pw->pw_passwd+1, pw->pw_name, PW_LOGIN, NULL))
|| !valid (passwd, pw)) {
return (UPAP_AUTHNAK);
}
#else
epasswd = crypt(passwd, pw->pw_passwd);
if (strcmp(epasswd, pw->pw_passwd)) {
return (UPAP_AUTHNAK);
}
#endif
syslog(LOG_INFO, "user %s logged in", user);
/*
* Write a wtmp entry for this user.
*/
tty = strrchr(devname, '/');
if (tty == NULL)
tty = devname;
else
tty++;
logwtmp(tty, user, ""); /* Add wtmp login entry */
logged_in = TRUE;
return (UPAP_AUTHACK);
}
______________________________________________________________________
Careful examination will reveal that we made another change as well.
The original version allowed access (returned UPAP_AUTHACK if there
was NO password in the /etc/passwd file. This is not good, because a
common use of this login feature is to use one account to allow access
to the PPP process and then check the username and password supplied
by PAP with the username in the /etc/passwd file and the password in
the /etc/shadow file.
So if we had set the original version up to run as the shell for a
user i.e. ppp, then anyone could get a ppp connection by setting
their PAP to user ppp and a password of null.
We fixed this also by returning UPAP_AUTHNAK instead of UPAP_AUTHACK
if the password field was empty.
Interestingly enough, pppd-2.2.0 has the same problem.
Next we need to modify the Makefile so that two things occur:
USE_SHADOW must be defined, and libshadow.a needs to be added to the
linking process.
Edit the Makefile, and add:
LIBS = -lshadow
Then we find the line:
COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t
And change it to:
COMPILE_FLAGS = -I.. -D_linux_=1 -DGIDSET_TYPE=gid_t -DUSE_SHADOW
Now make and install.
9. Frequently Asked Questions.
Q: I used to control which tty's root could log into using the file
/etc/securettys, but it doesn't seem to work anymore, what's going on?
A: The file /etc/securettys does absolutely nothing now that the
Shadow Suite is installed. The tty's that root can use are now
located in the login configuration file /etc/login.defs. The entry in
this file may point to another file.
Q: I installed the Shadow Suite, but now I can't login, what did I
miss?
A: You probably installed the Shadow programs, but didn't run pwconv
or you forgot to copy /etc/npasswd to /etc/passwd and /etc/nshadow to
/etc/shadow. Also, you may need to copy login.defs to /etc.
Q: In the section on xlock, it said to change the group ownership of
the /etc/shadow file to shadow. I don't have a shadow group, what do
I do?
A: You can add one. Simply edit the /etc/group file, and insert a
line for the shadow group. You need to ensure that the group number
is not used by another group, and you need to insert it before the
nogroup entry. Or you can simply suid xlock to root.
Q: Is there a mailing list for the Linux Shadow Password Suite?
A: Yes, but it's for the development and beta testing of the next
Shadow Suite for Linux. You can get added to the list by mailing to:
shadow-list-request@neptune.cin.net with a subject of: subscribe. The
list is actually for discussions of the Linux shadow-YYMMSS series of
releases. You should join if you want to get involved in further
development or if you install the Suite on your system and want to get
information on newer releases.
Q: I installed the Shadow Suite, but when I use the userdel command, I
get "userdel: cannot open shadow group file", what did I do wrong?
A: You compiled the Shadow Suite with the SHADOWGRP option enabled,
but you don't have an /etc/gshadow file. You need to either edit the
config.h file and recompile, or create an /etc/group file. See the
section on shadow groups.
Q: I installed the Shadow Suite but now I'm getting encoded passwords
back in my /etc/passwd file, what's wrong?
A: You either enabled the AUTOSHADOW option in the Shadow config.h
file, or your libc was compiled with the SAHDOW_COMPAT option. You
need to determine which is the problem, and recompile.
10. Copyright Message.
The Linux Shadow Password HOWTO is Copyright (c) 1996 Michael H.
Jackson.
Permission is granted to make and distribute verbatim copies of this
document provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
document under the conditions for verbatim copies above, provided a
notice clearly stating that the document is a modified version is also
included in the modified document.
Permission is granted to copy and distribute translations of this
document into another language, under the conditions specified above
for modified versions.
Permission is granted to convert this document into another media
under the conditions specified above for modified versions provided
the requirement to acknowledge the source document is fulfilled by
inclusion of an obvious reference to the source document in the new
media. Where there is any doubt as to what defines 'obvious' the
copyright owner reserves the right to decide.
11. Miscellaneous and Acknowledgments.
The code examples for auth.c are taken from pppd-1.2.1d and
ppp-2.1.0e, Copyright (c) 1993 and The Australian National University
and Copyright (c) 1989 Carnegie Mellon University.
Thanks to Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> for
writing and maintaining the Shadow Suite for Linux, and for his review
and comments on this document.
Thanks to Ron Tidd <rtidd@tscnet.com> for his helpful review and
testing.
Thanks to everyone who has sent me feedback to help improve this
document.
Please, if you have any comments or suggestions then mail them to me.
regards
Michael H. Jackson <mhjack@tscnet.com>
|