HPUX şifre sistemi incelemesi

[megabros]

Çoğu UNIX sistemleri kullanıcı bilgileri ve kriptolanmış şifreleri depolamak için benzer metodlar kullanırlar. Buna düz eski /etc/passwd veya gölge şifreler kullanımında /etc/shadow da dahil. Elbetteki bunlarin çeşitleri var. HPUX 10.x ve üzerinde üç seçeneğiniz var: Normal sürüm 7 tipi, gölge şifreler yada onların 'sadece güvenilen sistemler için' olan 'korunan şifre veritabanı'.

HP Güvenilen Sistemler`inin tam açiklamasi bu yazinin disina çikiyor, o yüzden ben sadece korunan sifre veritabani sistemi üzerinde duracagim. Güvenilen sistemler, basitçe, HPUX ile birlikte kurma seçeneginiz olan bir paket (HPUX`i iyi bilenlerden özür diliyorum). Anahtar özelliklerden birisi HPUX makine üzerinde uyguladigi korunan sifre veritabani.

Korunan şifre veritabani nedir? Diyelimki üzerinde güvenilen sistemler çalışıyor olan bir HPUX makineye login oldunuz. 'cat /etc/passwd' yazdınız ve şifrelerin yerinde eski '*' karakteri var. Sonrada gölge şifreleler kullanımda mı diye görmek için 'ls /etc/shadow' yaptınız fakat bir iz yok. Ve '/tcb/files' dizini dikkatinizi çekti. İşte burası güvenilen sistemler dizini ve kullanıcı bilgileri ve şifreleride '/tcb/files/auth' dizininde tutuluyor.

Artık kullanıcı bilgilerinin nerede tutulduğunu bildiğimize göre, tipik bir kullanıcı dosyasına bakalım. Her kullanıcının isminin ilk harfiyle başlayan bir dizin içinde kendine it bir düz yazı dosyası vardır. Bu, '/etc/passwd' gibi tüm kullanıcıları içeren bir dosyanın güvensizliği durumunda tüm kullanıcılar etkilendiği için daha iyi bir özellik.

jblow:  uname=jblow:u_id@2876:\
      :u_pwd=3E/IbASoPe6k2:\
      :u_auditid#5219:\
      :u_auditflag#1:\
      :u_succhg@979762751:u_llogin#0:u_pw_expire_warning#0:u_suclog#984723623:\
      :u_suctty=pts/tg:u_unsuclog#984278635:u_unsuctty=pts/ti:u_lock@:\
      :chkent:

