Dikkat edilmesi gereken daha fazla cevabı olan daha benzer sorular:
NOT: Buradaki cevapların bazıları, burada henüz belirtilmeyen özel çözümlere işaret etmektedir.
Aslında, farklı uygulanması ile epeyce jailing araçları var, ama bunların çoğu ya tasarım gereği güvenli değildir (gibi fakeroot, LD_PRELOADtabanlı), ya da değil tamamlandı (gibi fakeroot-ng, ptracetabanlı) veya (kök gerektirecektir chrootya plashda belirttiğimiz fakechroot uyarı etiketi ).
Bunlar sadece örnek; Bunların hepsini yan yana listelemeyi düşündüm, bu 2 özelliğin ("güvenilir olabilir mi?", "Kök kurulumu gerekiyor mu?") Göstergesiyle, belki de İşletim sistemi düzeyinde sanallaştırma Uygulamalarında .
Genel olarak, buradaki cevaplar açıklanan tüm olasılıkları ve hatta daha fazlasını kapsar:
sanal makineler / işletim sistemi
çekirdek uzantısı (SELinux gibi)
- (burada yorumlarda belirtilen),
chroot
Chroot tabanlı yardımcılar (bunun için setUID kökü olması gerekir, çünkü chrootkök gerektirir; veya belki de chrootyalıtılmış bir ad alanında çalışabilir - aşağıya bakın):
[onlar hakkında biraz daha fazla şey anlatmak için!]
Bilinen chroot tabanlı izolasyon araçları:
- onun
hsh-runve hsh-shellkomutları ile hasher . ( Hasher yazılımı güvenli ve tekrarlanabilir bir şekilde oluşturmak için tasarlanmıştır.)
- Başka bir cevapta belirtilen schroot
- ...
ptrace
(Yanı sıra başka güvenilir izolasyon çözüm bir seccompmerkezli bir ) üzerinden tam syscall-durdurma olacaktır ptraceiçin manpage açıklandığı gibi, fakeroot-ng:
Önceki uygulamalardan farklı olarak, sahte uygulama, izlemeli işlemi sahte fırlatma işleminin "hizmetlerini" kullanıp kullanmayacağına ilişkin hiçbir seçenek bırakmayan bir teknoloji kullanır. Bir programı statik olarak derlemek, çekirdeği doğrudan çağırmak ve kendi adres alanlarını değiştirmek, işlem sırasında LD_PRELOAD tabanlı kontrolü atlamak için önemsizce kullanılabilecek ve sahte uygulama için geçerli olmayan tüm tekniklerdir. Teorik olarak, iz bırakma işlemi üzerinde tam kontrole sahip olacak şekilde sahte köklendirme yapmak mümkündür.
Teorik olarak mümkün olsa da henüz yapılmamıştır. Fakerooting, izlenmekte olan süreçle ilgili belirli "güzel davranışlı" varsayımları kabul eder ve bu varsayımları ihlal eden bir süreç, eğer tamamen kaçmazlarsa, en azından sahte tarafından çevrilen "sahte" ortamın bir kısmını dolaştırabilir. ng. Bu nedenle, sahte aracı bir güvenlik aracı olarak kullanmama konusunda şiddetle uyarılırsınız. Hata, bir sürecin kasten (istemeden aksine) kaçmasının sahte bir kökünden kaçabileceğini iddia ettiğini bildirir.
Bu politikanın gelecekte yeniden düşünülmesi mümkündür. Bununla birlikte, şu an için uyarıldısınız.
Yine de, okuyabileceğiniz gibi, fakeroot-ngkendisi bu amaç için tasarlanmamıştır.
(BTW, neden seccompChromium için- tabanlı bir yaklaşımı kullanmayı tercih ettiklerini merak ediyorum ptrace...)
Yukarıda belirtilmeyen araçlardan kendim için Geordi'ye dikkat çektim, çünkü kontrol programının Haskell'de yazılmasından hoşlandım.
Bilinen parça tabanlı izolasyon araçları:
Seccomp
İzolasyon elde etmenin bilinen bir yolu , Google Chromium'da kullanılan seccomp sanal alan yaklaşımından geçer . Ancak bu yaklaşım, "ele geçirilen" dosya erişiminin ve diğer sistem çağrılarının bazılarını (izin verilenleri) işleyecek bir yardımcı yazdığınızı varsayar; ve ayrıca, elbette, sistemlere "müdahale" etmek ve onları yardımcıya yönlendirmek için çaba harcamak (belki de, ele geçirilen sistemlerin kontrol edilen işlem kodunda değiştirilmesi gibi bir şey anlamına geleceği anlamına gelir; oldukça basit olmak gerekirse, eğer ilgileniyorsanız, sadece benim cevabımdan ziyade detayları okusanız iyi olur).
Daha fazla ilgili bilgi (Wikipedia'dan):
( seccompChromium'un dışında bir genel tabanlı bir çözüm arıyorsanız, son madde ilginç görünüyor . Ayrıca "seccomp-nurse" yazarından okunmaya değer bir blog yazısı var: Sandboxing çözümü olarak SECCOMP? )
"Seccomp-nurse" projesinden bu yaklaşımı gösteren örnek resim :
Linux'un geleceğinde "esnek" bir sekcomp.
Ayrıca 2009'da Linux çekirdeğini yamalama önerileri vardı, seccompböylece mod için daha fazla esneklik elde edildi - "şu anda ihtiyaç duyduğumuz akrobasi çoğundan kaçınılabilecekti". ( "Akrobasi" hapisteki sürecin adına ve hapisteki süreçte muhtemelen masum syscalls yerine birçok muhtemelen masum syscalls yürütmek zorunda olan bir yardımcı yazma komplikasyonlar ifade eder.) Bir LWN ürün bu noktaya yazdı:
Ortaya çıkan bir öneri seccomp'e yeni bir "mod" eklemek oldu. API, farklı uygulamaların farklı güvenlik gereksinimlerine sahip olabileceği düşüncesiyle tasarlanmıştır; yerine getirilmesi gereken kısıtlamaları belirten bir "mod" değeri içerir. Sadece orijinal mod şimdiye kadar uygulandı, ancak diğerleri kesinlikle eklenebilir. Hangi sistem çağrısına izin verileceğini belirten başlatma işlemine izin veren yeni bir mod oluşturmak, tesisi Chrome sanal alanı gibi durumlar için daha kullanışlı hale getirir.
Adam Langley (ayrıca Google) da bunu yapan bir yama yayınladı. Yeni "mod 2" uygulaması, hangi sistem çağrılarının erişilebilir olduğunu açıklayan bir bit maskesini kabul eder. Bunlardan biri prctl () ise, sanal alan kodu kendi sistem çağrılarını daha da kısıtlayabilir (ancak reddedilen sistem çağrılarına erişimi geri yükleyemez). Tüm bunlar, sanal alan geliştiricileri için hayatı kolaylaştırabilecek makul bir çözüme benziyor.
Bununla birlikte, bu kod asla birleştirilemez çünkü tartışma o zamandan beri başka olasılıklara geçti.
Bu "esnek sekonder", Linux'un OS'de istenen özelliği sağlamaya daha da zorlaştıracak, karmaşık olan yardımcıları yazmaya gerek kalmayacaktı.
(Temelde bu cevapla aynı içeriğe sahip bir blog yazısı: http://geofft.mit.edu/blog/sipb/33 .)
ad alanları ( unshare)
Ad alanlarını yalıtmak ( unsharetemelli çözümler ) - burada belirtilmemiş - örneğin, bağlantı noktalarını (FUSE ile birleştirmek) paylaştırmak belki de güvenilmeyen işlemlerinizin dosya sistemi erişimini sınırlandırmak istediğiniz için çalışan bir çözümün parçası olabilir.
Ad alanları hakkında daha fazlası, şimdi, uygulamaları tamamlandığı için (bu izolasyon tekniği aynı zamanda "Linux Containers" veya "LXC" adı altında da bilinir , değil mi? ..):
"Ad alanlarının genel hedeflerinden biri, hafif sanallaştırma (ve diğer amaçlar için) olan bir araç olan kapların uygulanmasını desteklemektir" .
Yeni bir kullanıcı ad alanı oluşturmak bile mümkündür, böylece "bir işlem, bir kullanıcı ad alanının dışında normal bir ayrıcalıklı kullanıcı kimliğine sahip olabilirken, aynı zamanda ad alanında 0 kullanıcı kimliğine sahip olabilir. Bu, işlemin tam kök ayrıcalıklarına sahip olduğu anlamına gelir. kullanıcı ad alanındaki işlemler için, ancak ad alanının dışındaki işlemler için ayrıcalıklı değil ".
Bunu yapmak için gerçek çalışma komutları için aşağıdaki cevaplara bakın:
ve özel kullanıcı alanı programlama / derleme
Ancak, elbette, istenen "hapis" garantileri, kullanıcı alanında programlama yapılarak uygulanabilir ( işletim sistemi kaynaklı bu özellik için ek bir destek olmadan ; belki de bu özellik işletim sistemlerinin tasarımında ilk sırada yer almamış olabilir). ); az ya da çok komplikasyonlu
Bahsedilen ptrace- veya seccomptemelli kum havuzu, "Unix programları" keyfi olarak "kara kutular" olarak değerlendirilecek olan diğer işlemlerinizi kontrol edecek bir kum kutusu yardımcı yazarak, garantilerin uygulanmasının bazı değişkenleri olarak görülebilir.
Başka bir yaklaşım, izin verilmeyen etkilerle ilgilenebilecek programlama tekniklerini kullanmak olabilir. (O zaman programları yazan kişi sen olmalısın; artık kara kutular değiller.) Birini söylemek gerekirse, saf bir programlama dili kullanarak (sizi yan etkiler olmadan programlamaya zorlar) Haskell gibi sadece tüm etkilerini yapar. programın açık olması, böylece programcının kolayca izin verilmeyen bir etkisi olmayacağından emin olabilirsiniz.
Sanırım, programlama için başka bir dilde, örneğin Java gibi, kum havuzu olanakları var.
Bu konuyla ilgili bilgi toplayan bazı sayfalar, oradaki cevaplara da işaret etti: