I found myself unwillingly in a discussion about security or lack thereof. The security of certain tools that I have written and rolled out to about 1,000 workstations and servers.

The details: I create and support a RHEL based operating system that’s installed throughout campus. Its right under 1,000 systems and is built to scale to many more. A Systems Administrator can install trusted, supported versions of the product as well as random folks in dorm rooms can install an untrusted, unsupported setup. (Although, the latter has declined quite a bit.) If you are a Systems Administrator you have write access to a directory in AFS where you can put a config file that controls dynamic generation of a Kickstart file for a specific system. Then you can install said system. There are, roughly, about 50 such persons. Our security officer approves these persons, not me.

So far so good. Systems Administrators have a pretty cool way to install a “supported” system in a completely automated way. The config files allow for a very highly flexible and configurable installation. Then comes the fun part. There is a default root password and administrative user list that must be applied to the system. Each group on campus can also have their own root password and user list that overrides the defaults. These, mostly the root MD5 hash, are considered secret and are not shared. Being that MD5 hashes are easily brute forcible, they are encrypted. For each of my machines, if its s trusted machine it must have the write root password and users list including needed updates. If its an untrusted machine it must not have access to the secret information. Finally, the installer may have root access on the system, but that does not mean he or she knows the root password.

This problem boils down to distributing a group name (like ‘foolab’) and an encryption key. Once you have this information the encrypted blobs are world readable in AFS and are easily applied to the system with a little sysadmin know how.

My system works with a registration database and public/private RSA keys on the machines. Once installed a machine creates its keys and registers with the database. Then, that machines public key, signed by its private, serves as a positive identity that cannot be faked.

But, that’s not the problem. The problem is when machines register. Even though there are a specific set of circumstances that must be met before a machine will be allowed to register, it is still a completely automated process. In that window before a machine is successfully registered I do not know if that machine is the machine setup and installed by the Systems Administrator or if it has been replaced or spoofed with an imposter.

The system is completely automated. It cannot be secure. Push connections from the database or pull connections to the database. It cannot be done. There is obscurity involved. It bothers me. Its also based on the same systems used for other UN*X systems on campus for years. Its flawed. Asking for someone to have a little fun.

As a friend of mine states, and you’ll not find a better definition of security anywhere, security is based on one of three things. 1) You know something. (A password.) 2) You have something. (A key for your car.) 3) You are something. (A Systems Administrator.) Before machine registration none of these are true. You may generate all the RSA keys you want, the above must be true for the database and the client.

In such an automated process the only thing you can do to make the system end to end secure is to have one of those 50 or so Systems Administrators come by and bless the machine. (Also known as make_me_not_a_virgin.py.) This operation makes the system secure because the System Administrator (You are something) takes the public key for the machine and puts it in an AFS ACL’d place where only Systems Administrators can write and is loaded into the database. Then you have something. The database can securely recognize the machine and feed the machine the needed secrets in an encrypted way that only the machine that was blessed can decrypt.

The trick is to make that script you run to bless a machine as slick as possible. The goal being to make it easy. The downside is, how to convince folks that machine blessing is good. Having to touch each machine is quite frowned upon.