The security problems on Grex are a little different than those other systems have to deal with. On most systems, the first layer of security is preventing unauthorized people from logging in to the computer. But the whole point of Grex is to give away free accounts to total strangers. We want unauthorized people to log into our system.
From a security standpoint, this is both a blessing and a curse. On the positive side, we don't have to worry about mysterious people somehow logging into our system, because that happens all the time anyway. Some things that are considered secret on other systems aren't secret here.
For example, on most Unix systems, the login program responds to all errors with the message "Login incorrect". They don't differentiate between a bad login name or a bad password for a perfectly good login name, because they don't want to give hackers any clue about which login names exist. But Grex's login program has been modified to give messages like "Password Incorrect" and "No Such Login". Since anyone can get on our system, the full list of login names is no secret. Making the messages more helpful means staff gets fewer requests for help and the requests we get are less confused.
On the negative side, we don't have that first layer of security that other systems do, and we do still have things we need to keep secure. To understand our approach to security, it is important to first understand what our goals are. We need security for several reasons:
-
Protecting the privacy of users.
Our users should feel reasonably confident their mail and their files are not being read by other people. They should also know that other people can't log into their accounts and pretend to be them. To ensure this, we need to do our best to protect the security of the passwords, and of the root account (which has access to everything).
-
Restricting net access.
We are happy to give people anonymous access to our system, and we are prepared to deal with having mysterious people doing mysterious things on our system, but most of the rest of the Internet doesn't feel this way. Because of this, we allow anonymous people to come into Grex from the net, but we restrict who can go out to the net from Grex. This discourages people from using Grex as an anonymizer while attacking other systems. Having those restrictions means we must enforce them. This is done on Grex through modifications of the Unix kernel.
-
Prevent resource hogging.
Grex has very limited resources spread over an awful lot of people. One user hogging a disproportionate amount of our net bandwidth or CPU can prevent hundreds of other users from using Grex at all. Unfortunately, technical fixes to these kinds of problems usually cost too much in overall system performance, or in limiting legitimate use of the system to be desirable. In most cases, we deal with such problems on a case-by-case basis, often simply by talking to people instead of installing technical fixes. For example, we don't use the disk quota systems built into SunOS because they slow down the system too much. Instead we manually send mail to people asking them to reduce their usage, and manually reduce disk space for any users who aren't cooperative. However, when dealing with things manually becomes too much of a burden on our limited staff time, we do install hard resource limits, notably we (mainly Marcus Watts) have modified our mail software to limit the sizes of mailboxes.
-
Prevent harassment of users.
Occasionally one user will decide that he or she needs to interfere with another user's use of Grex, perhaps by flooding their screens with messages or otherwise messing things up for them. This kind of behavior is never welcome on Grex, and we believe in providing people with tools that allow them to shut out unwelcome messages. The standard Unix messaging programs "write" and "talk" have been modified here to limit abuse.
-
Tracking problem users.
From time to time we have users who come in and "try the locks," that is, attempt to break our security. We consider such people rather puzzling. Many of them pretend to be some kind of "information freedom fighters," but the only secrets on Grex are the personal mail and files of our users. Taking advantage of the free access we give away to try to pry into the private business of other users, sneak into other systems on the net, or harass people is downright rude. So we like to be able to track such rude people and turn them in to the proper authorities for suitable chastisement. That means we log everything, monitor the logs continually, and keep the logs for a long, long time. If you want to "test the locks" purely to satisfy your own curiosity, please do send mail to help@grex.org first, and please do advise us if you notice any problems. Thanks.
In general, however, we do not believe in keeping our security arrangements secret. This is why we have published detailed descriptions of most of our security arrangements on the web. We also maintain a public discussion forum on technical issues related to the operation of Grex in the garage conference. As a general principle, security by obscurity is generally very poor security. People who want to crack your security to steal things are often highly motivated, and secrets will leak out. By publishing our methods, we put nice people who are merely interested in security systems on an equal footing with the bandits. The nice people will probably let us know if they notice any weaknesses. The bandits probably won't. Thus publishing our security arrangements should make them more secure in the long run.
Grex runs SunOS 4.1.4, but has made many modifications to the basic software. Other technical notes give more detailed information about security-related aspects of these modifications to Grex:
- The Password Database - description of how passwords are stored and accessed.
- The Kernel Blocks - descriptions of kernel modifications to restrict outgoing net access.