next up previous contents
Next: 2.4 The SysHackAdminer Up: 2. The SysHackAdminer Previous: 2.2 The Hacker

Subsections

2.3 The System Administrator

I hope you're not pretending to be evil while being secretly good

That would be dishonest2.2

The system administrator is the person charged with the upkeep and stability of a machine. There is not much formal training of system administrators, especially with a focus on security. Most system administrators start off as programmers and are seen to be quite intelligent and knowledgeable on computers. They are then thrown into the deep end, and they have to learn very quickly. The last thing on their minds is security. They are too busy keeping the system working and the users happy to worry about external forces of complication on their lives. That is, until they get hacked.

2.3.1 Traditional roles

The system administrator's (sysadmin) focus was mainly on keeping the system working and the users happy. His job description also included the creation of new user accounts, adding software the users required and being a support-line for users with problems on the system. Most organizations have/had one system administrator who has to tend to all the problems on the network. Most of the time, he had so much other work to do that security was not even an afterthought.

Security incidents on the Internet increased. Organizations realized that some form of security was required for the protection of the organization's data. The system administrator's job description was stretched even further to include adding security. Being overworked already and having other mission-critical roles, security remained ignored but perhaps to a lesser extent than before. We continue to discuss some of the security strategies that have been adopted by system administrators in attempting to put some barrier up.

2.3.2 Security Strategies

2.3.2.1 No security

In this model, very little or no security is employed. This is either in the hope that no one will notice or justified by some excuse about trust. If someone happens to notice, the hope is that he will be friendly and not destroy anything. A very irresponsible model.

2.3.2.2 Security through obscurity

This model is in very wide use especially among small organizations. They cannot afford to pour much money into security. Their model is based on the belief that because they are small and insignificant, hackers will not notice them. This has been proven wrong on many occasions. Hackers tend to go for the smaller organizations with little security as a spring-board towards attaining the ``prized calf''.

Another variation of this model is not fixing the security but making it hard for those on the outside to get inside. While this model works very well if those on the inside can be trusted firstly to not break things themselves and secondly not to pass information to those on the outside, it falls apart completely when those on the outside get a foothold on the inside.

2.3.2.3 Security through fear

This model is applied in many institutions, especially universities. Guidelines for use of the network are laid out and those who are to use the network are required to abide by them. While user policies are good in regulation of activities and in the protection of the university legally should someone break the rules, they are not much of a security measure. The classic example of the use of this model is threatening expulsion from the university if ever an attempt is made to bypass the security measures that have been implemented. As could be guessed, this model fails badly when someone from the outside, not bound by the user policy, attempts to break in.

2.3.2.4 Security through backups

Security through backups is a good security measure. The philosophy for this kind of model is that if the system is in any way damaged, important information can be restored from the backup. One of the biggest problems with reliance on this form of security is that it provides a false sense of security. Although the model is adequate most of the time, under some conditions it falls apart. The model fails when the backups made have corrupted information. Consider an intruder who breaks in but is only noticed three months afterwards. If the intruder poisoned the information being backed up from the onset, three month old data or information may have to be used. Another complication is that it may not easy to determine the date the backed up data was poisoned.

2.3.2.5 Security through passwords

This security measure is also a good one. Security is ensured by forcing users to choose passwords which cannot be easily guessed. Intruders are deterred as they cannot easily guess the passwords. This model, like the security through backups, gives a false sense of security. Administrators are usually of the mindset ``We have good passwords, we are secure'' which could not be farther from the truth. The model works perfectly if the system neither accepts nor sends mail and has no daemons running. In other words, it works perfectly for single user machines which are not connected to networks. A potential point of failure on multiuser machines connected to a network is the very software that implements the security philosophy through passwords e.g. the login program.

2.3.3 System Administrator Ethics

The system administrator is in a naturally elevated position. He possesses super-user privileges. These privileges are for use when resolving problems that exist on the system being managed. The privileges the administrator possesses can also be abused. Herein lie our ethical considerations.

2.3.3.1 Abuse of privilege

Below we describe some actions that the system administrator may perform either as part of his role set or in the abuse of his privileges. We describe when it is allowed and ethical for a system administrator to perform these actions. This is in attempt to highlight times and situations when such actions are unethical and not allowed.

2.3.3.1.1 User Impersonation

