Sık Sorulan Sorular

İleti dizilerini kullanabilir miyim?

Evet, ileti dizileri Sandbox2'de desteklenir.

Tüm ileti dizileri korumalı alana alınmalıdır

Linux'un çalışma şekli nedeniyle, seccomp-bpf politikası yalnızca geçerli iş parçacığına uygulanır: Bu, politikanın mevcut diğer ileti dizilerine uygulanmadığı, ancak gelecekteki ileti dizilerinin politikayı devralacağı anlamına gelir:

  • Korumalı alanın execve() tarihinden önce etkinleştirildiği ilk modda Korumalı Alan2 kullanıyorsanız tüm ileti dizileri politikayı devralır ve herhangi bir sorun olmaz. Tercih edilen korumalı alan modu budur.
  • Yürütücünün set_enable_sandbox_before_exec(false) değerine sahip olduğu ikinci modu kullanıyorsanız ve Sandboxee, SandboxMeHere() ile korumalı alana almak istediğini yürütücüye bildiriyorsa filtrenin tüm ileti dizilerine uygulandığından emin olun. Aksi takdirde, korumalı alan kaçış riski söz konusudur: Kötü amaçlı kod, korumalı alana alınmış bir iş parçacığından korumalı alanda olmayan bir ileti dizisine taşınabilir.

Sandboxee'mi nasıl derlemeliyim?

Dikkatli değilseniz korumalı alan kullanımını zorlaştıran (tüm yan etkileri izleme) ve daha az güvenli (çünkü sistem çağrısı ve dosya politikaları daha kapsamlı olduğu için) çok sayıda bağımlılığı ve yan efekti (ekstra syscall'lar, dosya erişimleri ve hatta ağ bağlantıları) devralmak kolaydır. Bazı derleme seçenekleri, bu tür sorunların azaltılmasına yardımcı olabilir:

  • Çok sayıda syscall (open/openat, mmap vb.) kullanan dinamik bağlantıdan kaçınmak için Sandboxee ikili programını statik olarak derleyin.

  • Bazel varsayılan olarak pie eklediğinden, ancak statik öğe ile uyumlu olmadığından, cc_binary kurallarında aşağıdaki seçenekleri kullanarak bu özelliği devreye sokmak için özellik işaretini kullanabilirsiniz:

    linkstatic = 1,
features = [
    "fully_static_link",  # link libc statically
    "-pie",
],

Bununla birlikte: Statik kullanımı, ASLR yığın entropisini azaltmanın dezavantajıdır (30 bitten 8 bite kadar). Bu da kötüye kullanımları kolaylaştırır. Korumalı alan uygulamanıza ve politikanıza bağlı olarak neyin tercih edildiğine dikkatlice karar verin:

  • not static: İyi bir yığın ASLR'dir; ilk kod yürütmenin gerçekleştirilmesi potansiyel olarak daha zor olabilir ancak daha az etkili bir korumalı alan politikası pahasına, potansiyel olarak ayrılması daha kolay olur.
  • statik: Bozuk yığın ASLR; ilk kod yürütmenin daha kolay olması potansiyel olarak daha kolay ancak daha etkili bir korumalı alan politikası olup ayrılması potansiyel olarak daha zordur.

Derleyici, statik PIE'yi (Position Independent Executables) desteklemediğinden maalesef bir seçim yapmanız gerekir. PIE, ikili programın dinamik bir nesne olmasını sağlayarak uygulanır. Dinamik yükleyici ise ikili programı yürütmeden önce rastgele bir konumda eşler. Daha sonra, yığın geleneksel olarak ikili programın taban adresinden sonra rastgele bir ofsete yerleştirildiği (ve brk syscall ile genişletildiği) için bu, statik ikili programlar için yığın ASLR entropisinin PIE olmadığından yalnızca bu ofset olduğu anlamına gelir.

Bu derleme seçeneklerinin örnekleri için statik BUILD.bazel örneğine bakın: static_bin.cc statik olarak derlendiği için çok sıkı bir sistem çağrısı politikamıza sahip oluruz. Bu, üçüncü taraf ikili dosyalarının korumalı alana alınması için de iyi bir şekilde çalışır.

32 bit x86 ikili kodlarını korumalı alana alabilir miyim?

Sandbox2 yalnızca derlendiği aynı mimariyi korumalı alana alabilir.

Ayrıca, 32 bit x86 desteği Sandbox2'den kaldırılmıştır. Bir 32 bit x86 ikili programını veya 32 bit sistem çağrıları yapan 64 bit x86 ikili programını (int 0x80 aracılığıyla) korumalı alana almak için bir 64 bit x86 yürütücü kullanmaya çalışırsanız, her ikisi de mimari etiketiyle [X86-32] 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 verilmesi tehlikeli olacaktır. Bu durum aslında zararsız gibi görünen ve daha zararlı başka bir sistem çağrısının korumalı alanı bir kaçamak için açabileceği anlamına gelir.

Bir yönetici işleminin isteyebileceği korumalı alan sayısıyla ilgili herhangi bir sınır var mı?

Her Sandboxee örneği (çatal sunucusundan üretilen yeni işlem) için yeni bir iş parçacığı oluşturulur. Sınır burada bulunur.

Bir Yürütücü birden fazla Korumalı Alan oluşturulmasını isteyebilir mi?

Hayır. Bir 1:1 ilişki vardır. Yürütücü örneği Sandboxee'nin PID'sini depolar, İletişim örneğini Korumalı Alan örneğine yönetir vb.

Neden forkserver.cc içinde "İşlev uygulanmadı" mesajını alıyorum?

Sandbox2 yalnızca makul ölçüde yeni çekirdeklerde çalışmayı destekler. Şu an için son sınırımız 3.19 çekirdeği olsa da bu oran ileride değişebilir. Bunun nedeni, kullanıcı ad alanları ve TSYNC işaretine sahip seccomp gibi nispeten yeni çekirdek özellikleri kullanmamızdır.

Üretimde çalışıyorsanız filonun neredeyse tamamı yeterince yeni bir çekirdeği çalıştırdığından bu sorun yaşanmaz. Bu konuda herhangi bir sorun yaşarsanız lütfen bize ulaşın.

Debian veya Ubuntu'da çalıştırıyorsanız çekirdeğinizi güncellemek aşağıdaki çalıştırma kadar kolaydır:

sudo apt-get install linux-image-<RECENT_VERSION>