Sık Sorulan Sorular

İş parçacıklarını kullanabilir miyim?

Evet, Sandbox2'de iş parçacıkları desteklenir.

Tüm iş parçacıkları 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 execve() öncesinde sanal alanın etkinleştirildiği ilk modda kullanıyorsanız tüm iş parçacıkları politikayı devralır ve herhangi bir sorun yaşanmaz. Tercih edilen sanal alan modu budur.
  • Yürütücünün set_enable_sandbox_before_exec(false)'ye sahip olduğu ve Sandboxee'nin SandboxMeHere() ile sandbox'a alınmak istediği zaman yürütücüye söylediğ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ı alan içeren bir iş parçacığından korumalı alan içermeyen 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ın yüklenmesi 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ğlanmış sandboxee'lere baktığımızda, izin verilenler listesine daha az sistem çağrısı 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 şekilde özetlenebilir:

  • Dinamik: İyi yığın ASLR, başlangıç kodu yürütmesini elde etmek zor olabilir ancak daha az etkili bir korumalı alan politikası pahasına, korumalı alanın dışına çıkmak daha kolay olabilir.
  • Statik: Kötü yığın ASLR, başlangıçta kod yürütmeyi kolaylaştırabilir ancak daha etkili bir korumalı alan politikası olduğundan korumalı alanın dışına çıkmak zorlaşabilir.

Geçmişte, statik olarak bağlı ikililer konumdan bağımsız kodu (pie) desteklemiyordu. Ayrıca Bazel, pie özelliğini 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çeneklerin bir örneği için statik örneğe bakın. BUILD: static_bin.cc, static-pie ile statik olarak bağlantılıdır. Bu da çok sıkı bir syscall politikası oluşturmayı mümkün kılar. Bu yöntem, üçüncü taraf ikili dosyalarını korumalı alanda test etmek 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, korumalı alanı kaçışa açabileceği anlamına gelen, 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.

Why do I get “Function not implemented” inside forkserver.cc?

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şaretli seccomp ve kullanıcı ad alanları gibi 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>