Linux'ta sırları kökten tutma

Aslında, if root'unu kısıtlamak mümkündür işletim sistemine temelde güvenmek. Bu SELinux (bildiğim) ve muhtemelen diğer sistemler kullanılarak yapılabilir. SELinux'un bu şekilde kullanıldığını gördüğüm en iyi örnek Russell Coker'ın Play SELinux Machine .

Nasıl çalıştığına kısa bir genel bakış olarak, "root" adı Unix'te özel değildir. UID 0 değeri. UID 0, "söylediğim her şeye güven" anlamına gelir. Bu, özellikle Unices, Unixen'de kullanılan standart erişim modeli için geçerlidir veya "Unix" ile çoğul yaparsanız.

LSM veya Linux Güvenlik Modülleri, hemen hemen her şeye bağlanmanıza ve uygun gördüğünüz eylemleri denetlemenize/reddetmenize izin verir. SELinux durumunda, SELinux izinleri Unix izinlerinden sonra kontrol edilir, bu nedenle akışınız şöyle görünür:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

Anlaşılması gereken bir sonraki aşama, SELinux Politikasının farklı versiyonları olduğu veya tarihsel olarak var olduğudur. Buna girmeden önce bunu SELinux'da anlayın:

• inode, alan adı olarak da adlandırılabilen _t sonekine sahip türlere sahiptir; ve
• kullanıcıların _r soneki rolleri var.

Birlikte, belirli bir roldeki bir kullanıcının hangi eylemi yapabileceğini ve belirli bir etki alanındaki bir işlemin ne yapabileceğini kontrol ederler.

Şimdi, üç ana SELinux politikası var:

1. hedeflendi. Bu, Fedora gibi masaüstü bilgisayarlar için varsayılan politikadır. Hedeflenen fikir, kritik sistem hizmetlerinin ve arka plan programlarının etki alanlarında çalıştırılmasıdır, ancak son kullanıcının yaptığınız işlerin çoğunun unconfined_u:unconfined_r:unconfined_t İçinde çalıştırılmasıdır. Bunun ne anlama geldiğini tahmin etmek için ödül yok - Unix izinleri işe yararsa SELinux etkili bir şekilde geçer.
2. katı. Bu politika unconfined_u 'nun tamamen kaldırılmasını içerir. Bu, özellikle Linux masaüstünde (yani init 5) Kolay bir işlem değildir. Özellikle, X11 güvenlik modeli harika değildir ve bazı uygulamalar için genellikle unconfined_t Gerekir. Sen bunu yapabilirsiniz , ama özellikle kök gerektiren GUI uygulamaları yürütürken X11 ile çalışmak (imkansız olmasa da) daha zor olmasını beklenir. X'te XACE (X Erişim Kontrolü Uzantıları) adında SELinux benzeri işlevsellik desteği sağlamak üzere devam etmekte olan bir proje var.
3. MLS. MLS, çok düzeyli güvenlik anlamına gelir ve izin dizesinin sonu anlamına gelir: user_u:system_r:httpd_content_t.s0-s2:c5-c7, Yani s ve c sayıları aslında bir şey ifade ediyor. Özellikle, işlem belirli bir düzey olarak çalışmadığı sürece görebilecekleri bilgiler sınırlı olacak şekilde okuma yok, yazma yok kurulum oluştururlar. Bu bilgi düzeyinin fikri, sınıflandırılmış varlıkları korumaktır - SELinux başlangıçta NSA tarafından, muhtemelen bu amaçla geliştirilmiştir.

Bu sizin arka planınız. Şimdi, web sayfalarına göre (oyun makinesinde SSS ) root UID 0; ancak, kök katı politikasında user_r olarak değil sysadm_r olarak çalışacak şekilde ayarlanmıştır. Bu, kullanıcının Kabuktan yönetim işlevlerini yürütmesine izin verilmeyeceği anlamına gelir.

