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:
- their name,
- their ID,
- type of account (guest, major, graduate, faculty, staff, alumni)
- their username
- their password
- and a phone number
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:
- a regular expression defining what is acceptable as
input
- a string to be used as the prompt for the user
- a string to be used as an error message for the user
- an integer to define the minumum length of user input
- 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 - . '
$prompt_msg,
$err_msg,
$min_length,
$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: account.pl [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.
- -host
- 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.
- -port
- 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.
- -network
- 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.
