| |||||||||||
SELinux: Excessive Complexity and Lack of UtilitySELinux: Excessive Complexity and Lack of UtilityPosted Apr 10, 2008 16:29 UTC (Thu) by AnswerGuy (subscriber, #1256)In reply to: New Massive Botnet Twice the Size of Storm (Dark Reading) by skvidal Parent article: New Massive Botnet Twice the Size of Storm (Dark Reading)
"The point is that selinux helps [with] this problem in ways that other tools/oses[sic] cannot." If that's your point then you are missing the point. Please point to any case studies that describe real-world usage of SELinux on desktop (and workstation) systems and which exemplify how SELinux has actually helped. (That's just one part of your assertion. I contend that I haven't seen SELinux help with this class of problems and even if SELinux is capable of implementing meaningful measures for desktop users that its complexity precludes widespread use). The second part of your assertion is that "other tools" (and OSes) cannot address these problems. Read about systrace and then review a few dozen other approaches (LIDS, AppArmor, GRSecurity patches, RSBAC, SMACK, LOMAC, etc) and show how each and every one of them is incapable of helping in the ways that you claim SELinux could. My point is that SELInux is inherently complex (read this if you care to disagree. It's actually among the better summaries that I've read!) I disagree with those who claim that SELinux is only highlighting underlying complexity. The fact is that SELinux *adds* layers of complexity by introducing concepts (objects, labels, types and domains, classes, roles and subjects, and permissions ... with different sets of permissions for each class) that simply don't exist in the UNIX model. Creating a security policy for a specific application suite requires details knowledge of that application's internal architecture (must make sure that all its components end up in commonly accessible domains and classes and that each has the necessary permissions to access each other subsystem with which they interact). SELinux adds -Z flags a significant number "standard" UNIX/Linux commands such as ls and ps. That's a purely arbitrary switch designation chosen because none of the common utilities in question happened to use it. As someone who has worked as a sysadmin for over a decade, and professionally taught advanced systems administration classes, I think I have a pretty solid basis to form an opinion regarding a system's complexity. I have a very good idea of how long it would take to teach someone to be minimally functional (not even truly competent, just minimally functional) in the use of SELinux. I can teach the basics of reading strace output (and in capturing it from running daemons, writing strace wrappers, and even using the obscure /etc/initscript) in about two hours. The pre-requisite to that about one hour covering the basic system call process life cycle (fork(), execve(), exit(), wait()/waidpid(), SIGCHLD, etc.). In that time I could probably just barely cover a conceptual overview and terminology primer for SELinux. (In one of my classes taught around the time that RHEL4 was just being released it cost about an hour of class time just demonstrating how to bypass SELinux during the standard "recover from a lost root password" exercise; SELinux doesn't secure your system against booting with init=/bin/sh --- but it does add some cumbersome obscurity to it unless you also add selinux=0).
Jim Dennis
(Log in to post comments)
|
|||||||||||