4. Local Security

The next thing to take a look at is the security in your system against attacks from local users. Did we just say _local_ users? yes.

Getting access to a local user is one of the first things that system intruders attempt, while on their way to exploiting the root account. With lax local security, they can then "upgrade" their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump.

Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or have no contact information for is a very bad idea.

4.1 Creating New Accounts

You should make sure to provide user accounts with only the minimal requirements for the task they need to do. If you provide your son (age 10) with an account, you might want them to only have access to a word processor or drawing program, but be unable to delete data that is not his.

Several good rules of thumb when allowing other people legitimate access to your Linux machine:

• Give them the minimal amount of privileges they need.
• Be aware when/where they login from, or should be logging in from.
• Make sure and remove their account when they no longer need the access.

Many local user accounts that are used in security compromises are ones that have not been used in months or years. Since no one is using them they provide the ideal attack vehicle.

4.2 Root Security

The most sought-after account on your machine is the superuser account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea.

Several tricks to avoid messing up your own box as root:

• When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: ie, you are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak" and make sure you are going to delete the files you think you are. Using echo in place of destructive commands also sometimes works.
• Some people find it helpfull to do a "touch /-i" on their systems. This will make commands like: "rm -rf *" ask you if you really want to delete all the files. (It does this by your shell resolving the "-i" file first, and treating it as the -i option to rm.) This will not help with rm statements with no * in them. ;(
• Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are sure what needs to be done by root.
• The command path for the root user is very important. The command path, or the PATH environment variable, defines the location the shell searches for programs. Try and limit the command path for the root user as much as possible, and never use '.', meaning 'the current directory', in your PATH statement. Additionally, never have writable directories in your search path, as this can allow attackers to modify or place new binaries in your search path, allowing them to run as root the next time you run that command.
• Never use the rlogin/rsh/rexec (called the r-utilities) suite of tools as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a .rhosts file for root.
• The /etc/securetty file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles(vtys). Be very careful of adding anything else to this file. You should be able to login remotely as your regular user account and then 'su' if you need to (hopefully over ssh or other encrypted channel), so there is no need to be able to login directly as root.
• Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type!

If you absolutely positively need to allow someone (hopefully very trusted) to have superuser access to your machine, there are a few tools that can help. Sudo allows users to use their password to access a limited set of commands as root. This would allow you to, for instance, let a user be able to eject and mount removable media on your Linux box, but have no other root privileges. sudo also keeps a log of all successfull and unsuccessful sudo attempts, allowing you to track down who used what command to do what. For this reason sudo works well even in places where a number of people have root access, but use sudo so you can keep track of changes made.

Although sudo can be used to give specific users specific privileges for specific tasks, it does have several shortcomings. It should be used only for a limited set of tasks, like restarting a server, or adding new users. Any program that offers a shell escape will give the user root access. This includes most editors, for example. Also, a program as innocous as /bin/cat can be used to overwrite files, which could allow root to be exploited. Consider sudo as a means for accountability, and don't expect it to replace the root user yet be secure.