informations about boot sequence (Re: F15 - mysql start problem)

Stephen John Smoogen smooge at gmail.com
Tue May 10 01:19:09 UTC 2011


2011/5/9 Miloslav Trmač <mitr at volny.cz>:
> 2011/5/10 Stephen John Smoogen <smooge at gmail.com>:
>> 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


More information about the devel mailing list