2011/5/9 Miloslav TrmaÄ <mitr@xxxxxxxx>: > 2011/5/10 Stephen John Smoogen <smooge@xxxxxxxxx>: >> Let's make this simple: >> >> FAQ: How can I make my system unusable? How can I create a denial of service? >> >> Answer: On default systems there are multiple ways to do this, please >> choose one or more of the following: > > That's all true, on the other hand there are countermeasures > available; in larger organizations the countermeasures are documented, > configured on each system, and their presence is periodically > verified. 1) Running Fedora on large organizations is usually heavily frowned on. Been there, fought that battle, realized it was a lost issue, moved on. If Fedora is run, it always seemed to be more sandboxed away from production than all the more vulnerable systems. 2) The number of large organizations where RHEL, SuSE, etc where it is documented is very high. The number where it is configured is no where near as high. The place where those configs are turned off because some sysadmin hates being told how to set up his stuff is probably just as high. 3) The number of Unix sysadmins who I have met who work for such large organizations who HAVE no idea about any of those problems is also very high. I have gone through too many firedrills about one or more of the local DOS's because some guy who had been a sysadmin for 10+ years all of a sudden discovered his bullet proof Unix system can be brought down by it. And then I spent a long time finding out that all of the production software depended on something that the fix cleaned up. 4) The fixes to any of those problems are usable but usually end up breaking something else. Why did we have to turn off fork bomb protection? Because "big named business software package" broke because it was enabled. Make /var/tmp and /tmp separate partitions.. oh look another "big named software package uses hard links with its software in /opt to /tmp and won't work." Put mount options on /dev/shm and poof "all that web stuff this server is supposed to run doesn't." 5) The /dev/shm problem (and now /run/files) has been around for a LONG time. I have been finding root kits there since 2002 (and remember it being mentioned a lot earlier). Making it so it wasn't world writable but say group writable never seemed to fix the issues because the exploitable programs always needed to be in the groups to use it. The real world rule of security is "Unless a problem is fixed out of the box, it is not going to be fixed." Worrying about /run/file when we "ship" worse problems out of the gate is another closing the barn door after all the horses have run away. Especially when a lot of the issues were going to be fixed some time or another out of the past. I am not saying we shouldn't document it, and I am not saying we shouldn't fix it now but we had better do a darn better job with all the rest of the problems we come with. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
