İş parçacıklarını kullanabilir miyim?
Evet, Sandbox2'de iş parçacıkları desteklenir.
Tüm ileti dizileri korumalı alanda olmalıdır.
Linux'un çalışma şekli nedeniyle seccomp-bpf politikası yalnızca mevcut iş parçacığına uygulanır. Bu, politikanın diğer mevcut iş parçacıklarına uygulanmadığı ancak gelecekteki iş parçacıklarının politikayı devralacağı anlamına gelir:
- Sandbox2'yi ilk modda kullanıyorsanız (
execve()öncesinde sanal alan oluşturma etkinleştirilir) tüm iş parçacıkları politikayı devralır ve herhangi bir sorun yaşanmaz. Bu, tercih edilen sanal alan oluşturma modudur. - Yürütücünün
set_enable_sandbox_before_exec(false)olduğu ve Sandboxee'ninSandboxMeHere()ile sanal ortamda çalışmak istediğinde yürütücüye bildirdiği ikinci modu kullanıyorsanız filtrenin tüm iş parçacıklarına uygulandığından emin olun. Aksi takdirde, korumalı alandan çıkma riski vardır: Kötü amaçlı kod, korumalı alandaki bir iş parçacığından korumalı alan dışındaki bir iş parçacığına taşınabilir.
Sandboxee'mi nasıl derlemeliyim?
Statik olarak bağlı bir yürütülebilir dosya ile karşılaştırıldığında, sandboxee'nin dinamik olarak bağlı bir yürütülebilir dosyaya derlenmesi, izin verilenler listesine eklenmesi gereken sistem çağrılarında (ör. open/openat, mmap vb.) önemli bir artışa neden olur. Paylaşılan kitaplıkları yüklemek için çalışma zamanında dinamik bağlayıcı çağrısı yapıldığından bu ek sistem çağrılarının tümü gereklidir.
Ancak statik olarak bağlı sandboxee'lere bakıldığında: Daha az sistem çağrısının izin verilenler listesine eklenmesi gerekse de güvenlik açısından sonuçları vardır. ASLR yığın entropisi (30 bit'ten 8 bit'e) düşürülür ve bu da saldırıları kolaylaştırır.
Bu ikilem, temelde şu soruya indirgenebilir:
- Dinamik: İyi yığın ASLR, başlangıç kodu yürütme elde etmek zor olabilir ancak daha az etkili bir korumalı alan politikası pahasına, korumalı alandan çıkmak daha kolay olabilir.
- Statik: Kötü yığın ASLR, başlangıçta kod yürütmeyi elde etmek daha kolay olabilir ancak daha etkili bir korumalı alan politikası olduğundan korumalı alanın dışına çıkmak daha zor olabilir.
Geçmişte, statik olarak bağlı ikililer konumdan bağımsız kodu (pie) desteklemiyordu. Ayrıca Bazel, pie'yı varsayılan olarak ekledi. Sıkı bir sistem çağrısı filtresi tanımlayabilmek için Bazel'in varsayılan değerini geçersiz kılmanız gerekiyordu.
Derleyiciler yıllar içinde gelişti ve artık static-pie seçeneğini destekliyor.
Bu seçenekle derleyiciye konumdan bağımsız kod oluşturması talimatı verilir. Ancak pie ile karşılaştırıldığında bu seçenek artık statik olarak bağlanmış tüm kitaplıkları da içerir. Güvenlik açısından static-pie, ASLR entropisini (30 bit'ten 14 bit'e) azaltmaya devam eder ancak bu, pie'nin olmadığı önceki duruma göre bir iyileşmedir.
Bazel, varsayılan olarak pie eklediğinden ve statik bununla uyumlu olmadığından, pie bağlayıcı işaretini cc_binary kuralına iletmek ve varsayılanı geçersiz kılmak için bağlayıcı seçenekleri işaretini kullanmayı düşünebilirsiniz:-static-pie
linkstatic = 1,
linkopts=["-static-pie"],
Bu seçeneklerle ilgili bir örnek için statik örneğe bakın.
BUILD:
static_bin.cc, static-pie ile statik olarak bağlantılıdır. Bu sayede çok sıkı bir syscall politikası uygulanabilir. Bu yöntem, üçüncü taraf ikili dosyalarını korumalı alana almak için de uygundur.
32 bit x86 ikili dosyalarını korumalı alana alabilir miyim?
Sandbox2 yalnızca derlendiği mimariyi korumalı alana alabilir.
Ayrıca, 32 bit x86 desteği Sandbox2'den kaldırıldı. 32 bit x86 ikili dosyasını veya 32 bit sistem çağrıları yapan (int 0x80 aracılığıyla) 64 bit x86 ikili dosyasını korumalı alana almak için 64 bit x86 yürütücü kullanmaya çalışırsanız her ikisi de [X86-32] mimari etiketiyle tanımlanabilen bir korumalı alan ihlali oluşturur.
Bu davranışın nedeni, sistem çağrısı numaralarının mimariler arasında farklılık göstermesidir. Sistem çağrısı politikası, yürütücünün mimarisinde yazıldığından Sandboxee için farklı bir mimariye izin vermek tehlikeli olur. Bu durum, aslında daha zararlı bir sistem çağrısının sandbox'tan çıkışa izin verebileceği, görünüşte zararsız bir sistem çağrısına izin verilmesine yol açabilir.
Bir yürütme işleminin isteyebileceği sanal alan sayısıyla ilgili herhangi bir sınır var mı?
Her Sandboxee örneği (forkserver'dan oluşturulan yeni işlem) için yeni bir iş parçacığı oluşturulur. Sınırlama buradan kaynaklanır.
Bir Yürütücü birden fazla Sandbox oluşturulmasını isteyebilir mi?
Hayır. 1:1 ilişkisi vardır. Bir Executor örneği, Sandboxee'nin PID'sini depolar, Sandbox örneğiyle Comms örneğini yönetir vb.
Neden forkserver.cc içinde "Function not implemented" (İşlev uygulanmadı) hatası alıyorum?
Sandbox2 yalnızca makul ölçüde yeni çekirdeklerde çalışmayı destekler. Şu anda 3.19 çekirdeği destekleniyor ancak bu durum gelecekte değişebilir. Bunun nedeni, TSYNC işaretiyle kullanıcı ad alanları ve seccomp dahil olmak üzere nispeten yeni çekirdek özelliklerini kullanmamızdır.
Üretim ortamında çalışıyorsanız filonun neredeyse tamamı yeterince yeni bir çekirdek kullandığından bu bir sorun olmamalıdır. Bu konuda herhangi bir sorun yaşarsanız lütfen bizimle iletişime geçin.
Debian veya Ubuntu kullanıyorsanız çekirdeğinizi güncellemek için şu komutu çalıştırmanız yeterlidir:
sudo apt-get install linux-image-<RECENT_VERSION>