Several days ago, I resubscribed to linux-kernel after a bit of a hiatus.
Before resubscribing, I sent a note about what was the reaction to the
UNIX Review article about "Security: UNIX vs Mainframes". At that time,
I didn't have the magazine issue in front of me, but it is November 1996.
Anyway, since that time, I have received only one private e-mail about
this article, and have seen no discussion in linux-kernel... So what
follows is a brief summary of that article, and I encourage the "core"
developers to consider adopting something along these lines rather than
to continue cluttering up the kernel space with stuff (or that's how it
sort of appears to me)... I believe that with an architected solution,
along the lines of "accepted practice", we can really really shine!
Paraphrased and summarized from:
Security: UNIX vs Mainframes
by Dorin Miller, Pg 63-66
UNIX Review November 1996
"UNIX security challenges stem from its architecture."
The author then goes on to point out that because UNIX was designed to
provide openness, easu connectivity, simple access to data, and control
over the operating system, it is considered weak in security, and has
inherent security flaws. Rather than using a proactive security model,
as does the MVS operating system, UNIX apptemts to detect actions after
they occur, attempt to plug security holes as they are discovered, and,
in general fall short of ever being provably secure.
"Surprisingly, native MVS contains far less security than native UNIX."
MVS, by design, has almost no native operating-system security. Instead,
it "cleverly acknowledges that security is important enough to be handled
by an external facility that specializes in and provides the right type
of granularity and scalability to facilitate flexible and robust security
implementations". MVS identifies critical operating system events at
security-sensitive junctions, and uses a Security Authorization Facility
(SAF) to call external security products. From the MVS perspective, the
result of the SAF call is either to allow or disallow further processing
of the request.
Several issues and "complications" (bad) are identified with the UNIX
model (several of the same themes are currently the topic in the
"link(2)" discussions), and comparative MVS solutions are discussed.
Also the "control and the problem with root" issue is addressed, which
include the behaviors of create, alter, chmod, chown, and ACLs, etc,
concluding with "The intensity of powers concentrated within root makes
it the most prone to abuse". So...
"How can UNIX security be improved?"
The author suggests an approach. Do not build additional security within
the constraints of the UNIX design. Do not engage in more strenuous
attempts at discovering breaches of security. None of these address the
limitations directly. Rather, use something more along the lines of an
MVS SVC table (the UNIX syscall table) be used as a central junction for
redirecting security-sensitive decisions. Use "soft-hooks".
"Applying dynamic soft hooks to address UNIX security vulnerabilities can
carry significant benefits."
For example, not only can such a solution prevent/allow who can become
root, but it can further limit what powers that "person as root" has.
Different administrators some can define users accounts, and others can
manage system activities, neither of which can change/modify audit logs.
"For such a solution to be practical, it must use an architecture that
minimizes the dependence on internal system functions, and does not
require a kernel rebuild".
Today, Linux, with its wonderful modules, etc, etc, seems to beg for such
an approach. Further, life is simplified for the kernel writers because
all they need to do is say "is this ok?", and then get on with it. The
rules for "is this ok?" are no longer tied to the kernel, but rather can
be managed by local configuration desires. The conclusion of the article
is obvious (doh!):
"As long as these challenges are met and the right architecture is put in
place, UNIX can be as secure as MVS."
---- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------