Похоже на баг в sudo. Советую отписаться на багтрекер.

Хотя можно попробовать и так разрулить. Покажи-ка
grep AVC /var/log/audit/audit.log | tail

Секундочку

grep AVC /var/log/audit/audit.log | tail

type=AVC msg=audit(1292015114.844:13): avc: denied { read write } for pid=3078 comm=«iptables» path=«socket:[13162]» dev=sockfs ino=13162 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1292015114.881:14): avc: denied { read write } for pid=3091 comm=«iptables» path=«socket:[13072]» dev=sockfs ino=13072 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket

Не знаю, но думаю мне надо объяснить SELinux-су что этому скрипту разрешено управлять iptables. Потому что без SELinux, я имею свое ожидаемое срабатывание - бан ip в iptables

cat << EOF
module iptsocket 1.0;
require {
        type iptables_t;
        type initrc_t;
        class unix_stream_socket { read write };
}
allow iptables_t initrc_t:unix_stream_socket { read write };
EOF > iptsocket.te
checkmodule -M -m -o iptsocket.mod iptsocket.te
semodule_package -o iptsocket.pp -m iptsocket.mod
semodule -i iptsocket.pp

После этого должно заработать.

Спасибо nnz!

Я погружаюсь в гугл и в теорию. Ибо этим модулем ты меня сильно напугал. Почувствовал себя блондинкой. Что это такое вкратце, если не трудно?

Это просто правило, разрешающее iptables работать с сокетами из контекста initrc_t (из которого, видимо, запускается твой бан-скрипт).

Так как у selinux правила поодиночке не ходят, пришлось оформлять в модуль, компилировать и подгружать его.

ох, вспомню как писал подобные модули на генту... нехорошо становится мне )