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 account 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 for whom you have no contact information is a very bad idea.
4.1. Creating New Accounts
You should make sure you 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 him 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 you remove inactive accounts, which you can determine by using
the 'last' command and/or checking log files for any activity by the user.
-
The use of the same userid on all computers and networks is advisable to
ease account maintenance, and permits easier analysis of log data.
-
The creation of group user-id's should be absolutely prohibited. User
accounts also provide accountability, and this is not possible with group
accounts.
Many local user accounts that are used in security compromises 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 root (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. Even small mistakes made while logged in as the root user can
cause problems. The less time you are on with root privileges, the safer you
will be.
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 globing: e.g., if you want to do rm foo*.bak, 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.
-
Provide your users with a default alias to the rm
command to ask for confirmation for deletion of files.
-
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
(that is, the PATH environment variable) specifies the
directories in which the shell searches for programs. Try to limit the command
path for the root user as much as possible, and never include . (which means "the current directory") in your PATH.
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 suite of tools (called the r-utilities) as
root. They are subject to many sorts of attacks, and are downright dangerous
when 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 wary 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 Section
6.4 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 root 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 successful
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, because it helps you 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 root access
to a user invoking it via sudo. This includes most
editors, for example. Also, a program as innocuous 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 and still be
secure.
