2.2 vs 2.4 -- propozycja

[Michał Kuratczyk]

On Mon, Jul 23, 2001 at 11:38:21AM +0200, Tomasz Kłoczko wrote:
>> - zdejmowanie zbędnych CAPów (wiem, że można też capselem czy innymi)
>Jak pojawi sie xfs czy systemy plikowe z ACLami sprawa sie rozwiąże sama i 
>to bez takich wynalazków jak LIDS czy inne tego typu.
Capabilities i ACLe to mimo wszystko różne rzeczy. Przy użyciu ACLi
(AFAIK) nie mogęstwierdzić, że /usr/sbin/imapd nie ma prawa
czytać /etc/shadow. LIDS na to pozwala.

>> - informowanie admina o dziwnych zachowaniach w systemie (przede
>>   wszystkim próby wykorzystania zdjętych CAPów)
>I co to daje ? Równie dobrze mozesz logować próby logowanai an roota w 
>sytuacji kiedy tylko konkretne osoby mogą to wykonać.
LIDS pozwala dodatkowo zalogować próby załadowania modułu jądra czy
podmienienia jakiejś binarki (nie mówiąc już o tym, że to utrudni).

>Ktoś kto chce wykonac atak *zakłada* że dziura jest i wykorzystuje ją w 
>ciemno bez zostaiwanai dodatkowych śladów. Kogoś kto robi inaczje można 
>zignorować.
A jeśli założy, że dziura jest w moim (powiedzmy) imapd, a u mnie nie
pracuje imapd? W normalnej sytuacji dostanie odpowiedź ICMP i tyle.
Przy użyciu LIDSa, SNORTa czy czegoś tam jeszcze mogę dowiedzieć się o
takich próbach. Dzięki temu jak kilka godzin później ktoś mi się włamie,
to jednego podejrzanego będę już miał.

>Michał za długo w tym siedzę żeby dać sie nabrać na lepo pozozrnego 
>bezpieczeństwa (bo to tylko o to chodzi .. o pozór).
Nie twierdzę, że LIDS (czy cokolwiek innego) przed wszystkim mnie
uchroni. Myślę jednak, że możliwość zablokowania dostępu do krytycznych
plików programom, które tego dostępu nie potrzebują jest dość istotna.
Podobnie możliwość logowania różnych nieudanych prób zwiększa
bezpieczeństwo systemu choćby dlatego, że mam (jeszcze mocniejszą)
świadomość, że ONI próbują. :-)

Jestem świadom tego, że wszystkie zapezpieczenia da się obejść, ale nie
zaszkodzi utrudnić nieco ich obejście. Idealna sytuacja, w której system
po prostu nie ma dziur jest w praktyce nierealna... :-(

-- 
Michał Kuratczyk <kura w cs.net.pl>