Re: güvenlik problemi gibi gelen iki durum

[Recai Oktas <roktas@omu.edu.tr>]

Merhaba,

Tonguc gayet guzel ozetlemis, ben de birkac sey ekleyeyim.

* Azer Demir [2005-12-16 11:05:57+0200]
> birincisi /sbin ve /usr/sbin dizinlerinin altında bulunan programlarla
> ilgili. normalde bu dizinlerin içerikleri root kullanıcısı için path
> değişkenine ekli, fakat normal kullanıcı için ise ekli değil ki, böyle
> olması doğal. yalnız bu dizinlerdeki programların dosya izinleri bu
> programları normal kullanıcıların çalıştırmalarına olanak tanıyor,
> yani komut satırından şöyle dersek;
> 
> $ /sbin/modprobe ... (modprobe /sbin'in içinde miydi tam
> hatırlamıyorum, örnek olarak görelim :) )

Bu komut verilen cekirdek modulunun yuklenmesini saglar, bir sartla, modulu
yukleyen prosesin (ve dolayisiyla prosesi baslatan kullanicinin) elinde bir
izin belgesi olmalidir.  Bu izin belgesine "capability", bu tarz izin
denetimine de guvenlik jargonunda "capability based security"[1] deniyor.
Ayrintilar icin capabilities(7) kilavuzuna bakabilirsin.  Mesela ben o
belgeye baktigimda modprobe komutuyla bir modul yuklemem icin gerekli
"capability"nin CAP_SYS_MODULE oldugunu goruyorum:

    CAP_SYS_MODULE
	Allow  loading  and  unloading  of  kernel modules; allow
	modifications to capability bounding set (see init_module(2) and
	delete_module(2)).

Normal kullanicinin bu islemi yapabilmesi icin o komutun SUID ozelligini
etkinlestirebilirdik:

    $ cd /tmp
    $ sudo cp /sbin/modprobe .
    $ ls -l modprobe
    -rwxr-xr-x  1 root root 23276 Dec 16 13:48 modprobe
    $ ./modprobe pcspkr
    FATAL: Error inserting pcspkr ...: Operation not permitted
    $ sudo chmod u+s modprobe
    $ ls -l modprobe
    -rwsr-xr-x  1 root root 23276 Dec 16 13:48 modprobe
    $ ./modprobe pcspkr && echo OK
    OK

gibi...  Nitekim boyle SUID yapilmis iyi bilinen bir program da var:

    $ ls -l /bin/ping
    -rwsr-xr-x  1 root root 15244 Nov 19  2001 /bin/ping

Bu program CAP_NET_RAW yetkisi istiyor, o yuzden boyle ayarlanmis diye
biliyorum.
    
[...]
> olarak sistemi ele geçiren kötü niyetli biri (ki böyle bir kişi az
> bilgiye de sahip değildir) /sbin'den yada /usr/sbin'den direk komut
> çalıştırabilir, bu bir güvenlik problemi olarak görülmüyor mu, yada bu
> kullanıcının alması gereken bir problemdir denip kullanıcıya mı
> bırakılıyor, ve diğer dağıtımlarda da durum aynı mıdır?

Yani ozetle bu guvenlik ilk bakista gorundugu kadar kolay asilabilecek
durumda degil.  /sbin, /usr/sbin'in ortalikta olmasi hali, defter-kitap
acik yapilan bir sinav gibi. :-)

[...]
> $ sudo aptitude install istedigim_paket
> 
> dediğimde şifre olarak root şifresini girdiğimde reddediliyordum.
> sonradan öğrendim ki burada kendi kullanıcımın şifresini girmem
> gerekiyormuş. şu anda bu halde sudo'yu kullanabiliyorum. ama bu da
> bana bir güvenlik problemi gibi geliyor. yine benim kullanıcımı ele

Komutu calistiran kullaniciya ait parolanin istenmesi bana cok dogal
geliyor.  Sonucta root bir kisiye izin vermis, falan filan islerin
kendisinden izin alinmaksizin yapilabilmesi icin.  Ama izin verilen kisi,
gercekten o kisi mi acaba?  Basitce bu denetleniyor.

> geçiren kötü niyetli biri sudo'yu kullanıyor olduğumu düşünüp deneme
> yapabilir, ve gayet de güzel başarılı sonuçlara ulaşabilir, hatta
> üstteki durumdan daha kesin bir sonuç olur :) (tabii sudoers
> dosyasının içeriğine göre). neden sudo benden root şifresini istemiyor
> da benim kendi şifremi istiyor anlayabilmiş değilim. yada şöyle
> sorayım sudo'yu bana root şifresini soracak şekilde ayarlayabilir
> miyim? eğer böyle bir şeyi sağlayamıyorsam benim için sudo kullanmanın

Bunu ayarlamak mumkun, sudoers(5)'den alinti:

    rootpw  If set, sudo will prompt for the root password instead of the
            password of the invoking user.  This flag is off by default.

[1] http://en.wikipedia.org/wiki/Capability-based_security

-- 
roktas