There are circumstances when a particular user's problem cannot be resolved from super-user mode. If the user configured his start-up files incorrectly, the exact location of the problem may not be easily apparent. It may therefore be necessary for the administrator to login as the user concerned, to get a closer look. The scenario we have just described is one of a few instances when it is ethical and correct to impersonate users, to correct problems. Unethical behaviour includes impersonating users to carry out illegal activities. When the activities are traced, the impersonated user is seen to have carried out such offences.

2.3.3.1.2 Termination of user processes and sessions

If a mission critical system requires 80% of the processing power of the server machine and the only way to obtain these resources is to kill user processes, the administrator is required to do so. Abuse of privilege would be killing user processes and session for no apparent reason. Sessions and processes of users who frustrate or upset the administrator may be killed without reason. It should be obvious that this too is abuse of privilege.

  
2.3.3.1.3 Removing user files

Some will claim that because the administrator can have no knowledge of what is contained in a file, he is not allowed to remove it unless requested to do so. While this view is reasonable, there are circumstances where the administrator has to remove user files without their concent. If one particular user is hogging all the space available on the machine, and in so doing is disturbing the correct functioning of the system, his files may be removed to restore the system to normal working order. Anything that inconveniences either the system or the general user population can be safely terminated without breaking any moral or ethical rules. An administrator removing user files to make space for his own junk files is clearly acting unethically.

2.3.3.1.4 Hogging system resources

There exist times and conditions when system resources have to be used for mission critical or system purposes. Under such conditions, the administrator is allowed to hog resources. An administrator hogging system resources to further no purposes but his own is not acting ethically.

2.3.3.2 Privacy issues

Privacy is guarded and provided for by a bill of rights in most civilized countries. Although not all real life privacy issues cannot easily be clearly mapped into the computing world, there are some which can be mapped easily. Unix allows users to set permissions on files that allow no-one but the users to read and write to them. These private files and user electronic mail messages are regarded by many as inviolable property. Let us look at situations where an administrator may be allowed to violate user privacy.

2.3.3.2.1 Going through users' electronic mail

Security conscious organizations usually force the users to adhere to a clearly defined user policy. To this end, users sign a document promising adherence to the defined policy. In this document is usually a clause allowing the organization to peruse users' private files and mail if the users are suspected of breaking policy or illegal activity. In these situations, the administrator is permitted to look through users' electronic mail. Not many similar conditions exist.

2.3.3.2.2 Going through users' files

This activity is as serious as reading users' electronic mail. The same conditions apply for allowing the system administrator to violate user privacy in this way. In 2.3.3.1.3 we dealt with deletion of user files. An administrator may choose to read through files in the user's space to determine their importance. When files need to be deteled, those that do not seem important are deleted. This theory fails when the value of the information is introduced. The administrator, even after reading a file, can never adequately determine its worth to the user. Although the administrator's intention may have been only to help, the invasion of privacy may be seen as an additional offence.

2.3.4 Security Obstacles

2.3.4.1 Trust

All networking is based on some form of trust or another. This trust is an obstacle to security. The best example of this is the Internet itself. Trust was needed for the sharing of communication and security was therefore ignored. When it was noticed that not all to whom trust was extended were trustworthy, attempts were made at security. A lot of organizations claim to trust their employees or students, and so implement little in the form of security measures. This model is closely related to ``Security through fear''. The trust translates to ``we trust you and if we find that we cannot, we will punish you''. Security depends on, perhaps for a little while, doubting someone's claims and motives. This is the reason we have passwords.

2.3.4.2 Usability

Usability is probably the greatest obstacle to security. A lot of people are happy sacrificing security to get easy use of the system. The argument is that computers are meant to be useful, and in a relatively easy way. By implementing security, the claim is that usefulness and ease of use may be compromised and security is therefore overlooked.

Although ease of use is appealing and a big reason we use computers, it should not be elevated above security concerns. We use computers to perform tasks that advance us and perhaps put us ahead of the competition. The information that puts us ahead of the competition is therefore a very important part of our being ahead. The protection of that information should be our foremost concern.

2.3.5 The change

From our discussion above, it should be apparent that a change of paradigm is needed. Not only do system administrators need to be trained both in the workings of the system, but also about security issues. We have also observed that general security models which are applied by many a system administrator are inadequate for the protection of valuable information. A change to the current system administration person or model has to occur, especially with the increase in computer related crime. We therefore propose a new person, the SysHackAdminer. While he may perform system administration roles, his primary concern is the security of the information kept on systems.


next up previous contents
Next: 2.4 The SysHackAdminer Up: 2. The SysHackAdminer Previous: 2.2 The Hacker
Shaun Bangay
1998-11-19