Hello, Steve G napsal(a): > When a core dump is attempted, the audit system gets control briefly. It records > the event as an ANOM_ABEND event. ANOM_ is the whole class of events that are > intended for use by the IDS/IPS code. ABEND is the subtype that means the program > ended abnormally. > Now, the reason that I'm writing all this in an email is that there are programs > that can cause false positives. No one is attacking my system via the dhcdbd > command. The aborted tells me that the application must be calling abort(). In > many cases people want their program to exit due to some problem. Calling abort() > means end the program AND dump core. This will trigger the IPS part of the system > at some point. > > Anyways, I wanted to point this out so that as new code is written, people > understand that an abort() may be confused with an attack. Please don't call > abort() unless you really intend to dump core. User space will need some cleaning > up to make an IDS/IPS effective. From what I can see, there's only a couple > offending programs. abort() is the traditional way to abort a program when an assertion fails (developers might need the core file in that case), and SIGABRT terminations are very unlikely to be caused by buffer overflows and similar attacks. They are much more likely to be caused by application bugs that can not be used for unauthorized code execution (although they might be used for denial of service.) Changing all software to use some other mechanism to report assertion failure is completely impractical (even the POSIX standard requires assert() to call abort() on failures); besides, what alternative mechanism is available? Repeated SIGABRT terminations might indicate an ongoing DoS attack, but isolated SIGABRT terminations need to be ignored, IMHO. Mirek -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
