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 it gets 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:
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).
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. Having those restrictions means we must enforce them. This is done on Grex through modifications of the Unix kernel.
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 usual 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.
Occasionally one user will decide that he or she needs to interfere with another users 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.
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 secrets 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 staff@cyberspace.org first, and please do advise us if you notice any problems. Thanks.