New Massive Botnet Twice the Size of Storm (Dark Reading) [LWN.net]

New Massive Botnet Twice the Size of Storm (Dark Reading)

Posted Apr 7, 2008 15:59 UTC (Mon) by elanthis (subscriber, #6227)
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)

How does it help?  SELinux policies for desktop users, including most corporate desktop users,
allow any general process to run and have network access.  The targeted policies lock down
risky client apps that are known to the policy (the system-install Firefox, for example) but
not apps the user installed into their home directory (including a user-downloaded Firefox
binary).

The super restrictive SELinux policies that would actually solve these problems aren't in use
because even corporate users have at least one or two custom in-house apps that they need to
run, and figuring out how the heck to give those things proper permissions in SELinux is still
way too hard for the average IT idiot to figure out.

(Log in to post comments)

SELinux: Excessive Complexity and Lack of Utility

Posted Apr 10, 2008 16:29 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

"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