CmndAlias'ı kullanmak ALLasla güvenli olmayacak
Çalıştırmak için 1000 yol vardır service network restartyapmadan sudo service network restart. İşte yaramaz bir kullanıcının deneyebileceği bir örnek:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
Kullanıcılara ALLdiğer ad komutunu verirseniz ve ardından bir kara liste oluşturmaya çalışırsanız, her zaman çevresinde bir yol bulabilirler. Kara liste bash ve python kullanacaklar. Kara liste pitonu ve Perl kullanacaklar. Kara liste Perl, PHP kullanacaklar. Kimse bunu istemez!
Gerçekten de birilerinin bir şeyler yapmak istemiyorsanız, Thomas dediğini yap ve onlar şeylerin bir beyaz liste oluşturmalısınız edilir yapmaya izin verdi.
İstisna ile beyaz liste oluşturma
Hariç tutulan küçük bir beyaz listeye örnek aşağıdakilerin altında bulunabilir man sudoers:
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(Aslında bu sayfadaki örnek güvenli değildir ve kökün şifresini değiştirmek için kullanılabilir! Bunun için aşağıdaki yorumlara bakınız.)
Vakanızla kadar bütün sunmak olduğunu adapte deneyebilirsiniz servicepersonel grubuna komutları, ama dışlamakservice network olduğunu sen endişe komutları:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
(Bu ALLpozisyonda Host_Alias, Cmnd_Alias değil - kafa karıştırıcı değil mi?)
Kullanıcı çalıştırmak mümkün olmayacaktır sudo bashya sudo teeya sudo wgetya sudo /path/to/malicious_script. Dikkatliysanız, kullanıcılarınız için daha fazla yönetici komutunu beyaz listeye alabilirsiniz. Sadece spesifik ol!
Not: Gelecekte araca zararsız bir bayrak eklenmesi durumunda, yukarıdaki *kelimeden önce networkekledim service. --verboseGelecekte bir bayrak eklendiğini düşünelim , o zaman kullanıcılar aşağıdakileri çalıştırabilir:
$ sudo service --verbose network restart
Bu yüzden *hizmet adından önce herhangi bir bayrağı tüketmek zorundayız . Tek dezavantajı, bunun aslında çalışanların aklını takmadığınız diğer servisleri, örneğin, aranan safe-networkveya network-monitorreddedilenleri engelleyebilecek olmasıdır.
Kullanıcıların grup izinlerini kullanarak bir dosyayı düzenlemesine izin verin
Aşağıda, kullanıcıların bir dosyayı veya dosyaları düzenlemesine izin vermek için rnanoaracılığıyla çeşitli girişimleri bulabilirsiniz sudo. Ama gerçekten olması gerekenden daha karmaşık ve daha tehlikeliler.
Çok daha basit ve daha güvenli bir çözüm, düzenleme haklarını açmak istediğiniz belirli dosyalar üzerindeki grup izinlerini değiştirmektir. Burada bir çift örnek var:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
Daha fazla hassas denetime ihtiyacınız varsa (örneğin: yalnızca 3 kullanıcının erişimine erişebilirsiniz, ancak tüm personel üyelerine değil) bu addgroupkomutu kullanarak yeni bir grup oluşturabilir ve ona yalnızca birkaç kullanıcı ekleyebilirsiniz.
Kullanıcıların dosyayı düzenlemesine izin ver sudo
Bu cevabın geri kalanı, sudokullanıcılarınıza esneklik sunmaya çalışırken yapılandırmanızda delikler bırakmanın ne kadar kolay olduğu üzerine bir araştırma haline geldi . Aşağıdakilerden herhangi birini yapmanızı tavsiye etmem!
Kullanıcılarınıza belirli bir dosyayı düzenlemeleri için erişim izni vermek istiyorsanız, şunu kullanmayı deneyebilirsiniz rnano:
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnanosadece belirtilen dosyayı düzenlemelerine izin verecektir. Kötü niyetli bir kullanıcının farklı bir başlangıç servisini (örneğin /etc/init.d/urandom) düzenlemesini ve çalışacak bir satır eklemesini önlemek önemlidir service network restart.
Ne yazık ki, rvimyeterince kısıtlamanın bir yolunu bulamadım (kullanıcı yine de herhangi bir dosyayı kullanarak açabilir :e), bu yüzden takılı kaldık nano.
Ne yazık ki, kullanıcıların birden fazla dosyayı düzenlemesine izin vermek çok daha zor ...
Kullanıcıların birden çok dosyayı düzenlemesine izin verin (olması gerekenden çok daha zor)
1. Güvensiz yaklaşımlar
Joker karakterlere dikkat edin! Çok fazla esneklik (veya herhangi bir esneklik) teklif ediyorsanız, yararlanılabilir:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
Bu durumda, kötü niyetli bir kullanıcı diğer herhangi bir başlangıç servis komut dosyasını düzenleyebilir ve ardından çalıştırabilir:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(Sudo emri gerçekten önler .ve ..genişletir, ancak ne yazık ki tartışmalarda değil.)
Böyle bir şeyin işe yarayacağını umuyordum, ama hala güvensiz:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
Yana sudoşu anda sadece teklifler topak desenleri, o *şey maç olacak - bir regexp değil!
(Düzenleme: Ne olursa düşünün vermedi olabilir senin durumundaki yukarıda yanına altındaki hiçbir alt klasörler olduğundan, sites-available. Biz talep bir karakter klasörüne sonra eşleştirilecek yoktu ve /... Bir dosya adı sonra başarısız olması Ancak bu bir değil uygulanabilir çözüm, çünkü rnanobirden fazla argüman kabul eder ve genel olarak yine de bu, alt klasörleri olan bir klasörde güvensiz olur !)
Alt klasörümüz olmasa ve içeren satırları hariç tutsak bile, /../bir *küre öneren kural hala kullanılabilir, çünkü rnanobirden fazla argüman kabul eder (üzerlerinde bisiklete binme <C-X>ve yer *küre tarafından mutlu bir şekilde kabul edilir) .
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. Zarfı iterek (nihayetinde güvensiz)
Peki ya boşluk içeren ya da ulaşmaya çalışan çizgileri reddedersek /..? Öyleyse, uygulanabilir bir son çözüm şöyle olabilir:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
Biz klasörünün "altındaki" her şeyi kabul ama biz de herhangi bir çağrıyı reddetmek rnanodurumunda /..ya /.ya /.dışlama /..dışlamayı gereksiz kılar , ancak her ikisini de netlik için bıraktım.)
Klasörü buldum ve /.istisnalar gerekliydi çünkü aksi takdirde kullanıcı klasörün kendisini hedefleyebilirdi. Şimdi rnanobir klasöre işaret ederse engelleyeceğini düşünebilirsiniz , ama yanılıyorsunuz. Aslında benim sürümüm (2.2.6-1ubuntu1) hafif bir uyarı ve boş bir dosya ile başlıyor, sonra <C-X>benden kaydetmek istediğim bir dosya adı girip yeni bir saldırı vektörü açmamı istiyor ! En azından varolan bir dosyanın üzerine yazmayı reddetti (yaptığım bir testte). Her neyse, alt klasörleri sudo ile kara listeye almanın bir yolu olmadığından, bu yaklaşımın tekrar güvensiz olduğu sonucuna varmalıyız. Üzgünüm kullanıcılar!
Bu keşif, nano'' kısıtlı '' modunun eksiksizliğinden şüphe etti . Bir zincirin sadece en zayıf halkası kadar güçlü olduğunu söylerler. sudoKara liste kara büyü kombinasyonunu hissetmeye başlıyorum ve rnanobir papatya zincirinden daha güvenli olmayabilir.
3. Güvenli ancak sınırlı yaklaşımlar
Globlar çok kısıtlı - bir karakter sınıfını birçok kez eşleştirmemize izin vermiyorlar. Sen olabilir çoklu dosya düzenlemeleri sunuyoruz, tüm dosya adları (bu durumda aynı uzunluğa varsa hosttek rakam ile devam eden):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
Ancak, kullanıcının çeşitli dosyaları düzenlemesine izin vermek istiyorsanız, her dosyayı açıkça belirtmeniz gerekebilir:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
*Herhangi bir noktadakullanmak için ayartmayınız . Neden için yukarıdaki 1. ve 2. bölümlere bakınız! Unutmayın: Küçük bir fiş tüm kullanıcı hesabını ve tüm sistemi tehlikeye atabilir.
4. Kendi argüman denetleyicinizi yazın (güvenlik şimdi sizin sorumluluğunuzdadır)
Umarım sudogelecekte regexp desteği eklerler ; Doğru kullanılırsa birçok sorunu çözebilir. Ancak, argümanların özelliklerini de kontrol etme yeteneğine ihtiyacımız olabilir (yalnızca dosyalara, yalnızca klasörlere veya yalnızca belirli bayraklara izin vermek için).
Ancak, sudo'da esneklik yaratmanın bir alternatifi var. Sorumluluğu başkasına yüklemek:
%staff ALL = /root/bin/staffedit *
Ardından staffedit, kullanıcı tarafından iletilen argümanların yasal olup olmadığını kontrol etmek için kendi komut dosyanızı veya yürütülebilir dosyanızı yazın ve isteklerini ancak yapıyorlarsa yapın.
networkingvenetwork-manager? Ayrıca, kullanıcılarınızın nedensudoerişimi var? Tam kök ayrıcalıklarına sahip olmalarını istemediğiniz sürece yapmamalılar.