4.1.1. Just what is a "security policy?"

Like many buzzwords now current among computing aficionados, the term "security policy" rarely gets spelled out with any specificity. There are "policies," and then there are policies. Some are expensive exercises in bureaucratic deniability. These impressive documents, often termed "security assertions," will lay out some basic measures and practices that need to be followed. Unfortunately, the practical result is that frequently the security needs of a system are never addressed beyond the strict wording of the "assertion." If there's a problem at least we can say, "Well, we followed the assertion, so it must have been faulty; sue the consultant." The consultant can almost always win these cases since he or she is well prepared to demonstrate that 'due diligence' was exercised in the preparation of the assertion. So the entire raison d'etre of the policy is revealed to be no more than an elaborate exercise of "Cover your back side."

Beyond specifying a certain number of protective measures to be taken, a good security policy should in effect draw a complete picture of the operation of the system(s) whose security is at stake, especially with regard to the following:

• What are the threats?

  A list of all the possible causes of data loss or downtime would be an impressive document indeed. As noted above, nowadays all the hype is focussed on the blackhat crackers. In fact losses due to other causes probably outweigh those brought about by intentionally malicious incursions. Consider, for instance, the role of mistakes. An administrator or user enters an untoward command and presto: instead of backing up a drive it is wiped clean. Or, think about hardware failures; all storage media as of this writing are mortal creatures with finite life spans. Suppose a thorough backup procedure is not in place? The point here is that security threats come in myriad colors: accidents, mistakes, Acts of God, as well as intentional invasion by bad people.

• What are relative priorities of these threats?

  Yes, you've installed a state of the art smoke detector system, and a similarly modern Halon fire extinguishing system in all parts of the building that house hosts. But, in the event the toilet (water heater, etc.) in the restroom down the hall malfunctions, how many inches of water are required to reach those hosts? Are they on the floor? My money is on the toilet overflowing more often than the building catching fire.

• For each specific threat, what is the recovery plan in the event a given threat comes to pass?

  How much time will it take to get organized and in gear to repair a problem? Or, will the owner or CEO have to be reached in Santiago because no one else knows who has a copy of the key used to encrypt the backups? How many people know who to order a replacement drive from? Typically the problem with recovery plans is that they get written once, and then gravitate towards the bottom of a bookshelf in someone's office. Eventually no one is sure where it is, or how long it's been since it was reviewed and updated. Sound familiar? ("It's on the bottom shelf of the bookcase behind my desk, under the stack of three year old catalogs I refuse to part with.")

4.1.2. What is Social Engineering?

"Hello, I'm the new sysadmin. Could I have your password?"

The term "Social Engineering" is a modern euphemism for "flim-flam." Social engineering is "wetware" engineering, the manipulation of people. It's the old confidence game in cyber-dress. Three card monte with folks sitting at keyboards.

Although the telephone is the classic tool of social engineering, it is not the only one. Suppose someone managed to get the following memo into everyone's mail box:

Hi, 

My name is Bob Slickwhistle and I am the network administrator here at 
dialupsRus.com. We recently had a security intrusion and are re-assigning 
passwords to all users. We would highly recommend that you change
your password as soon as possible to the randomly chosen password below. 

Your randomly chosen password is: zrY5yw2P 

Thank you,
B. Slickwhistle

Inform your users that a Unix system administrator never needs to ask any user for his or her password. Tell them that you are glad they are nice people, anxious to help their fellow computer users, but that you are paid handsomely to be not nice to unknown callers, and that all requests for help should be redirected to yourself.

Email is convenient but it is trivial to forge 'From:' and 'Reply-To:' headers. Never trust critical matters to email communications unless they are PGP/GnuPG signed and verified, or you have some other way of verifying their authenticity. Sometimes Plain Old Telephone is best.

4.1.3. Software Package Security

"Security through obscurity" is a failed paradigm. Trying to make things secure by keeping them secret doesn't work anymore, if it ever did. Now everything is out in the open. Well, not everything. Many security breaches go unreported and many more, UN publicized. Sometimes this is due to an organization's wish to avoid embarrassing notoriety. No doubt intrusions into national security facilities are for the most part kept quiet. To a large degree, though, the bugs, the holes, the exploits, and the tools of both black- and white- hats are posted all over the Internet.

