From: Rick Moen
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 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 .

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

> ...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:

Cheers, "Please return all dogmas to their orthodox positions."
Rick Moen -- Brad Johnson, in r.a.sf.w.r-j