- but really, it's safest not to use setuid scripts at all.Q.12 Why shouldn't I leave "root" permanently logged on the console?Using a 'smart' terminal as console and leaving "/dev/console" worldwritable whilst "root" is logged in is a potential hole.  The terminalmay be vulnerable to remote control via escape sequences, and can beused to 'type' things into the root shell.  The terminal type canusually be obtained via the "ps" command.Various solutions to this can be devised, usually by giving the consoleowner and group-write access only , and then using the setgid mechanismon any program which has need to output to the console (eg: "write").Q.13 Why shouldn't I create Unix accounts with null passwords?Creating an unpassworded account to serve any purpose is potentiallydangerous, not for any direct reason, but because it can give a crackera toehold.For example, on many systems you will find a unpassworded user "sync",which allows the sysman to sync the disks without being logged in.  Thisappears to be both safe and innocuous.The problem with this arises if your system is one of the many whichdoesn't do checks on a user before authorising them for (say) FTP.  Acracker might be able to connect to your machine for one of a variety ofFTP methods, pretending to be user "sync" with no password, and thencopy your password file off for remote cracking.Although there are mechanisms to prevent this sort of thing happening inmost modern vesions of Unix, to be totally secure requires an in-depthknowledge of every package on your system, and how it deals with theverification of users.  If you can't be sure, it's probably better notto leave holes like this around.Another hole that having null-password accounts opens up is thepossibility (on systems with runtime linked libraries) of spoofingsystem software into running your programs as the "sync" user, bychanging the LD_LIBRARY_PATH variable to a library of your own devising,and running "login -p" or "su" to turn into that user.Q.14 What security holes are associated with X-windows (and other WMs)?Lots, some which affect use of X only, and some which impact thesecurity of the entire host system.I would prefer not to go into too much detail here, and would refer anyreader reader looking for detailed information to the other FAQ's inrelevant newsgroups.  (comp.windows.*)One point I will make is that X is one of those packages which oftengenerates "Incompatible Usage" security problems, for instance theability for crackers to run xsessions on hosts under accounts with nopassword (eg: sync), if it is improperly set up.  Read the questionabout unpassworded accounts in this FAQ.Q.15 What security holes are associated with NFS?Lots, mostly to do with who you export your disks to, and how.  Thesecurity of NFS relies heavily upon who is allowed to mount the filesthat a server exports, and whether they are exported read only or not.The exact format for specifying which hosts can mount an exporteddirectory varies between Unix implementations, but generally theinformation is contained within the file "/etc/exports".This file contains a list of directories and for each one, it has aseries of either specific "hosts" or "netgroups" which are allowed toNFS mount that directory.  This list is called the "access list".The "hosts" are individual machines, whilst "netgroups" are combinationsof hosts and usernames specified in "/etc/netgroup".  These are meant toprovide a method of finetuning access.  Read the relevant manual pagefor more information about netgroups.The exports file also contains information about whether the directoryis to be exported as read-only, read-write, and whether super-useraccess is to be allowed from clients which mount that directory.The important point to remember is that if the access list for aparticular directory in /etc/exports contains:1) <nothing>Your directory can be mounted by anyone, anywhere.2) <a specific hostname>Your directory can be mounted by anyone permitted to run the mountcommand at hostname.  This might not be a trustworthy person; forinstance, if the machine is a PC running NFS, it could be anyone.3) <a netgroup name>If the netgroup:a) is empty, anyone can mount your directory, from anywhere.b) contains "(,,)", anyone can mount your directory, from anywhere.c) contains the name of a netgroup which is empty or contains "(,,)",   anyone can mount your directory, from anywhere.d) contains "(hostname,,)", anyone on the named host who is permissioned   to mount files can mount your directory.e) contains "(,username,)", the named user can mount your directory,   from anywhere.4) <a word which is neither a hostname or a netgroup>If you meant to export the directory to the host "athena" but actuallytype "ahtena", the word "ahtena" is taken as a netgroup name, is foundto be an empty netgroup, and thus the directory can be mounted byanyone, anywhere.So, if you aren't careful about what you put into /etc/exports and/etc/netgroup you could find that a user with a PC could  a) mount your mainframe filestore as a network disk  b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ...  c) log into your mainframe as another user, possibly "root"Disclaimer: The above information may not be true for all platformswhich provide an NFS serving capability, but is true for all of the onesin my experience (AEM).  It should be noted that the SAFE way to createan "empty" netgroup entry is:                           ngname (-,-,-)Which is a netgroup which matches no-one on no-host on no-NIS-domain.[ I am STILL working on PC NFS packages / ethics at the moment - AEM ]Q.16 How can I generate safe passwords?You can't.  The key word here is GENERATE.  Once an algorithm forcreating passwords is specified using upon some systematic method, itmerely becomes a matter of analysing your algorithm in order to findevery password on your system.Unless the algorithm is very subtle, it will probably suffer from a verylow period (ie: it will soon start to repeat itself) so that either:  a) a cracker can try out every possible output of the password  generator on every user of the system, or  b) the cracker can analyse the output of the password program,  determine the algorithm being used, and apply the algorithm to other  users to determine their passwords.A beautiful example of this (where it was disastrously assumed that arandom number generator could generate an infinite number of randompasswords) is detailed in [Morris & Thompson].The only way to get a reasonable amount of variety in your passwords(I'm afraid) is to make them up.  Work out some flexible method of yourown which is NOT based upon:  1) modifying any part of your name or name+initials  2) modifying a dictionary word  3) acronyms  4) any systematic, well-adhered-to algorithm whatsoeverFor instance, NEVER use passwords like:alec7           - it's based on the users name (& it's too short anyway)tteffum         - based on the users name againgillian         - girlfiends name (in a dictionary)naillig         - ditto, backwardsPORSCHE911      - it's in a dictionary12345678        - it's in a dictionary (& people can watch you type it easily)qwertyui        - ...ditto...abcxyz          - ...ditto...0ooooooo        - ...ditto...Computer        - just because it's capitalised doesn't make it safewombat6         - ditto for appending some random character6wombat         - ditto for prepending some random charactermerde3          - even for french words...mr.spock        - it's in a sci-fi dictionaryzeolite         - it's in a geological dictionaryze0lite         - corrupted version of a word in a geological dictionaryze0l1te         - ...ditto...Z30L1T3         - ...ditto...I hope that these examples emphasise that ANY password derived from ANYdictionary word (or personal information), modified in ANY way,constitutes a potentially guessable password.For more detailed information in the same vein, you should read theAPPENDIX files which accompany Crack [Muffett].Q.17 Why are passwords so important?Because they are the first line of defence against interactive attackson your system.  It can be stated simply: if a cracker cannot interactwith your system(s), and he has no access to read or write theinformation contained in the password file, then he has almost noavenues of attack left open to break your system.This is also why, if a cracker can at least read your password file (andif you are on a vanilla modern Unix, you should assume this) it is soimportant that he is not able to break any of the passwords containedtherein.  If he can, then it is also fair to assume that he can (a) logon to your system and can then (b) break into "root" via an operatingsystem hole.Q.18 How many possible passwords are there?Most people ask this at one time or another, worried that programs likeCrack will eventually grow in power until they can do a completelyexhaustive search of all possible passwords, to break into a specificusers' account - usually root.If (to simplify the maths) we make the assumptions that:  1) Valid passwords are created from a set of 62 chars [A-Za-z0-9]  2) Valid passwords are to be between 5 and 8 chars longThen the size of the set of all valid passwords is: (in base 62)                                   100000 +                                  1000000 +                                 10000000 +                                100000000 =                                ---------                                111100000       (base 62)A figure which is far too large to usefully undertake an exhaustivesearch with current technologies.  Don't forget, however, that passwordsCAN be made up with even more characters then this; you can use <space>,all the punctuation characters, and symbols (~<>|\#$%^&*) too.  If youcan use some of all the 95 non-control characters in passwords, thisincreases the search space for a cracker to cover even further. However, it's still MUCH more efficient for a cracker to get a copy of"Crack", break into ANY account on the system (you only need one), logonto the machine, and spoof his way up to root priviledges via operatingsystems holes. Take comfort from these figures.  If you can slam the door in the faceof a potential crackers with a robust password file, you have sealedmost of the major avenues of attack immediately.Q.19 Where can I get more information?Books:[Kochan & Wood]Unix System SecurityA little dated for modern matters, but still a very good book on thebasics of Unix security.[Spafford & Garfinkel]Practical Unix SecurityThis wonderful book is a worthy successor to the above, and covers awide variety of the topics which the Unix (and some non Unix) systemmanager of the 90's will come across.>From: Gene Spafford <spaf@cs.purdue.edu>>Mention appendix E in "Practical Unix Security."Okay: Appendix E contains an extensive bibliography with even morepointers to security books than this FAQ contains.[Stoll]The Cuckoo's EggA real life 1980's thriller detailing the tracing of a cracker fromBerkeley across the USA and over the Atlantic to Germany.  An excellentview from all points: a good read, informative about security, funny,and a good illustration of the cracker psyche.  Contains an excellentrecipie for chocolate chip cookies.A videotape of the "NOVA" (PBS's Science Program on TV) episode thatexplained/reenacted this story is available from PBS Home Video.  Theyhave a toll-free 800 number within North America.