From: Rick Moen rick@linuxmafia.com
Newsgroups: linux.astcomm.net
Subject: Re: System Security
Date: Sun, 18 Aug 2002 22:55:11 +0000 (UTC)
Organization: If you lived here, you'd be $HOME already.
User-Agent: tin/1.5.13-20020703 ("Chop Suey!") (UNIX)
(Linux/2.2.19 (i686))
Chris Olson chris@astcomm.net wrote:
> Rick, with your experience, I would be *very* interested
in reading
> your overview of how you go about securing a multi-user
linux system.
> Things such as directory permissions, what processes are
safe to run
> and which one's aren't, what users and groups are allowed to
do what
> (keeping in mind that a goodly portion of attacks on unix
systems come
> from the *inside*), network security, and in particular,
your use of
> sudo on the system. A single user system, I would think, you
would
> treat differently.
I can't think offhand of anything special I do differently
on
single-user systems. It's pretty nearly the same, in my view. I
might
think of some significant differences later, but can't think of
any
right now.
Security is a topic that tends, in practice, to go badly off
the rails
for a couple of reasons, in my experience. (1) Many people
seek
security as a product/technique. They want to _add_ security.
That's
not how it works: Security is process, not product.
The process in question involves these sorts of things:
o asset identification
o risk assessment
o defence in depth/prevention
o detection
o identification/analysis
o countermeasures/response
o recovery
o reporting
In other words, you aim to know what risks you're taking, what
the
possible damage is, how to mitigate or prevent it, how to detect
if a
loss/damage or attack is underway, how to respond, how to
recover.
Getting a handle on these things results in what is called a
_policy_,
as to how you (or your company) will operate. What we call
"security"
is (then) the implementation / modification of that policy. Which
is of
course an iterative process -- in as much as it's process, not
product.
When I say "loss/damage", I don't mean just from deliberate
break-ins.
The lossage could be data corruption, loss of personal or
business
reputation, misappropriation of resources, information
leakage
(including privacy violation), denial of service, and
unauthorised
escalation of privilege by users or remote parties. Security
is
concerned with all such matters.
(2) Security discussions tend to attract gadget freaks -- by
which I
mean people whose fundamental interest lies in playing with
neat
mechanisms. Playing with technology is fine, but such people will
tend
to want to throw _more and newer mechanism_ (especially software
or
algorithms) at any problem, despite the fact that generally
simpler,
more battle-proven solutions are greatly preferable.
I make this point in my rundown on all ftp daemons known to be
available
for *ix, at http://linuxmafia.com/pub/linux/security/ftp-daemons
.
To know what's at risk on your system and what lossage /
attacks /
threats are possible, your first requirement is of course to
understand
what's going on, on your host and (if applicable) attached
networks.
> An example: 'useradd' used with the -m flag in Debian
systems, by
> default, creates a /home/~user directory with chmod 755
permissions.
> Redhat, OTOH, is configured to create the user directory
chmod 700.
Which one is desirable and the other undesirable is a question
you can
answer (for your local system) only after understanding group
membership
and umasks (including the shell built-in of the same name). Users
will
want to allow no more access to their files than their
_personal_
policies dictate -- but also no less access, either. Fortunately,
they
can override system policy in their directories and shell login
scripts.
> And thinking about sudo a little bit, I can see where it
may be useful
> for me to be able to access some processes as root from my
normal user
> account, but I'm still a little uncomfortable giving other
users
> access to *any* of the root processes on a machine that I
own unless
> I'm supervising what is going on.
The applicability of sudo isn't limited to just root
authority. It's a
generalised tool for granting _any_ sort of privileged access to
a user
or group of users. Naturally, you must configure /etc/sudoers
very
carefully, and the /usr/bin/sudo binary is itself (being
SUID-root) a
potential point of attack by the Bad Guys.
But to address your point directly, there are things that can
normally
be done only with root authority that are not obviously harmful.
For
example, a user might ask you to serve up primary DNS for his
personal
domain. So, you might put a copy of his zonefile(s) in /etc/bind,
chown
them to his username, and add an entry to /etc/bind/named.conf .
He can
then edit his zonefiles as needed -- but can't restart the
nameserver,
to load his changes. Every time he needs to do
"/etc/init.d/bind
restart", he has to bother _you_ to do it as root -- even though
that's
basically harmless. So, you can solve that problem with an
/etc/sudoers
entry that lets the user wield root authority _only_ to do
"/etc/init.d/bind restart".
Many other times, you stop and think: Why am I having to
perform this
function as root? For example, do you have to "su -" to read or
write a
floppy? To use the modem? To edit system HTML files? Often as
not,
you can reflect for a moment and use group memberships and SGID
bits on
directories and files, or just chowning things, to eliminate
the
necessity. But you have to understand the ramifications of what
you're
doing.
> ...I've found two different unix admins of equal
experience will
> invariably have differing views of how to set up a
system.
Asking n admins will get you at least n+1 opinions. However,
those will
be differences on details. I've tried to articulate, above, the
sorts
of guiding principles that probably everyone can agree upon.
Here's an article I wrote on a Linux security topic, that may
be useful:
http://linuxmafia.com/~rick/essays/attacking-linux.html
--
Cheers, "Please return all dogmas to their orthodox
positions."
Rick Moen -- Brad Johnson, in r.a.sf.w.r-j
rick@linuxmafia.com