|
Abstract: |
|
Many
people and organizations are using the free operating system
UBUNTU. It is a powerful Linux distribution that has been
widely accepted. It comes with a rather unique root access
security architecture that most users accept out of the box.
The UBUNTU security approach is refreshing, but it might not
be the best approach for you. In this article, I want to
stimulate thought about the choice of your approach to using
UBUNTU and let you know that you can modify its security model
to best fit your needs.
Jim Burdick,
SNCSafeNet, www.sncsafenet.com. | |
Is UBUNTU’S Security Model Best For
You?
|
UBUNTU,
An Introduction
UBUNTU is an implementation (called a ‘Distribution’)
of the free and open source Linux operating system. Linux is a
UNIX-like multi-user, multi-tasking computer Operating System
written by a huge number of people from around the world.
UBUNTU can be installed in many configurations,
including some standard uses such as Desktop or Server and
innumerable customizations between. Because of its power,
security, reliability, price (it is free!), standardization,
and other characteristics, UBUNTU is used by a wide range of
people and organizations from hobbyists to large
organizations.
This
article is intended to question and perhaps resolve some
issues related to the built-in security of the UBUNTU system,
particularly focusing on sensitive environments such as
financial institutions.
|
|
Security Model
Overview
In
UNIX environments, the highest concentration of power is
called the super-user or ‘root’ account. This is the account
that is powerful enough to literally kill the system. It is
standard practice to use the root account only as much as
absolutely necessary. It may be obvious from this that one
should never use the root account for routine
activities.
In
most other UNIX and related operating systems, the root
authority is exerted simply by logging in as root and doing
the desired tasks. In this model, actions requiring root
authority and other authority are mixed together in many
cases.
The
UBUNTU distributions have a rather unique approach to use of
the root account. In the UBUNTU environment, access to the
root account is only allowed for temporary periods and then
only to a limited number of
users.
UBUNTU uses commands and files related to the ‘su’
command to control root access. The su command stands for set user or switch
user.
This and a series of related
commands control who can invoke root authority, when, how,
where, and perhaps in what
context.
|
|
|
Risk
Management
There
are many factors that govern how a security architecture
integrates with your organization. In fact many (most?) UBUNTU
users are likely to be private individuals, not an
organization. I do not aim this article toward private
individuals, but there is nothing in the article that isn’t
essentially true for the personal use of
UBUNTU.
For
organizations, the thrust of this discussion is related to
Risk Management. Briefly, Risk Management is a discipline that
recognizes that there are a lot of bad things that can happen
in this world, that these things can happen to you, and that
you have taken steps for those factors within your control to
limit the bad things to a level you can live
with.
When
you have identified a risk, there are only three things you
can do to that risk: avoid, assign, or accept.
You
avoid a risk by placing a control to cancel or eliminate the
risk. A firewall or antivirus program is intended to avoid
risk by eliminating certain
threats.
You
assign a risk by placing a resource under the control and
responsibility of another. This is what happens when we
purchase insurance (e.g. business interruption insurance) or
when we outsource, such as purchasing email service from a
vendor.
There
are two ways that we accept a risk. The first way is to
recognize a risk, either assign or avoid the risk, and then we
accept any risk that ‘falls through the cracks’ of what we
have done to assign or avoid the risk. The other way to accept
risk is to do nothing. This is not good. Risk acceptance is
the default. If we chose to do nothing, or if we aren’t aware
of threats that pose risk, we are accepting that risk
knowingly or otherwise.
This
article is specifically intended for people and organizations
that use UBUNTU and are in need of understanding the Risk
Management implications of this operating
system.
|
|
|
Possible Flaws
On
the surface, the UBUNTU model seems clever and effective.
However, there are potential flaws to the model. For instance,
every root access requires two password entries, one to log on
and one to verify the root task. Every password entry is a
risk-event, which is a potential for compromise.
Normal user access presents a risk to root access in
the long run as the compromised user password can be used
later for root access. This means an ordinary user account can
be used with no need to do a root function and compromised on
Thursday and the hacker can wait and use that same password
the next Tuesday and then ascend to
root.
Always remember that using the access of a normal user
to climb the trust ladder and become a privileged user has
long been a hacker tactic, and an effective tactic at
that!
Using
multiple trustees of root responsibility renders root access
only as strong as the weakest of the normal user account
passwords.
Distribution of root responsibilities and capability
complicates the detection and management of root attacks and
compromises.
|
|
|
Your
Specific Environment
It is
easy to talk about UBUNTU, or any operating system, and place
values on its security, but that security does not exist in a
vacuum. UBUNTU always exists in an environment. There is an
enormous difference between the lobby of a public library and
the inner bowels of a locked computer room. There are risks to
a laptop hooked up in a hotel that do not exist in a network
management shop. And there are other risks apparent in all
situations.
This
article can not cover all uses or environments and you
absolutely need to filter all evaluation through the lens of
you own implementations and
situations.
|
|
|
Special Thoughts About
Examiners
If
your organization is a financial institution that has
examiners looking over your security controls, you need to
take appropriate actions. Regulations require
that you show adequate control of privileged access. You need
to document how you control access, how you verify compliance,
and how you react to exceptions in operational
situations.
Understand that not all organizations fall under the
review of examiners, but if you do, this may help you see how
this topic is influenced by the
process.
If
you use the UBUNTU security model you need to track user
accounts of those individuals whose accounts are tied to the
sudo capability. This means that you need to track every
routine access as though it might escalate authority because
it could escalate.
The
good side of this is that UBUNTU’s approach allows sufficient
logging and support
programs to satisfy an examination, though you will need to
work to stay on top of things.
Another examiner-related issue is that the examiner
will expect policies and procedures to match the security
controls, be sure to develop or modify both policies and
procedures so that the entire control manages your risk and
controls it.
What
examiners really need to ascertain is that you:
§
recognize a resource in your environment that might
present risk,
§
you
have evaluated the potential risk,
§
you
have placed controls (that WORK!) on that resource,
§
the
controls are congruent to policies and
procedures,
§
you
test the controls to assure that they work,
and
§
you
understand and accept the residual
risk.
If
you meet these points, you will probably pass muster for an
examiner.
|
|
|
Recommendation
Okay,
so I’ve been in security for a long time, folks always ask me
what I recommend. I’ll tell you. But let me first share what I
say in this matter with the warning, that much (most!) depends
on your situation. But what I share will be generally
applicable.
First, everyone, no matter what, should assign a good,
strong root password and put it under the organization’s
password policy and procedure. You should never have a machine
in your environment that has an account you do not have
covered by your organization’s password policy and
procedure.
Make
appropriate changes to allow root login at the console. This
may also be expanded to root login using the SSH protocol, or
other encrypted equivalent. Authorized users have the root
password and use the root account to do privileged
tasks.
Unless the machine will not allow it because of an
error state, authorized root users should always first log in
using their personal account. This helps maintain a proper log
trail.
When
ascending from a user account to root account and privileges,
always use the “su –“ (called “su dash” or “su minus”)
command. Never, ever ascend to root by using only the “su”
command. The hyphen assures that the root account uses the
root environment instead of using the person’s personal
environment.
Make
a thorough review of those folks that require the root
privileges and give the root account access to only them.
Repeat this review on a regular basis according to corporate
policy and procedures.
If
some functions require a limited root access, such as user
account administration, use the UBUNTU root architecture for
these functions, limiting the access in every way that makes
sense, such as person, privileged activity, time of day,
connecting host, and appropriate logging. Review and repeat
the review of these assignments on a regular basis according
to corporate policy and
procedures.
And
as equally important as all the above, and probably before
accomplishing the above, create or update policies and
procedures to reflect these security
controls.
In
closing, I suggest that you use UBUNTU. Use it when it makes
sense for your operational requirements. But don’t feel tied
to its built-in security model. It is not a bad model; I just
don’t think it fits all
situations.
|
|
|
