[Pardus-kullanicilari] [Gelistirici] Ahenk 2.0 Planları

[Burak Arslan]

not: kullanicilar listesine uye insanlarin hosgorusune siginarak bu 
mailin yine yetkisi olan biri tarafindan gelistirici listesine 
iletilmesini rica ediyorum. simdiden tesekkur ederim.

======

selamlar,

Gürer Özen wrote:
> On Friday 17 April 2009 12:01:14 Emre Erenoglu wrote:
>
>   
>> policyleri ldap'ta tutmak, cok kisir bir deklaratif dil kullanmak demek.
>> (sadece key=value diyebiliyorusunuz, bence kotu fikir.)
>>     
>
> O kısır dille Active Directory gayet güzel çalışıyor ve piyasayı ele geçirmiş 
> durumda. Yönetim işinde çalışan elemanlar ve 3. parti yazılımlar bu yapıları 
> ve protokolleri iyi biliyorlar. Kurumların halihazırdaki dizin yapılarını 
> bozmadan bizim LDAP'a aktarmak ve kullanmak çok kolay. Unix adminlere 
> puppet'ı satmak kolay olabilir ama kurumlara pek öyle değil maalesef.
>
>   

ne altyapi kullandiginizi soracak kadar bilgili insanlar puppet'i 
duyunca oturmus bir teknoloji oldugu icin daha kolay ikna olurlar, 
digerleri ise zaten umursamiyor. dezavantaji nedir bu durumun?

>> yine deklaratif bir dil kullandigi icin  puppet dilinde policy ureten
>> bir gui yazip istemci yonetimini puppet vasitasiyla yapmak daha kisa
>> zamanda daha guclu bir urun ortaya cikmasina yardimci olacaktir. (gui
>> ile policyleri uretin, gerisini puppet yapsin)
>>     
>
> İstemcideki ajana yazacağımız kod yerine gui tarafında script üretici kod 
> yazıyoruz, toplam emek değişmiyor pek.
>
>   

aslinda puppet kodu uretmek basta daha zor olacaktir. ama puppet 
depolama ve yayma islerini hallettigi icin oyle bir altyapi ile ugrasmak 
zorunda kalinmayacak, bu da toplamda daha az zaman harcanmasina neden 
olacaktir diye dusunuyorum (ldap schemasi yazmak tiksinc bir is degil 
midir ? :)). ayrica puppet xmlrpc de destekledigi icin soa mimarisine 
kendini adamis bir it mantalitesi (ki ibm sagolsun turkiyede su siralar 
cok populer bu kavram) tarafindan kabul gormesi cok daha kolay olacaktir.

puppet olmasa bile soap / xmlrpc kullanilmasini oneriyorum istemci / 
sunucu iletisiminde. (istemcilerde bir soap istemcisi bir portu 
dinleyecek, sunucu teker teker bunlara baglanarak yeni komutlari 
gonderecek vs seklinde)

>> boylece hem gui isteyen 
>> insan hem de script yazmak isteyen insani mutlu edebiliriz.
>>     
>
> puppet'a ihtiyacı olan puppet'ın kendisini kurup kullanabilir zaten. puppet 
> yada cfengine kullanmayın demiyoruz ki.
>
>   

peki bu ahenk'in yonetim ozelliklerini cope atmak anlamina gelmiyor mu? 
bir interop cozumu var mi?

>> bu dagitim isi guvenilir(?) it personeli tarafindan elle yapilacaksa
>> sorun yok. ama pratikte bu islem otomatik yapilacaktir.
>>     
>
> Sertifika dağıtım işi konunun dışında bir problem. Onu tartışmaya girersek 
> içinden çıkamayız. Ama her güvenlik yönteminde bu tür problemler vardır. Bunu 
> çözemeyecek bir kurumun Kerberos'u kurup takır takır çalıştırabileceğine 
> inanmıyorum :)
>
>   

ben bir tls / ssl yapisinda, guvenilirligi saglayan pki nin nasil 
konunun disinda olabilecegini anlayamiyorum.

ayrica onca active directory kullanicisi kerberos u takir takir 
calistiriyorlar.

>> peki kerberos bunlari nasil cozer ? cok basitlestirilmis bir sekilde:
>> istemci, kerberos sunucusuna (AS) kullanici adini cleartext olarak
>> gonderir. kerberos sunucusu encrypted bir mesaj gonderir. mesajin
>> sifresi kullanicinin sifresidir. istemci kullanicinin girdigi sifre ile
>> gelen mesaji decrypt eder ve ortaya cikan yeni mesaji TGS'ye gonderir.
>> eger TGS gelen mesajdan birsey anlayabilmisse (== sifre dogruysa)
>> istemciye bir ticket gonderir. vesaire.
>>     
>
> Yani simetrik şifreleme var. Peki burada her bilgisayarın kendi şifresini 
> bilmesi gerekmiyor mu? Bunun pratikte sertifika dağıtımı probleminden farkı 
> nedir?
>
>   

