CCS Account Software

Systems Manual

Documentaion by Hank Hughes

There are two main parts to the account software: the client and the server. The client is run as a login shell available from every machine on the network. The server lives on the host named 'account' which should also be the YP master. The client and the server share a protocol: a reply code and a brief reply message.

The Client

Source exists in /ccs/src/homegrown/account-#.#.

The client becomes a login shell for user: 'account'. It is intended to be a menu-driven, front-end for users either requesting or changing their account. It is not intended to allow the user to escape the menu and let the user access to a valid shell, or, in essence, let the user execute commands.

It's primary functionality for making accounts is to collect user input and insert that data into the "account request queue". Note, this software is not an automation of account requests, just a data collector which makes a pile of requests for a human to validate and make the final decision. Personal information includes:

The critical feature to the account client is the way it handles passwords. Most places you request a password, you write it down or tell your systems administrator what you want your password to be. With the account client, the user selects their password and noone on systems ever sees the un-encrypted version. The password is recieved, validated to be safe, and then crypted, which is later bundled with the rest of the users personal data and shipped across the network to the account server.

Security ...

First off, the usual things to tighten security are on: "-w" for warnings and "-T" for tainting. Also, there's no use of "eval", "system", "open( | )", or even backtick'd commands like `/bin/touch foo` at all. On top of the usual, predictable methods, input from the user is collected via the get_input which has 5 arguments:
  1. a regular expression defining what is acceptable as input
  2. a string to be used as the prompt for the user
  3. a string to be used as an error message for the user
  4. an integer to define the minumum length of user input
  5. an integer to define the maximum length of user input
In most cases, the regular expression is defined as alphanumeric only. However, there are three special cases when determining someones full name. The hyphen is allowed for hyphenated names, the period is allowed for words like "Sr." or "Jr.", and the apostrophe is allowed for words like "O'Hallahan". For example:
   $full_name =
       &get_input( "[a-zA-Z0-9 \-\.\']+",   # Allow alphapnumeric with - . '
		   $max_length );

Please note, that the regular expression should not contain the semi-colon, or backtick. This could pose a security threat.

Also, the colon should also be considered harmful as input. Since the colon is deterministic in the gcos field of a password entry and this program is essentially collecting data for that password entry, the colon should not be allowed as valid input from the user.

The get_input will display warning (maybe it should just die?) if it notices these characters defined as acceptable input.

Communication to a server is obviously done through a pipe. A socket connection is made and communication is made throught print statements like:

   print $socket "$msg\r\n" if $NET;
Again, note there is no communication like open( FH, "| ...") where nefarious users could attempt to slip in mesages like open( FH, "| `rm -rf /`") into the socket connection.

Usage ...

For a quick list of command line options run the account program with the "-help" flag. That output should look like the following:
USAGE: [options]

    [ -help ]          for this help message
    [ -version ]       for version number
    [ -debug ]         for debugging output
    [ -verbose ]       for verbose output (another alias for debug)

    [ -host ]          to define server's hostname 
    [ -port ]          to define server's port

    [ -network ]       to "fake" the network connection
                       don't actually connect, similar to `make -n install'
-debug -verbose
Either of these flags will display helpful messages as to what the program is actually doing and saying to the account server.

This flag will override the default setting of what the hostname is for the account server. This can be useful if working on an alternative server.

This flag will override the default setting of what the port is for the account server. This can be useful if working on an alternative server.

This flag will pretend to talk to the server, but not actually communicate to any server. Not even a socket is made, only a filehandle. This can be useful for debugging purposes and you don't actually want to talk to the account server and generate account requests.

As a Login Shell ...

The full pathname to this program should be allowed as an entry into the /etc/shells file. Finally, a UNIX account named `account' with the password `account' should be made with it's login shell defined as the entry in /etc/shells.

The Server

The server on the yp host should listen for and verify account requests from users. The client follows a process of data entry. The client sometimes asks the server whether the data entered is valid. For instance, whether the username does or doesn't exist, whether the account type jibes with the registrar data, whether the identification number does or doesn't exist, etc. The server takes these client tests and delivers messages slightly more verbose than "yes" or "no". The client then reacts accordingly. If the user survives the course of data entry, an account request is made and, if approproate, added the administrator's request queue.

The account request should include the password, but the client should have already attempted to crack. If the crack attempt passed, then the password is crypted and sent to the server. Yes, the password is sent "in the clear" but it is crypted - not plaintext.

Essentially, the server tests for username validity and prevents dupication. Assuming that account administration is done with yp and NIS, the server should be able to test for these requests and answer the clients tests. (It is not mandatory that you use yp and NIS, the server code is malleable enough to use whatever you'd like.)

Shared Resources

Since the client and server speak their own code with numeric status, it'd be nice to have them share a file that defined what the status were.

CCS Home | Feedback | Search | Online Help | Server Info | Modified Sep 7, 1997