Mümkün olan en basit güvenli korumalı alan (sınırlı kaynak gerekir)

Dağıtılmış simülasyonlar uygulayan bir proje üzerinde çalışıyorum: rasgele kod birden çok düğüm üzerinde yürütülür ve sonuçları daha sonra toplanır ve toplanır.

Her düğüm bir Ubuntu Linux sanal makinesinin bir örneğidir ve yürütülecek kodu bir dizi çalışan işleme (her çekirdek için 1 adet) iletmekle ilgilenen bir ana işlem yürütür.

Bu soru, her çalışanın, her biri için sanal makine örneği kullanımına başvurmadan korumalı bir ortamda çalıştığından nasıl emin olacağınızla ilgilidir. İşçiler için kesin gereksinimler şunlardır:

• fs : yazma izni yok, tek bir dizin (ve alt klasörler) ile sınırlı salt okunur izin
• net : yalnızca yerel iletişime izin verilir (IPC, TCP, her neyse ...)
• mem : bellek kullanımı sınırı (takas belleği yok) mem sınırı aşıldığında öldür
• cpu : sadece 1 çekirdeğe izin verilir, zaman aşımı durumunda öldür

Başka bir sınırlama getirilmemelidir: çalışan dinamik kütüphaneleri (salt okunur klasörden) yükleyebilmeli, yeni iş parçacıkları veya süreçleri oluşturabilmeli, sistem işlevini çağırmalı, ecc ecc olmalıdır, ancak sınırlar doğmuş / yüklenmiş varlıklar tarafından devralınmalı ve toplam olarak uygulanmalıdır (örneğin, bir işçinin 800MB kullanan iki iş parçacığı üretemediğimizde, her biri bu tür bir işçinin bellek sınırı 1 GB'dir).

İşçinin haklarını yükseltmesinin bir yolu olmaması gerektiğini söylemeye gerek yok.

Gereksinimlerimi karşılayan en basit çözüm için mevcut alternatifleri (SELinux, AppArmor, cgroups, ulimit, Linux ad alanları, LXC, Docker, ...) gözden geçirmek için epey zaman harcadım, ancak alandaki deneyimim sınırlı.

Şu anki anlayış: LXC ve Docker, kullanım durumum için biraz ağır tarafta ve tamamen güvenli değil 1 . AppArmor, daha kolay yapılandırma nedeniyle SELinux'a tercih edilir, fs ve net kısıtlamalar için kullanın; ulimit'e tercih edilen cgroups (tek bir işlemde çalışır), mem ve cpu kısıtlamaları için kullandı.

Hedefime ulaşmanın en basit yolu bu mu? AppArmor veya gruplarını yalnızca kullanabilir miyim? Modelimde belirgin bir güvenlik açığı var mı? Kılavuz "işçinin kendisini başka bir şeyden aşağı indirmesine izin verilmelidir " olmalıdır .

Evet, yürüteceğiniz rastgele kodu izlemek ve denetlemek için yalnızca cgroups ve SELinux / AppArmor komutlarını kullanabilirsiniz .

Gruplarla aşağıdakileri yapabilirsiniz:

1. CPU çekirdek kullanımını cpusetalt sistemle 1 CPU ile sınırlayın
2. memoryÇatalları bile izleyerek alt sistemle bellek kullanım sınırlarını belirleyin . Örnek için https://github.com/gsauthof/cgmemtime adresine bakın .
3. Üzerinde değil şey engelle ağ erişim loile net_prioalt sistem.

SELinux / AppArmor ile sürecin okuma / yazma erişimini sınırlandırabilirsiniz.

Not: AppArmor'u bilmiyorum, ancak Zorunlu Erişim Kontrolü (MAC) sistemidir, yani yazma ve okumayı korumak iştir.

Bu sistemleri kullanmak, uygun konfigürasyonların yazılması meselesidir. Tabii ki, bütün bunlar söylenenden çok daha kolay. İşte başlamanız için birkaç referans bağlantısı:

• RedHat'ın Kaynak Yönetimi Kılavuzu
• ArchLinux's CGroup Wiki

İyi şanslar!

Ben atmak istiyorum SELinux'u için AppArmor'u kullanıyorum edilmeleri halinde Ubuntu . (gerçekten oldukça zor)

LXC kendi başına güvenli değildir Güvenliğe ihtiyacınız varsa bunları libvirt ( SELinux MLS tabanlı ) ile kullanmalısınız.

Sorununuz sonsuzdur, bu yüzden rafta herhangi bir çözüm bulmaya çalışmayın ve sonsuz zaman olmadan, kernel.org'un bile kandırıldığını ve çok yakın bir zamanda FBI , birisinin sistemlerini şimdiye kadar tespit edilmeden yıllardır kullandığını söyledi.

LXC / libvirt ile oldukça iyi bir güvenlik için gideceğim ya da DAX / KSM'nin açık kullanımı ile konteynırınız için çok hafif bir VM kullanan "yeni" intel açık kapları deneyeceğim (test etmedim ama çok görünüyorlar gerçekten umut verici).

Çekirdek sömürüsü hakkında endişeleriniz varsa, grsecurity sizin çözümünüzdür, ancak bunu konteyner çözümünüzle entegre etmeniz gerekir (kesin olarak baş ağrıları).

Bu yüzden kolay bir iş değil, LXC / libvirt gerçekten temiz ama belki de açık kaplar gitmek için bir yol.

Liman işçisi? Vagrant kutusu mevcut olmadığında docker'ı yerel testlerden daha fazlası için kullanmadım / kullanmayacaktım, daha fazla iş ve daha iyi bir topluluğa ihtiyaç duyuyorlar.

Tabii ki systemd kapları da güzel ama onları sevmiyorum / istemiyorum çünkü onlardan bile bahsetmediniz ve onlar satıcı agnostik bir çözüm değildir.

"Daha kolay" ve daha amatör bir şey istiyorsanız, firejail'i kontrol edebilirsiniz , bazı masaüstü "uygulamaları" için kullanıyorum ve bu işi yapıyor (özel uygulamanız için şablon oluşturmak oldukça kolaydır, "özel" kullanın direklerinizin üstüne monte edilir ve ağı yalnızca yerel kullanım için kısıtlar, ortaya çıkan süreçler ebeveyn için miras alır ve devam eder ...).

Şerefe ve çıldırmadan eğlenin. ;)

seccomp-bpf, OpenSSH, vsftpd ve Chromium için iyi çalışan başka bir seçenektir ve yapılandırılabilir Berkeley Paket Filtresi kurallarını kullanarak sistem çağrılarının filtrelenmesine izin vermesine rağmen, sadece exit (), sigreturn (), read () kullanır. Ayrıca bellek, cpu vb.Için cgroups ile birlikte kullanılabilir ...

https://wiki.mozilla.org/Security/Sandbox/Seccomp

Izgara bilgi işlem sistemlerine bakmak isteyebilirsiniz. Özellikle, BOINC ( http://boinc.berkeley.edu ) neredeyse tüm kutularınızı kontrol eder.

Ben senin gibi parametreler üzerinde çalışır inanıyorum:

fs: başka bir yerde kendi dizinini okuyamaz / yazamaz

net: yalnızca BOINC sunucunuza ağ erişimine izin verecek şekilde yapılandırılabilir, ancak IIRC kutusundan varsayılan olarak çıkmaz

mem: evet, boşta ve boşta duran makineler için ayrı bellek sınırları

cpu: evet, "bilgisayar boşta değilse çalışma" diyebilir