O halde bilmek ilginç olan, kök gerektiren diğer süreçlerin durumudur. Muhtemelen bu tür süreçler uygun şekilde etiketlenmiştir ve ihtiyaç duydukları erişime izin veren politikalara sahiptir. Bu durumda soru, sistemi nasıl yönettiğinize dönüşür ve bu işlemlerden herhangi biri, kullanıcının bağlamında bir Kabuk başlatabilir. Böyle bir şey olursa, yine de bir istismar yönetebilirsiniz.

Oyun makinesi şu anda kapalı olduğundan (yazma sırasında), burada varsayımlar üzerinde çalışıyorum; ancak temelde, bir istismarın hedefi olarak sysadm_r ve UID 0 ile çalışan bir işleme ihtiyacınız olacaktır. Böyle bir sürecin var olduğunu ve sömürülebilir olduğunu varsayarsak, yine de kök salmış olabilirsiniz. Hala root üzerinden yönetebilmeye gelince, düşünebileceğim iki seçenek var:

• Ya kökün sysadm_r (Daha az güvenli) veya
• Farklı çalışma seviyelerinde, farklı bir ilke geçerlidir, bu nedenle makineyi yönetmek için çalışma seviyesi 1 olarak ayarlanır ve ilke kökle sınırlanmaz. Burada tahmin ediyorum.

Özet

Sorunuz "Şimdi bunu kolayca ve güvenli bir şekilde yapabilir miyim?" cevap hayır. Sorunuz "SELinux hakkında bilgi edinmeye hazırım, dağıtımımla inin ve kirlenin ve işe yaramayan bir çok şeye katlanın." Bununla birlikte, bu hiçbir şekilde istismarlara karşı savunmasız kalmaz - bir kullanıcının bu ekstra erişim kontrolünü yazılımda veya fiziksel olarak atlatmasını imkansız hale getirmez.

Yani evet, işleri kökten görünmez yapabilirsiniz; ancak, ekstra teknik yük bir yana, herhangi bir normal kullanıcı üzerinde herhangi bir erişim kontrolü kurulumu için aynı uyarılar geçerlidir - gümüş mermi yoktur.

Oh ve bariz bir kendini tanıma: sırları yazılımda saklamak ile ilgili blog yayınımı beğenebilirsiniz. Güvenlik stackexchange blogunda, bu yüzden bunu tanıtmak konusunda çok kötü hissetmiyorum. Temel olarak, gördüğünüz gibi, bir saldırgan (ve siz) için hayatı çok daha zor hale getiren mekanizmalar vardır, ancak sonunda, "tamamen kaplumbağaların" bir vakası, yani temel olarak imkansızdır.

Bir web sitesindeki kullanıcılar arasında 'özel mesajlar'ı güvende tutmak isteyen bir müşteri tarafından yaklaşıldığında bu sorunu daha önce çözmek zorunda kaldım. Bazı durumlarda bazı verileri korumak mümkündür, ancak bu oldukça sınırlıdır.

Yaklaşımım, notun şifrelenmiş bir sürümünü sunucuda saklamak ve onlara gönderilmesini sağlamak (elbette kimlik doğrulaması yapıldıktan sonra), daha sonra tamamen istemci tarafı şifresini çözmekti. Bu, sunucu güvenliğinin (yani kök erişiminin) tamamen tehlikeye girmesi durumunda bile notların güvende kaldığı anlamına gelir. Ancak bunun sınırlamaları:

