388 lines
8.3 KiB
HTML
388 lines
8.3 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Local Security</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Security HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Physical Security"
|
|
HREF="physical-security.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Files and File system Security"
|
|
HREF="file-security.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Security HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="physical-security.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="file-security.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="local-security"
|
|
></A
|
|
>4. Local Security</H1
|
|
><P
|
|
> The next thing to take a look at is the security in your system
|
|
against attacks from local users. Did we just say <EM
|
|
>local</EM
|
|
> users? Yes!
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN281"
|
|
></A
|
|
>4.1. Creating New Accounts</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> Several good rules of thumb when allowing other people legitimate
|
|
access to your Linux machine:
|
|
</P
|
|
><P
|
|
>
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> Give them the minimal amount of privileges they need.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Be aware when/where they login from, or should be logging in from.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> 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.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The use of the same userid on all computers and networks is advisable
|
|
to ease account maintenance, and permits easier analysis of log
|
|
data.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The creation of group user-id's should be absolutely prohibited. User
|
|
accounts also provide accountability, and this is not possible with
|
|
group accounts.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="root-security"
|
|
></A
|
|
>4.2. Root Security</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> Several tricks to avoid messing up your own box as root:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>rm foo*.bak</TT
|
|
>, first do <TT
|
|
CLASS="literal"
|
|
>ls foo*.bak</TT
|
|
> and make
|
|
sure you are going to delete the files you think you are. Using <TT
|
|
CLASS="literal"
|
|
>echo</TT
|
|
>
|
|
in place of destructive commands also sometimes works.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Provide your users with a default alias to the <TT
|
|
CLASS="literal"
|
|
>rm</TT
|
|
> command to ask for
|
|
confirmation for deletion of files.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>
|
|
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 <EM
|
|
>sure</EM
|
|
> what needs to be done by root.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The command path for the root user is very important. The command
|
|
path (that is, the <TT
|
|
CLASS="literal"
|
|
>PATH</TT
|
|
> 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 <EM
|
|
>never</EM
|
|
>
|
|
include <TT
|
|
CLASS="literal"
|
|
>.</TT
|
|
> (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.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>.rhosts</TT
|
|
> file for root.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>/etc/securetty</TT
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>su</TT
|
|
> if you need to (hopefully over
|
|
<A
|
|
HREF="password-security.html#ssh"
|
|
>Section 6.4</A
|
|
> or other encrypted channel), so there is no
|
|
need to be able to login directly as root.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Always be slow and deliberate running as root. Your actions could
|
|
affect a lot of things. Think before you type!
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> 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. <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
> 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. <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
>
|
|
works well even in places where a number of people have root access,
|
|
because it helps you keep track of changes made.
|
|
</P
|
|
><P
|
|
> Although <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
>. This includes
|
|
most editors, for example. Also, a program as innocuous as
|
|
<TT
|
|
CLASS="literal"
|
|
>/bin/cat</TT
|
|
> can be used to overwrite files, which could allow
|
|
root to be exploited. Consider <TT
|
|
CLASS="literal"
|
|
>sudo</TT
|
|
> as a means for
|
|
accountability, and don't expect it to replace the root user and still
|
|
be secure.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="physical-security.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="file-security.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Physical Security</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Files and File system Security</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |