[Linux] Re: Linux Istanbul 2002

---------

New Message Reply About this list Date view Thread view Subject view Author view

From: Serdar Koylu (serdarkoylu@fisek.com.tr)
Date: Mon 09 Sep 2002 - 13:12:49 EEST


Selamlar...

09 Sep 2002 12:26 EEST tarihinde yazmışsınız:

>
> > Merhaba,
>
> Selam,
>
> > Bunlar bir bebek icin her zaman gecerli olacak sancilar degil midir?
> > Baska ornegi olmadigi icin Gelecek Linux'tan soz ettigimizi dusunuyorum.
> > Dagitimi begendigimi soylemiyorum ama dogrusu ben bu calismayi cok
> > anlamli ve degerli buluyorum.
> >
> > Bugun cok zayif olabilir ama her sey boyle baslamaz mi? Bu kadar hizli
> > donen bir dunyada "mukemmeli" uretmeye calismak, kendi sinirlarini
> > zorlamaya calismak ilk gunden yapilabilecek bir sey degil bence...
>
> Bu konuda herhangi bir tartismaya girmek istemiyorum. Fakat guvenlik
> update leri, sunucu olarak kullanilmasi onerilen bir sistem icin
> zorunluluktur. Bunun bebeklikle veya baska birseyle iliskisi yoktur.
> Sadece zorunluluktur. Bunu yapmak, yapmamak, yapamamak ... tamamen
> ilgili kisilerin ve kullananlarin sorunudur.

Gelecek bugune kadar RedHat'in pesinden gitmis. Bu nedenle guvenlik guncellemelerini redhat'tan takip edebiliyorsunuz. Ben ise buna karsi oldum. Komple yeni ve sifirdan bir dagitim olsun istedim her daim. Gelecek Linux ekibi farkli. O isle ilgilenen arkadaslar oyle yapiyorlar. Ben herkes kadar fikir beyanindan fazlasini yapmiyorum. Onlarin savunmasi ise, guvenlik guncellemesi gibi kritik noktalarda boyle yapmanin daha mantikli oldugu oldu. Hak vermiyor degilim. Bu sekilde yaparak RedHat'in guvenlik guncellemelerini takip ettiginizde bu sorun ortadan kalkmis oluyor.

Yeni server serisinin yaklasimi ise cok farkli. O guvenlik acisindan tam bir paranoyak olarak davranabiliyor. Varsayilani, bu sekilde. Guncellemeleri otomatik yapabiliyor. Bu tamam. Hemde su anki mevcut diger cozumlerden 1-2 adim onde giderek. Fakat bunun yaninda sistem event driven bir kaliba giriyor. Bu durumda ornegin bir brute force denemesi olursa, o kullanici suspend edilebiliyor otomatik olarak. SIGSEGV ozellikle takip ediliyor. SIGSEGV ardindan stack uzerinden kod calistirilmasi mumkun degil. Dahasi, hemen her process'i chroot ortamda ve kendi VM'inde calistirabilmeyi dusunuyoruz. Ornegin izin verilen adreslerden yapilan baglantilar disinda, hic bir baglantidan root olunamayacak. Buna SIGSEGV sonrasida dahil. Yani, sisteme ssh ile bile root olarak baglanmaniz mumkun degil. Dahasi diyelimki baska bir user olarak baglandiniz, su root yapmanizda mumkun degil. Derhal saldirgan olarak kabul edilirsiniz ve baglantiniz kesilir. Bunlar pek paranoya alameti degil ve su anda mevcut bazi patch'ler ile zaten yap
ilabilen seyler. Fakat, bir paranoya alameti olarak sunu gostereyim. Tum konfigurasyon dosyalari ("/etc"), farkli bir partisyonda tutuluyor. Bu partisyona erisim ise izleniyor. Sadece konfigurasyon arabirimleri bu partisyona yazabiliyor. Her servisin baslama, bitis, restart, HUP gibi islevleri konfigurasyon arabirimleri tarafindan yerine getiriliyor. Fakat, tum DMZ'i kontrol eden konfigurasyon arabirimleri tek bir makinada calisabilir. Bu partisyona da sadece bu makineden encrypted connection ile ulasilabilir. Yani siz her makineye ayri ayri konfig arabirimi kurmak zorunda degilsiniz. CLIRP platformu bunu size kolayca saglar. Dahasi bu paranoyaya yonelik ilave cok husus var. Ama urun ortaya ciktikca bunlar daha iyi gorulebilecek. enteresan bir kac durumdan bahsedeyim. Bir makine uzerindeki X servisi bir sekilde saldiriya ugrayip *SIGSEGV (buffer overflow) vs. yerse, yada o servis bir saldiriya ugradigini farkederse, sistem firewall'den saldirganin tum baglantilarini kapatabiliyor. Bazi guvenlik bilesenleri i
cin erisim root yetkisi olanlar icin dahi ikinci bir parola gerektiriyor. Benzeri bir suru ozellik var.

Bastan bir sistem yaziyoruz. RPM'in ve/veya .DEB'in suyu cikmamisti ki gidip 50K satirla packet yonetici yaziyoruz. BIND 9'un satir sayisi 20K civarindadir. Paket yonetici bagli oldugu ortak bilesenlerle birlikte 150K satir civarinda olacak diye tahmin ediyorum. SuSE, astaro gibi dagitimlar zaten var, yeni bir urun cikarirken mevcut olandan daha iyisi olmali ki, yapmis oldugumuza degsin. Bu kafayla egiliyoruz konuya. Yapamayacagiz diye bir sey yok. Tek tereddut ettigimiz husus, belki biraz daha gecikebilir. Bu nedenle belki ara surumler cikarmak durumunda olabiliriz. Boylece gelistirme surerken, gelistirilen bolumlerin kullanicilarin istifadesine sunulmasini saglayabiliriz. MS'ye kizarken, bizim musterilere beta testi yaptirmayacagimizdan emin olabilirsiniz.

Umarim yeni sistem icin akillardaki soru isaretlerinden guvenlik ile alakali olanlara biraz cevap verebilmisimdir. Linux gercekten guclu bir sistemdir. Ama gucunu ham olarak sakliyor. Kullanicilar ise cogu zaman bu gucun farkinda bile degil. Biz bu gucu ortaya cikaracak bir platform gelistiriyoruz, hepsi bundan ibaret. Ama bu dikensiz gul bahcesi degil elbette. Mesela bu seri 486 ile calismayacak. RAM ihtiyaci 128K'dan basliyor. Belki zorunlu olarak bir ses karti sart olacak. Bu ses karti random sayi jeneratoru olarak kullanilacak. Tam bir pembe gurultu olan dip gurultusunu yakalamayi dusunuyoruz. Bu sadece bir dusunce simdilik.

Saygi ve sevgiler..
-----------------------------------------------------------------------
Liste üyeliğiniz ile ilgili her türlü işlem için
http://liste.linux.org.tr adresindeki web arayüzünü kullanabilirsiniz.

Listeden çıkmak için: 'linux-request@linux.org.tr' adresine,
"Konu" kısmında "unsubscribe" yazan bir e-posta gönderiniz.
-----------------------------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view

---------

Bu arsiv hypermail 2b29 tarafindan uretilmistir.