• Korunan veriler yalnızca uzlaşma noktasına kadar güvende olur ve daha sonra olmaz. Bilgiyi şifrelemek için kullanılan yönteme bağlı olarak, köklü bir sunucu kullanıcıyı şifre çözme anahtarlarını (JavaScript yerleştirme veya yerel GUI istemcileri için, güvenliği ihlal edilmiş bir istemci güncellemesi yayınlama) ifşa etmesi veya şifre çözme anahtarlarını başka şekilde engellemesi için kandırabilir kullanıcının parola gibi kimlik doğrulaması ile aynı yöntemi kullanamazlarsa, sunucu tarafı kimlik doğrulama işlemi sırasında bunlar ele geçirilebilir).
• İletim mükemmel bir ileri gizlilik gerektirir, aksi takdirde şifrelenmiş veriler yukarıda ele alındığı gibi ele geçirilebilir, saklanabilir ve daha sonra uzlaşma sonrası şifresi çözülebilir.
• İstemci de tehlikeye atılırsa bu hiçbir şeyi korumaz. Şifrelenmiş verileri tamamen kendi kafanızda işlemediğiniz sürece (ve eğer yapabiliyorsanız, bir kupayı ya da bir şeyi hak ederseniz), bir şey adresine hassas veriler vereceksiniz ve hiçbir şey - mükemmel uzlaşmaz.
• Şifre çözülebilir/düz metin meta veriler yan yana depolanmadığı sürece, bu veri sunucusu tarafını (dizinleme amacıyla) kullanmanın bir yolu yoktur, bu da ek bilgileri gösterebilir.

Esasen bu, bu senaryo için potansiyel kullanımları sınırlar ve hala zayıflıklar vardır, ancak bazı durumlarda çalışması mümkündür. Parola karması (makul) başarılı bir 'kök güvenliğinin aşılması koruması' örneğidir, çünkü fiziksel erişim bile bir kullanıcının parolalarını göstermez (elbette bu paranın ödün verildikten sonra iletilmesi dışında).

Bu iş parçacığında, göz önünde bulundurmaya değer, ancak sunucuyu yalnızca güvenli bir depolama hizmeti olarak kullanan, istemci tarafı işleme senaryosuna biraz dikkat eden başka örnekler de var.

TC

Dosya sisteminde herhangi bir yolla tam kök için bile erişilemeyen, ancak bazı işlemler için erişilebilen dosyalar olabilir mi? Şu anda çalışan bazı işlemler, hatta şu anda erişime sahip işlemler tarafından başlatılan yeni işlemler?

Hayır. Bir işlem onlara erişebildiğinde, kök de olabilir. Bu tür şeyleri yapmak istiyorsanız, tüm sistemi büyük olasılıkla değiştirmelisiniz, muhtemelen bazı salt okunur cihazlardan değiştirilemeyen bir çekirdek önyükleyen ve belirli dosya/bellek erişimlerini kökten reddeden ve diğer kullanıcıların t Taklit etmek.

Sırlar, tam kökün bile onlara hiçbir şekilde erişememesi için süreçleri çalıştırarak bellekte tutulabilir mi? Bu sırlar kökün etkileyemeyeceği bir yolla yeni süreçlere aktarılabilir mi?

Hayır. Yukarıdaki cevaba bakınız.

Tanım gereği, root erişimini kısıtlayamazsınız. Kök erişimini sınırlarsanız, artık kök kullanıcı değildir.

Sırlara kök erişimini reddetmek isteseydim, onları saklamaya çalışırdım. Kriptografik kaplar, takas belleğinde veya başka bir yerde saklanabilir ve yalnızca bir şifre veya başka bir tür steganografi ile erişilebilir. İmkansız olmasa da samanlıkta iğne bulmak çok zordur.

Kökün rasgele kod yürütmesine neden olabilecek birkaç dolaylı yol vardır. Bunları devre dışı bırakabilirsiniz ve gerçekten de bazı güvenlik çerçeveleri bunları devre dışı bırakabilir, ancak köklerin yönetim görevlerini yerine getirme yeteneğini engeller.

Örneğin, root her türlü dosya sistemi izinlerini atlayarak doğrudan disklere okuma ve yazma yapabilir. Bu yeteneği ortadan kaldırabilirsiniz, ancak kök acil bir durumda tam bir dosya sistemini yeni bir diske taşıyamaz.

