| |||||||||||||
|
| |||||||||||||
New Massive Botnet Twice the Size of Storm (Dark Reading)New Massive Botnet Twice the Size of Storm (Dark Reading)Posted Apr 7, 2008 15:29 UTC (Mon) by skvidal (subscriber, #3094)In reply to: New Massive Botnet Twice the Size of Storm (Dark Reading) by Cader Parent article: New Massive Botnet Twice the Size of Storm (Dark Reading)
Well, to be fair. A linux user running selinux might have a somewhat harder time doing this. There are many many advantages of selinux for combating things like this botnet. I've not always been thrilled with selinux but it does certainly help deal with crack like this.
(Log in to post comments)
New Massive Botnet Twice the Size of Storm (Dark Reading) Posted Apr 7, 2008 15:59 UTC (Mon) by elanthis (subscriber, #6227) [Link] 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.
New Massive Botnet Twice the Size of Storm (Dark Reading) Posted Apr 7, 2008 16:13 UTC (Mon) by skvidal (subscriber, #3094) [Link] Creating policies really isn't that difficult. There are a number of good beginner guides to making selinux policies for specific apps and uses. The point is that selinux helps this problem in ways that other tools/oses cannot.
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
New Massive Botnet Twice the Size of Storm (Dark Reading) Posted Apr 7, 2008 16:14 UTC (Mon) by copsewood (subscriber, #199) [Link] Not sure yet that Selinux is useful for general purpose desktop computing or IT research computing where end users need 50 general purpose applications and another 50 which few other people use but which need to be changed on a daily basis. Selinux might be useful for locking down a server application the resource requirements of which can be carefully studied and monitored, but most end users have no idea which files they need to execute and which files and ports these executables need to be able to access in which (read/write/delete/modify) modes. Most end users are also likely never to want to acquire this knowledge. I can imagine some end users who only ever use software in a standard distribution and single distribution repository where the selinux policies are maintained by all the application packagers, whom selinux would theoretically be able to help. But when they have to install a new device driver or any unpackaged application that requires the tar/make/configure dance they will be well and truly blocked and then they are likely to get fed up and use a system that isn't so well locked down. The problem Selinux will probably never solve is knowing the difference between low level access from users doing what they know they want to do and low level access happening as a result of attacks that users didn't want to happen. Perhaps having a selinux protected main system plus virtual machines usable for quick and dirty application installs but to which no important data is entrusted would go further, but this still doesn't solve the device driver installation requirement where low level access is needed.
|
|
||||||||||||