yanlis bilmiyorsam bilgisayarin sifresi diye birsey yok. kullanici adi 
cleartext olarak AS ye gidiyor. gelen cevap kullanicinin girmesi gereken 
sifre(den uretilmis bir hash) ile encrypt edilmis. istemci bunu 
kullanicin girdigi sifre ile decrypt edip TGS ye gonderiyor. decryption 
islemi TGS tarafindan anlasilir bir veri ortaya cikartmissa sifre 
dogrudur deniyor ve auth islemine devam ediliyor.

sifreyi kullanicilara elden teslim ediyoruz ve ilk loginde 
degistirmelerini istiyoruz zaten. yani dedigim gibi sertifika dagitim 
problemini tamamen ortadan kaldiriyor.



>> son olarak belirtmek istedigim bir nokta var ki o da su: kriptografi ile
>> hobi olarak ugrasan birisi olarak(asil isim istatistiksel dogal dil
>> isleme), kriptografide turkiyenin et yetkin kurumu olarak bildigimiz bir
>> kurumun calisanlarina kriptografi anlatirken ellerim terlemiyor degil.
>>     
>
> Bir yanlış anlaşılma olmasın, bildiğim kadarıyla Pardus geliştiricilerinin 
> hiçbirinin UEKAE'nin kripto gruplarıyla bir alakası yok. Çalıştığım sürede 
> enstitüden bu konuda herhangi bir bilgi destek alındığını da görmedim 
> duymadım. Sorarsak bilgi verirler mi ondan da emin değilim :)
>   

tubitak ve uekae markasini pazarlama yaparken kullaniyor, hatta pardusu 
ziyarete gelince bakiniz soyle kripto cihazlarimiz, boyle guvenlik 
aletlerimiz var diye bize hava atmayi biliyorsunuz ama :))

saka bir yana, bence bu konuda zaman ayirmak onlarin da isine 
gelecektir. sanirim devletin kullanacagi sistemlerin guvenligi 
denetlenirken zaten bu insanlarin da fikri aliniyordur / alinacaktir. 
bilemiyorum uekae nin nasil isledigini tam olarak tabii ama bi' 
citlatmaktan ne zarar cikar ki?

Gürer Özen wrote:
> On Friday 17 April 2009 12:01:14 Emre Erenoglu wrote:
>
>   
>> ayrica wikipedia'da belirtilen kerberos'un eksikleri ya dupeduz yalan ya
>> da diger sistemlerde de ayni eksikler mevcut.
>>     
>
> Merak ettim, düpedüz yalan olduğu halde orada yazılmış olan eksikler 
> hangileri?
>
>   

    * Single point of failure: It requires continuous availability of a
      central server. When the Kerberos server is down, no one can log
      in. This can be mitigated by using multiple Kerberos servers and
      fallback authentication mechanisms.


her merkezi kimlik dogrulama sisteminin bir eksigi. bi' zahmet artik ! :)

    * Kerberos requires the clocks of the involved hosts to be
      synchronized. The tickets have a time availability period and if
      the host clock is not synchronized with the Kerberos server clock,
      the authentication will fail. The default configuration requires
      that clock times are no more than 10 minutes apart. In practice
      Network Time Protocol
      <http://en.wikipedia.org/wiki/Network_Time_Protocol> daemons are
      usually used to keep the host clocks synchronized.


replay saldirilarina karsi koymanin tek yontemi bu, ve ntpd var, bu 
zaten yapiliyor, o yuzden bunun bir drawback olmasi yanlis.

    * The administration protocol is not standardized and differs
      between server implementations. Password changes are described in
      RFC 3244 <http://www.ietf.org/rfc/rfc3244.txt>.


standart yonetim protokolu diye birsey ben hic duymadim ?

    * Since the secret keys for all users are stored on the central
      server, a compromise of that server will compromise all users'
      secret keys.

bi zahmet artik 2 :)

    * A compromised client will compromise the user's password

kulliyen yalan. 
http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/overview.html 
paragraf 2.2

wikipedia'nin fikirbirligi ile olusturulan bir sistem oldugu 
unutmayalim. misal 500 sene once insanlarin dunyanin tepsi oldugu ve 
evrenin merkezi oldugu konusunda hemfikir olduklari dusunulurse, 
wikipedia'nin ne kadar carpik bir "bilgi" kaynagi oldugu daha iyi ortaya 
cikar. herhangi bir konu hakkinda guvenilir bilgi sadece konunun 
otoritelerinden alinmalidir.

son olarak soylemek istedigim sey, ahenk'i bu haliyle konudan bihaber 
kucuk / orta buyuklukteki firmalara satabilirsiniz, hatta bu onlar icin 
guvenli bir cozum de olacaktir (verinin degerinin o veriyi elde etmenin 
maliyetinden kucuk olmasi dolayisiyla). ama misal is bankasi gibi buyuk, 
ciddi kuruluslarin bu cozumu yeterli bulacaklarina inanmiyorum.

aldigim istihbarata gore ozgur yazilim gunlerinde karsilacagiz zaten, 
orada gorusmek uzere.

iyi calismalar,
burak


-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: http://liste.pardus.org.tr/pardus-kullanicilari/attachments/20090417/e3e9ff3d/attachment-0001.htm