Kök çekirdek modüllerini yükleyebilir ve böylece çekirdeğin yapabileceği her şeyi yapabilir. Bu özelliği kaldırabilirsiniz, ancak daha sonra çalışırken takılabilir medya için sürücüleri yüklemeyi önlersiniz. (Bu, unix kurulumlarının% .001'inde arzu edilebilir, ancak genel durum bu değildir.)

Kök, login veya sshd gibi kullanıcıların oturum açmasına izin veren yürütülebilir dosyaları güncelleyebilir. Bu cinler kullanıcı kimlik doğrulamasını yapar, bu nedenle kodlarını kontrol ederseniz bir arka kapı enjekte edebilirsiniz. Bu özelliği ortadan kaldırabilirsiniz, ancak kök güvenlik yükseltmeleri gerçekleştiremez.

Kök kullanıcılar oluşturabilir ve kaldırabilir ve kimlik doğrulama bilgilerini değiştirebilir: eğer /etc/passwd hesap eklemek için, hesabı geçici olarak şifresiz yapmak üzere düzenleyebilirsiniz. Kök için bile bazı dosyaları salt okunur yaparak bu yeteneği kaldırabilirsiniz, ancak daha sonra yeniden başlatmadan kullanıcı hesapları oluşturamayacağınız veya kaldıramayacağınız bir sistem elde edersiniz.

Güvenlik çerçeveleri etkin bir şekilde, yalnızca sistemin bir alt kümesinde kök olan “gerçek” sistemde değil, yalnızca sanal bir makinede kök olan sınırlı köklü kullanıcılar oluşturur. Bu sınırlı kök, gerçek sistemde yönetim görevleri gerçekleştirme olasılığını kaybeder. Bence sanallaştırma peşinde olduğun şey.

Bu, "iki anahtar" selinux sistemi kullanılarak nispeten kolayca gerçekleştirilir: root'un hiçbir şey yapma izni yoktur ve kök izinleri olmayan başka bir kullanıcı does, bu yüzden şeyleri değiştirmek için önce kök olmayan diğer kullanıcı, o zaman "su" kök değiştirmek için.

Hiçbir kullanıcı tek başına hiçbir şey yapamaz veya göremez.

Bunu kullanıyorum. Gerçekten iyi çalışıyor.

Asıl ihtiyaç soruda iyi tanımlanmamıştır, ancak bahsedilmediği söylenen iki potansiyel çözüm:

• Kaplar
• HSM'ler

Tabii ki, hapishane ve SELinux gibi araçlarla parça parça yapıldığına daha mimari olarak daha duyarlı bir yaklaşım olan kaplar, sorunun yeniden çerçevelendirilmesi bağlamında alakalı olabilir - unix benzeri mantıklı bir yol var mı sistem saldırganlara maruz kalabilir, böylece kök tehlikeye girebilir, ancak fiziksel sistemdeki sırlar hala korunur. Konteynerlerle bu hedefe yaklaşıyoruz. NCC güvenlik grubu tarafından yakın tarihli bir makale okunmaya değer: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSM'ler, şifre çözme anahtarlarının fiziksel veya mantıksal yöntemlerle alınmasını önleyen donanım şifreleme aygıtlarıdır, bu nedenle yeniden çerçevelenen soruya bir cevap olabilir - güvenli bir şekilde şifresini çözmek zorunda olduğum sırlarım var, anahtarlarla ne yapacağım.

Falcon'un dediği gibi, kök kullanıcı tanımı gereği tüm bu şeylere erişebilir ya da artık kök kullanıcı değildir.

Çekirdek tüm donanımı kontrol eder, böylece root olduktan sonra aynı erişime sahip olursunuz. Gerçekten sanallaştırmaya ihtiyacınız var, bu nedenle root kullanıcınız sadece üzerinde çalıştığı sanallaştırılmış işletim sistemi için kök olmalı ve bazı Hypervisor bunun dışında duruyor root. (hipervizörlerin istismar edilmediğini söylememek, ancak yapmaya çalıştığınız şey buna eşdeğerdir).

Grsecurity'yi denediniz mi? Kök kullanıcılarını mümkün olan her şekilde etkili bir şekilde kısıtlayabilir. https://grsecurity.net/

Grsecurity, PaX ile birleştiğinde kutunuzu imkansız bir kale yapar ...