Messages in this thread |  | | From | LD Landis <> | Subject | Linux Security: An Appeal | Date | Tue, 17 Dec 1996 10:28:12 -0600 (CST) |
| |
Hi,
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) -----------------------------------------------------------------------------
|  |