The upside to this arrangement is clear; when a problem or bug surfaces the alerts are sounded and work on the fixes gets underway immediately. The downside may be less obvious: everyone reads the alerts, good guys and bad guys alike. If you are not reading the alerts then the black hats will always be several steps ahead of you. They are counting on you not to pay attention to security matters. Unfortunately, as a rule, you (present company excepted of course) do not disappoint them.

Does this mean you have to subscribe to Bugtraq (http://www.securityfocus.com/forums/bugtraq/intro.html)? Not necessarily, since Caldera's track record for following security issues related to Linux is one of the best among the major Linux distributors. Here is what you ought to do:

• Subscribe to the Caldera announcement email list. You will receive notification of new security-related updates to eServer's software packages. For subscription information surf to http://www.calderasystems.com/support/forums/announce.html.

• Become familiar with the archive of past security updates. Bookmark it's URL: http://www.calderasystems.com/support/security/.

• Learn about the Caldera FTP server. Updated rpm packages for eServer are here: ftp://ftp.calderasystems.com/pub/updates/eServer/. Take the time to become familiar with the directory layout of the ftp site. Note the importance of the 'current/' directory.

• Get your system in sync with 'current/'.If you see a package there that you are not using, consider removing it from your system.

4.1.4. To-do List

Here are some odds 'n ends. That they are located in this section should not be taken as a measure of their importance.

4.1.5. A Few Thoughts on Physical Security and Backups

This is an enormous topic, which by its very nature invites encyclopedic treatment. Such a treatment can be found in Simson and Garfinkel, but here are some rambling reflections.

• Locks tend to be placed more with convenience in mind than security. Example: your hosts are behind a door that is always locked, but your unencrypted backup tapes are in the unlocked file cabinet in your office, which on a good day resembles Grand Central Station.

• You've invested a goodly sum in a UPS, but do you know how long it will keep your system(s) running, and is it set up to shut them down in an orderly fashion? Where is it? Who has access to it?

• How many complete sets of backups should you have? Keep in mind that all storage media are fallible, and over time are bound to fail. Where are backups kept? Are they under lock and key at their off-site locations?

• Is your data of sufficient value to merit encrypted filesystems, and/or encrypted backups? Have you thought about what it would take to recover in the event that data fell into someone else's hands? What damage could be done with your data in the wrong hands?

• If you use encryption in your filesystem or backups, who has the key(s)? Where are their copies kept? Under what conditions? How many copies should be in others' hands?

4.2.1. Configuring kdm for secure operations

When first installed, eServer is configured to utilize the services of the kdm program to manage logins, reboots and shutdowns. This program is responsible for the initial graphical login screen that appears when the computer has booted and is ready for a login. For secure operations the default install of kdm is unacceptable on two counts.

• The monitor displays a list of the usernames for all normal accounts on the system.

• Any person, whether a user or not, never mind whether the superuser or not, can shut the machine down or reboot it by clicking on the "Shutdown" button displayed on kdm's screen dialog.

This may seem an ephemeral concern. The consideration is always, however, "How can I make it even a little harder for an attacker, and how I can do that easily?" Hiding kdm's display of usernames is easy, as we shall see. Furthermore, requiring even a casual attacker (if there is such a creature) to guess both a username and a password will slow down such an attack. The indiscriminate and unnecessary display of any system information literally invites attack; it advertises carelessness.

Are there people who will sit at a login prompt and try to guess a username and password? A little history will suffice to answer. Unix systems did not at first have a password protected login system. In the collegial atmosphere of the research and academic facilities in which Unix was developed, a culture of trust and respect permeated the workplace. Obviously it was soon realized that the blessings of such an ethic were not widespread, and the first encrypted password systems were developed. At one interesting turn in this development it was observed that an interloper could determine whether or not a username just entered was a valid username on the system by observing the amount of time required to come back to the login prompt after a login attempt failed. In the earliest configuration of passwords, if the username entered was not valid, the login program would not bother to check the password also entered. Since this checking entailed encrypting the password and comparing it to the system's password file, there was an easily noticeable time differential between the behavior of the login process with a valid username, and without. The obvious conclusion was reached, and the login program was rewritten so that all passwords would be encrypted regardless of whether the username was valid or invalid. The answer to the question above, then, has always been, "Heck yes!" Before proceeding to the fix, we need to address the second concern regarding kdm.

Recall further that, on the KDE desktop, the logout "X" button can similarly be clicked by any person, thus bringing up the kdm dialog. Granted, the screensavers provided by KDE can be configured to require the user's password to regain access to the KDE desktop, but screensavers must tolerate a delay before they are activated, and most users are sufficiently inconvenienced by short delays to avoid them. In fact most users will avoid setting a password on their screensaver because it too is inconvenient. Consequently, it is more than likely that any casual bystander will in short order be able to shutdown or reboot an eServer system.

Edit them to read:

ShutdownButton=RootOnly UserView=false

At this point if you log out of the current KDE session you will return to a different kdm dialog. The row of icons representing users will be gone. And, if you click on "Shutdown," you will be asked for the root password.

4.2.2. How to remove kdm

An alternative to the steps just described is to remove kdm, or, more accurately, circumvent it. This results in eServer behaving in a traditional, "normal", fashion; after booting up the user will be presented with a character-based terminal login prompt. After logging in the KDE desktop can be started with the command "kde".

kdm can be removed with a few simple steps:

1. As root edit the file /etc/inittab. Change the default runlevel from '5' to '3':

   # The default runlevel. id:3:initdefault:

2. Edit the file /etc/lilo.conf. Comment out this line by prepending the '#' character:

   #message = /boot/message

3. If your version of lilo.conf contains a line that begins 'vga = ' make it read:

   vga = normal

4. Update the lilo bootloader by running the command:'/sbin/lilo'.

   Note: This command, if executed unwisely, can render a computer inoperable, that is, incapable of being rebooted. Always run it first with these arguments:

   # /sbin/lilo -v -t

   This puts lilo into verbose mode and test mode. You will be shown what lilo will do, but no changes will actually be made. It is almost always fatal to ignore any warnings lilo produces here.

4.2.3. Disabling Ctrl-Alt-Del

This step should be taken regardless of whether kdm is used or not used. Although this keystroke combination is not effective while in the KDE desktop, the defaults for eServer's initial install are such that any user in a console session can initiate a shutdown and reboot by pressing the famous three keys at the same time.

There are two possible responses to this situation, depending on the behavior one would like to see. It is possible to completely disable this keystroke combination, and it possible to disable it partially, so that the combination is only effective when root is logged in. In this latter case, as long as root is logged in any user at any console can activate Ctrl-Alt-Del. Superuser logins do not satisfy this condition, only direct logins by root. Since the strong advice here is to never do this, this "partial" method will in almost all cases be tantamount to a "complete" method for disabling the combination.

Both approaches require only a simple edit of /etc/inittab. Look for these lines:

# Trap CTRL-ALT-DEL ca:12345:ctrlaltdel:/sbin/shutdown -t3 -r now

The "complete" solution is achieved by commenting the line out:

# Trap CTRL-ALT-DEL #ca:12345:ctrlaltdel:/sbin/shutdown -t3 -r now

or by substituting another command for 'shutdown', as in this example:

# Trap CTRL-ALT-DEL ca:12345:ctrlaltdel:/bin/echo "Ctrl-Alt-Del has been disabled."

The "partial" solution is achieved by first adding the '-a' argument to the shutdown command (see 'man shutdown'):

ca:12345:ctrlaltdel:/sbin/shutdown -a -t3 -r now

and then creating the file /etc/shutdown.allow containing the lone word "root":

# echo root > /etc/shutdown.allow

The command

# telinit q

will bring these changes to /etc/inittab into effect.

4.2.4. Those other drives

This section might easily have come under the rubric "Physical Security," but it concerns specifically how the machine might be rebooted. Obviously, where there is physical access to a host, it will always be subject to unauthorized reboots, if only by the simple expedient of toggling the power switch a couple of times. There is however one contingency that ought to be at least considered as a candidate for preemptive measures.

A Linux boot floppy is a simple enough thing to put together. Diskette images are floating around all over the Internet; the diskettes are shipped with every distribution, and there are software packages available for creating custom diskettes. Some of the latter comprise complete working Linux systems; all they require is a computer that will boot from the floppy drive. And, there are CD versions of the same that can be used with hardware that is bootable from that drive.

Booting via either of these methods provides access to the entire file-system. Any file can be altered, copied, or sent to another host anywhere in the world, depending on the connectivity afforded by the host in question. The usual rebuttal here is "Look, with physical access to the machine all bets are off. Why bother with the boot drives when everything you describe can be accomplished anyway without rebooting?" But this last statement is misleading. An intruder seated at the terminal will have to get past the security built into the system in the form of passwords and file ownerships and permissions. All of these latter are instantly circumvented with a simple floppy reboot, but even a skillful attacker with physical access will require some time to work through the security inherent in the system.

Recall that what is "secure" is a judgment call made by someone in a particular context, a certain time and place. In short, we are always "playing the odds" here, and one might even say that it is ultimately a game of one psychology versus another. Every attacker will, at a certain unknown and unknowable level of frustration, move on. Theoretically, an imaginary "hyper-predator" attacker, capable of tolerating infinite frustration, will always succeed, sooner or later. The aim of all security measures is to make the attacker work harder and harder for a victory. We have to be content with layering one finite measure after another onto the system, and there is no way to predict which measure will in the end succeed in deterring a given attacker on a given day. That is the backdrop to all security policies, and this discussion of boot drives exemplifies it perfectly. The possible steps suggested below are typical of the small incremental actions which, taken together, produce the elusive quality known as "secure."

Nothing says, "Go away; you have no business here." quite like a computer case with no visible drive doors. The "boundary condition" of this phenomena, its ultimate development, can be seen perhaps in the design of remotely administered rack mounted server units. Here are some possibilities:

• Remove all floppy, CD, tape and zip drives, replacing them with blank covers. If the host is that important, and at some point needs to be rebooted from the floppy drive, you should have where feasible a drop-in replacement for it handy. In any event reinstalling a floppy drive takes about three minutes.

• Open the case and unplug the data and power cables from all of those devices. Always carry a screwdriver. (And, some would add, a good set of wire-cutters capable of dealing with any of your network cables.)

• Go into the system BIOS and disable all of those devices.

• Do the above but also set a password in the BIOS.

4.3.1. How passwords work

Passwords function as part of an authentication system. They serve to demonstrate to the computer that the user who logs in is in fact the person that user purports to be. As we noted earlier, the pioneering work on Unix evolved inside workplace subcultures that put a premium on trust and respect for others. Alec Muffett writes:

A system can be perfectly secure without any passwords at all, so long as it is in an environment of people who recognize its purpose and depend on it. I say this after having had accounts on several 'public' machines, which could have been taken to bits by any competent Unix person, but were largely safe - because when someone worked out who did anything nasty, the culprit was ostracized from the community.

Although it is no doubt an oversimplification, historically there have been four major stages in the implementation of passwords on Unix systems:

• No passwords at all.

  This arrangement is now merely an historical curiosity, a vestige of the hallowed times of early Unix development in research and university environments. The day is long gone since this was a reasonable option.

• Plain text passwords in world-readable files.

  In their landmark essay "Password Security: A Case History," Robert Morris and Ken Thompson described one possible outcome of this technique:

  ...in the early 60's...a system administrator on the CTSS system at MIT was editing the password file and another system administrator was editing the daily message that is printed on everyone's terminal on login. Due to a software design error,the temporary editor files of the two users were interchanged and thus, for a time, the password file was printed on every terminal when it was logged in.

  So much for plain text. It is worth taking note of the other feature mentioned, that password files have up until a few years ago always been world-readable on Unix systems. A look at your /etc/passwd file will make clear the reason for this. A typical entry for a normal user, utilizing plain text passwords, might have looked like:

  wingnut:fishwrap:1004:1004:Eric 'Alibut,,,:/home/wingnut:/bin/bash

  So, user 'wingnut' has the password 'fishwrap'. However, it is the other information in the record for this account that needs to be available to any process on the system, regardless of who "owns" that process. So, the account's username, user id, group id, home directory, and shell for logins, are made public, and along with them the account's password. It's clear why plain text had to go.

  Note: The quote is from "R. Morris and K. Thompson, "Password Security: A Case History", Communications of the ACM, Vol.22, No.11, November, 1979, pp.594-597. It can be found at ftp://ftp.mcc.ac.uk/pub/security/PAPERS/PASSWORD/PWSTUDY.PS

• Encrypted password representations in world-readable files.

  This is the contribution described by our two authors, above. When the password for an account is first set, it is used to generate a thirteen character long string that to any human being appears mere gibberish. For example, the same record noted above would now appear something like this:

  wingnut:pW5R9RwayjNtw:1004:1004:Eric 'Alibut,,,:/home/wingnut:/bin/bash

  Thereafter, whenever user 'wingnut' logs in, the password he or she enters is put through that same process used initially to generate the string that is "on record" in the password file. If the results of that process match the record, then the login is permitted. Note that the string so generated and kept in the file is not properly speaking an "encrypted password." It is the result of an encryption process that incorporates, or represents indirectly, the password. This seemingly pedantic point will turn out to have implications for security when we examine the password system in detail.

• Encrypted password representations in files with restricted read access ("shadowed").

  As the speed of computers went up and their price came down, it became clear that world-readable password files were too risky. With this greatly improved "bang per buck" computing factor came much greater likelihoods that any encrypted password file could be "cracked." A way was found to separate out what needed to be in a world-readable file from what could be put be placed a file with restricted read access. This was termed "shadowing" the passwords. Our user wingnut's record in /etc/passwd now looks like this:

  wingnut:x:1004:1004:Eric 'Alibut,,,:/home/wingnut:/bin/bash

  The presence of an "x" in the second colon-delimited field indicates that password shadowing has been implemented; the encrypted representation of wingnut's password is in another file, /etc/shadow, which is not world-readable. All the other bits of information that are needed by processes running on the computer are still available in /etc/passwd.

4.3.2. Choosing passwords

The facts are simple. Virtually every word in every written language has been put into machine-readable lists that can potentially find their way into the databases used by password cracking programs. (Most of them already have.) And, virtually no human being is in possession of even a tiny fraction of what's on those lists. Given today's storage technology and processing speeds it is a simple matter to make available to these programs the contents of every dictionary, name list, encyclopedia, gazetteer, geographical atlas and scientific lexicon that one could wish to have. Then leave it to clever programmers who live, eat, and sleep password cracking to code into these programs every imaginable reordering scheme one might ever apply to all of these words. Look at them forwards, backwards, inside-out, upside-down, with a number after them and a number before them. Substitute the obvious and not so obvious numerals for letters (o = 0, l = 1, e = 3, etc.) Then ring changes on capitalization and all of its imaginable variations. You get the idea.

The upshot of all of this is that brute force attacks on passwords never need to be even attempted. A "key search" can restrict itself to a comparatively very narrow subset of all possible passwords, and that subset can be defined and manipulated with all the speed modern computers possess. The one thing no programmer can deliberately set out to snare via any set of rules or patterns is the perfectly randomly chosen password. The secret to secure passwords is the degree of randomness, or "entropy" as it's termed, that is built into the process of selecting that password. But there's no free lunch; random passwords are difficult to remember, and without a bit of education on their care and feeding most users will write a random password down and leave it somewhere, such as the middle top drawer of their desk, if not on a postit note stuck to their monitor.

4.3.3. Enhancing eServer passwords

It is possible to leave behind the eight character limitation on the length of passwords used by eServer. Using the 'MD5' cryptographic hash function, passwords of up to 127 characters can be encrypted. With the DES-based password system installed by default in eServer, passwords longer than eight characters will appear to be accepted without complaint; nevertheless only the first eight characters are significant. This can be easily tested, but if you want to do the test do it before carrying out the steps outlined in this section.

The advantage of longer passwords should be clear: they make the job of the cracker enormously more difficult. It's not that password cracking cannot operate on MD5 encrypted password files, but that the universe of likely choices for passwords is larger by several degrees of magnitude. Hence the job of building the word lists that inform the cracking process is that much more difficult. Here are the steps necessary to convert eServer to using MD5 hashed passwords:

4.3.4. Password cracking

Here are two password cracking programs that can be installed on eServer.

4.4.1. Tripwire

Tripwire has been around for quite some time. Its job is to provide the administrator with information about changes to critical files on the system. Intruders have become quite skilled at covering their tracks, and rootkits as a rule go through log and history files removing mention of the intruder's activities. Typically these attacks feature the substitution of compromised files for standard system files; the most notorious of these being /bin/login. Tripwire can pick up these sorts of changes, and it is well within the realm of possibility that an intrusion could go unnoticed apart from the special scrutiny afforded by Tripwire. The program works by taking a 'snapshot' of the state of the system, its critical files, at a point in time when the system is believed to be secure. It does this by creating a database containing cryptographic signatures of these files. Then, on a regular basis, typically daily, the files' signatures are compared to the contents of the database. Any changes will be noted and reported by Tripwire.

4.4.2. Aide

A project is underway to provide a replacement for Tripwire that is licensed under the GPL, the license that has been used for developing and distributing a fair amount of the GNU/Linux system, of which eServer is an instance. Aide (Advanced Intrusion Detection Environment) has a home page at http://www.cs.tut.fi/~rammer/aide.html.

4.4.3. COPS

No discussion of file integrity security would be complete without at least a mention of COPS. It is one of the most venerable auditing tools available for the Unix platform. Functionally it overlaps somewhat the ground covered by Tripwire, inasmuch as COPS will report changes made to vital files, for instance system binaries and libraries. COPS's method for this task is not as sophisticated as Tripwire's, and COPS does not have the innate security that is afforded Tripwire by virtue of its extensive use of encryption. But there are two sides to every story, and COPS examines certain aspects of the system that are not examined by Tripwire. For example COPS will look at your password and group files and report any untoward circumstances therein. COPS will report on files that are world-readable but perhaps should not be. And, COPS pays special attention to suid files, listing prominently in its reports all of these files and any changes to them. These are only some of the checks performed by COPS that Tripwire does not encompass. Tripwire does one job, and does it in a sophisticated and secure fashion. COPS, although it spreads its net farther than Tripwire, unfortunately is not as tamper-proof as Tripwire. This makes it perhaps not the tool of choice for routine daily monitoring, but COPS still has a role in assessing the security-related health of a system.

What follows is a description of the steps needed to build COPS and take it out for a first test spin. The discussion will not follow through to a complete system installation of COPS; the documentation included is more than adequate to guide the reader through that process. As noted above, no security tool should be used for serious work without a thorough examination of the relevant documentation.

4.5.1. A Diceware-like table for passwords

The table shown is designed for use with a set of 16 dice. Put them all in a can (after closing the blinds and latching the door) and roll them all at once. Then arrange them on your desk in a 2x8 array and pick the eight characters off the table according to that array. Simple, yet almost perfectly random. For a larger set of characters, such as upper and lower case, put eight coins in the can along with the dice: heads for upper, tails for lower case. If the dice call for a number, then heads could mean the number and tails mean "pick a special character".

4.5.2. mkpasswd script

Here is Don Libes' mkpasswd script, as found at http://www2.informatik.uni-jena.de/docs/Programs/expect/example/mkpasswd. The first line has been changed to reflect expect's path in eServer's filesystem.

#!/usr/bin/expect -- # mkpasswd - make a password, if username given, set it. # Author: Don Libes, NIST # defaults set length 8 set minnum 2 set minlower 2 set minupper 2 set verbose 0 set distribute 0 if [file executable /bin/yppasswd] { set defaultprog /bin/yppasswd } elseif [file executable /bin/passwd] { set defaultprog /bin/passwd } else { set defaultprog passwd } set prog $defaultprog while {[llength $argv]>0} { set flag [lindex $argv 0] switch -- $flag \ "-l" { set length [lindex $argv 1] set argv [lrange $argv 2 end] } "-d" { set minnum [lindex $argv 1] set argv [lrange $argv 2 end] } "-c" { set minlower [lindex $argv 1] set argv [lrange $argv 2 end] } "-C" { set minupper [lindex $argv 1] set argv [lrange $argv 2 end] } "-v" { set verbose 1 set argv [lrange $argv 1 end] } "-p" { set prog [lindex $argv 1] set argv [lrange $argv 2 end] } "-2" { set distribute 1 set argv [lrange $argv 1 end] } default { set user [lindex $argv 0] set argv [lrange $argv 1 end] break } } if {[llength $argv]} { puts "usage: mkpasswd \[args] \[user]" puts " where arguments are:" puts " -l # (length of password, default = $length)" puts " -d # (min # of digits, default = $minnum)" puts " -c # (min # of lowercase chars, default = $minlower)" puts " -C # (min # of uppercase chars, default = $minupper)" puts " -v (verbose, show passwd interaction)" puts " -p prog (program to set password, default = $defaultprog)" exit 1 } if {$minnum + $minlower + $minupper > $length} { puts "impossible to generate $length-character password\ with $minnum numbers, $minlower lowercase letters,\ and $minupper uppercase letters" exit 1 } # if there is any underspecification, use additional lowercase letters set minlower [expr $length - ($minnum + $minupper)] set lpass "" ;# password chars typed by left hand set rpass "" ;# password chars typed by right hand # insert char into password at a random position proc insert {pvar char} { upvar $pvar p set p [linsert $p [rand [expr 1+[llength $p]]] $char] } set _ran [pid] proc rand {m} { global _ran set period 259200 set _ran [expr ($_ran*7141 + 54773) % $period] expr int($m*($_ran/double($period))) } # choose left or right starting hand set initially_left [set isleft [rand 2]] # given a size, distribute between left and right hands # taking into account where we left off proc psplit {max lvar rvar} { upvar $lvar left $rvar right global isleft if {$isleft} { set right [expr $max/2] set left [expr $max-$right] set isleft [expr !($max%2)] } else { set left [expr $max/2] set right [expr $max-$left] set isleft [expr $max%2] } } if {$distribute} { set lkeys {q w e r t a s d f g z x c v b} set rkeys {y u i o p h j k l n m} set lnums {1 2 3 4 5 6} set rnums {7 8 9 0} } else { set lkeys {a b c d e f g h i j k l m n o p q r s t u v w x y z} set rkeys {a b c d e f g h i j k l m n o p q r s t u v w x y z} set lnums {0 1 2 3 4 5 6 7 8 9} set rnums {0 1 2 3 4 5 6 7 8 9} } set lkeys_length [llength $lkeys] set rkeys_length [llength $rkeys] set lnums_length [llength $lnums] set rnums_length [llength $rnums] psplit $minnum left right for {set i 0} {$i<$left} {incr i} { insert lpass [lindex $lnums [rand $lnums_length]] } for {set i 0} {$i<$right} {incr i} { insert rpass [lindex $rnums [rand $rnums_length]] } psplit $minlower left right for {set i 0} {$i<$left} {incr i} { insert lpass [lindex $lkeys [rand $lkeys_length]] } for {set i 0} {$i<$right} {incr i} { insert rpass [lindex $rkeys [rand $rkeys_length]] } psplit $minupper left right for {set i 0} {$i<$left} {incr i} { insert lpass [string toupper [lindex $lkeys [rand $lkeys_length]]] } for {set i 0} {$i<$right} {incr i} { insert rpass [string toupper [lindex $rkeys [rand $rkeys_length]]] } # merge results together if {$initially_left} { regexp "(\[^ ]*) *(.*)" "$lpass" x password lpass while {[llength $lpass]} { regexp "(\[^ ]*) *(.*)" "$password$rpass" x password rpass regexp "(\[^ ]*) *(.*)" "$password$lpass" x password lpass } if {[llength $rpass]} { append password $rpass } } else { regexp "(\[^ ]*) *(.*)" "$rpass" x password rpass while {[llength $rpass]} { regexp "(\[^ ]*) *(.*)" "$password$lpass" x password lpass regexp "(\[^ ]*) *(.*)" "$password$rpass" x password rpass } if {[llength $lpass]} { append password $lpass } } if {[info exists user]} { if {!$verbose} { log_user 0 } spawn $prog $user expect { "assword*:" { # some systems say "Password (again):" send "$password\r" exp_continue } } # if user isn't watching, check status if {!$verbose} { if {[lindex [wait] 3]} { puts -nonewline "$expect_out(buffer)" exit 1 } } } if {$verbose} { puts -nonewline "password for $user is " } puts "$password"

4.5.3. Installing gpw