Eğer iyi incelenirse '/tcb/files/auth/j/jblow' altında bulunan bu dosyanın pek çok değerli bilgi içerdiği görülebilir. Eğer getprpwnam(3) man sayfalarına bakarsak tüm bunların ne anlama geldiğini ve kullanılmayan alanların listelenmediğini göreceğiz. Gerçekte, güvenilen sistemleri çok 'özel' yapan düzinelerce alan ve flag`ler mevcut (ör. kullanıcının ne yapıp ne yapamayacağının kontrolü).

 
Peki bu dosyada nasıl değişiklikler yapabiliriz? Bunu yapmanın yollarından biri HPUX`in lame sistem yönetim aracı 'sam'ı kullanmak. Fakat C kodu yzamak daha eğlenceli ve ilgi çekici. jblow kullanıcı hesabı ile ilgili birşeyler yapacağımızı düşünelim. İşte kullanıcının tüm alan ve flag`lerinin yapısını veren bir C kodu (bir kez daha, getprpwnam(3) man sayfası):

#include
#include
#include

struct pr_passwd* userinfo;
struct pr_passwd* temp;
temp = getprpwnam('jblow');
if(temp == NULL)
{
      printf('Geçersiz kullanıcı ismi.\n');
      exit(1);
}
else
{
      userinfo = (struct pr_passwd *) malloc(sizeof(*temp));
      if (userinfo != NULL)
      memcpy(userinfo,temp,sizeof(*temp));
}

Burda yapıyı geçici bir yapıya kopyaladık. Bu güvenli programlama için. gdb gibi bir debugger ile karışık bir print rutini yazmadan 'userinfo' yapısına göz atabilirsiniz. Bu şekilde yapı içerisinde neler olduğuna dair iyi bir bilginiz olur. Bir sonraki adım jblow`un kullanıcı hesabında bir şekilde değişiklikler yapmak. Ben eğlence için şifre alanını seçtim. HPUX`da şifre alanı eski iyi crypt(3) fonksiyonu kullanılarak yaratılıyor. Eğer man sayfalarına bakarsak aşağıdakileri göreceğiz:

NAME
      crypt, setkey, encrypt - generate hashing encryption
SYNOPSIS
      #include
      #include
      char *crypt(const char *key, const char *salt);
      falan filan...

Anlaşıldığına göre, key kriptolanacak olan karakterler ve salt da 2 karakterlik ... salt işte! Crypt kullanmanın dezavantajlarından biri sadece 8 karakterlik bölümler kriptolayabileceğinden şifre uzunluğunu kısıtlamasıdır. Bu sebeple, jblow`a bakarsak: 3E/IbASoPe6k2. Burda '3E' salt karakterleri ve '/IbASoPe6k2' kriptolanmış şifre. Eğer 8 karakterden daha fazlasını kriptolamak isterseniz, bir salt ve ilk 8 karakteri geçirmeniz gerekli ve sonra kriptolanmış karakterlerin ilk ikisini bir sonraki için salt olarak kullanmanız gerekli vs. Örneğin, '/I' bir sonraki salt olarak kullanılabilirdi. Tabi boyut sınırını aşan bigcrypt(3) fonksiyonu olduğundan başımız ağrımıyor. Şimdi örnek olarak biraz C koduna bakalım (hala jblow`un userinfo yapısını kullanıyoruz):

char *newpass; /* bu örnek için  yeni bir şifre */
  /* içerdiğini varsayalım */
int length = strlen(newpass);

/* güvenilir sistem uyumluluğu kontrolü */
for (i=0;i=2)&&(num_nonalpha>=1)))
{
     printf('Yeni şifre en az iki alfa-karakter ve');
     printf('bir alfa-olmayan karakter içermeli');
     exit(1);
}

/* yeni şifreyi kriptola ve yerine koy */
encrpyt_pw = (char *)bigcrypt(newpass, salt);
strcpy(userinfo->ufld.fd.encrypt,encrypt_pw);

/* Bu kullanıcı hesabının şifre değişikliğine zorlayıp */
/* zorlamayacağını kontrol edin */
if(userinfo->ufld.fd_schange == 0)
{
     /* o halde login olurken şifre değiştirmeye zorlanacak */
     userinfo->ufld.fd_schange=time(&tloc); /* o anki tarih */
}

if (!putprpwnam(user,userinfo))
{
     printf('Hata, şifre değişmedi.\n');
     exit(1);
}

Yukarda da göreceğiniz gibi güvenilen sistemler can sıkıcı. Tüm bunların detayı sistem tarafından uygulanan politikalara (policy) bağlı. Yukarda fd_schange alanını kontrol ettiğimi farketmişsinizdir. Bunun sebebi man sayfaları fd_schange için 'last successful change in secs past 1/1/70' yazıyor. Eğer bu 0 ise ve 'son başarılı değiştirme' yok ise ve sistem şifre değişikliğine zorlarsa bununla ilgilenmek gerekli.

Sistem politikalarını bulmak zor olabilir. Başlangıç olarak '/tcb/files/auth/default' dizinine bakmanızı öneririm. Bunun dışında, kendi başınasınız.

Sonuç olarak, HPUX büyük ihtimalle bu sistemi uzun süre tutmayacak. Web üzerinde kısa bir araştırma güvenilen sistemler ile ilgili pek çok problem yaşandığını gösteriyor. Güvenilen sistemlerin PAM ile çalışmaması gibi ek bir yararıda var. Bu sebeple, bence HPUX`in yeni bir şeyle ortaya çıkıp bunlardan kurtulması an meselesi. Fakat bunu kullanan çok sistem var, özellikle de akademik sektörde.

Saygılar.