Linux'ta zararlı olabilecek programın yürütülmesi

Öğrenciler tarafından yazılmış programları test edecek bir program yazıyorum. Korkarım ki onlara güvenemiyorum ve çalışan bilgisayar için kötü sonuçlanmayacağından emin olmalıyım.

Sistem kaynaklarına sınırlı erişime sahip bazı çarpışma testi yapan bir kullanıcı yapmayı ve o kullanıcı olarak programlar çalıştırmayı düşünüyordum, ancak şimdiye kadar internette bulduğum şeyden sanal bir sistem yapmak en güvenli seçenek ...

Birisi bana doğru yaklaşımı seçmekte yardımcı olabilir mi? Güvenlik benim için büyük bir endişe. Öte yandan, gereğinden fazla olmayan ve gerçekten ihtiyacım olmayan bir şeyi öğrenmek için fazla zaman harcayan bir çözüm istemiyorum.

• Sanal makine size yeniden başlatmadan en yüksek güvenliği sağlayabilir, ancak en düşük performansı sağlayabilir.

• Sanal bir makineden daha yüksek güvenlik için başka bir seçenek: sabit sürücüye erişmeden "canlı" bir CD / DVD / pendrive'ı başlatın (BIOS'ta HDD'yi geçici olarak devre dışı bırakın; yapamıyorsanız, en azından sürücüyü takmayın / otomatik olarak monte edilmişse, sökünüz - fakat bu çok daha az güvenlidir)

• Bir liman işçisi konteyner tam bir sanal makineye biraz daha az güvenli bir alternatiftir. Muhtemelen bu ikisi arasındaki en önemli fark (güvenlik açısından) liman işçisi olarak çalışan sistemlerin aslında ana sisteminizin çekirdeğini kullanmasıdır.

• Özel, güvenli bir ortam yaratacak izolat gibi programlar var - buna genellikle sanal alan denir - bunlar genellikle chroot temellidir, ek denetimle - size uygun olanı bulurlar.

• Basit bir chroot en azından güvenli olacaktır (özellikle programların yürütülmesiyle ilgili olarak), belki biraz daha hızlı olsa da, fakat ... Bütün bir kök ağacı kurmanız / kopyalamanız ve bağlama bağları /devvs. kullanmanız gerekir (bkz. Not 1 altında!). Bu nedenle, genel olarak, bu yaklaşım, özellikle daha güvenli ve genellikle daha kolay bir sandboxortam oluşturmak için kullanabiliyorsanız önerilemez.

0 Not: "özel kullanıcı" yönü için, gibinobodyhesaba: Bu verir neredeyse hiç çok daha az hatta basit değil, güvenlikchroot. Birnobodykullanıcı, başkaları için ayarlanmış izinleri okuma ve yürütme dosyalarına ve programlarına erişebilir. İle test edebilirsiniz. Ayrıca, herhangi birinin erişebileceği herhangi bir yapılandırma / tarih / önbellek dosyanız varsa (bir hata veya küçük bir güvenlik deliği ile),izinleriile çalışan bir programerişebilir, gizli veriler için grep ("pass =" vb.) Ve birçok yol onu ağ üzerinden ya da her neyse gönderir.su -s /bin/sh -c 'some command' nobodynobody

Not 1: Gilles, aşağıdaki açıklamada belirtildiği gibi , basit bir chroot ortamı, ayrıcalık artışını amaçlayan istismarlara karşı çok az güvenlik sağlayacaktır. Bir tek chroot, duyu güvenlik açısından kılan yalnızca çevre güvenliği teyit programların oluşan minimal sadece (ama hala potansiyel çekirdek düzeyinde güvenlik açıklarını riskini kalır) ve chroot çalışan tüm güvenilmeyen programları çalıştıran chroot dışında herhangi bir işlem yürütmeyen bir kullanıcı olarak. Chroot'un önlediği şey (burada belirtilen kısıtlamalarla), ayrıcalık artışı olmadan doğrudan sisteme nüfuz etmedir. Ancak, Gilles'un başka bir yorumda belirttiği gibiBu program bile, bir programın chroot'tan çıkmasına izin vererek, bu durumun üstesinden gelebilir.

Sanal bir makine kullanın. Daha az bir şey fazla güvenlik sağlamaz.

Birkaç yıl önce chrooted adanmış bir kullanıcı ya da bazılarını önerebilirdim. Ancak donanım daha güçlü hale geldi ve sanal makine yazılımı kullanımı daha kolay hale geldi. Ayrıca, kullanıma hazır saldırılar daha sofistike hale geldi. Buraya kadar gitmemek için artık bir neden yok.

VirtualBox çalıştırmanızı tavsiye ederim. Sanal makineyi birkaç dakika içinde kurabilir, ardından içine bir Linux dağıtımı yükleyebilirsiniz. Önerdiğim varsayılan olmayan tek kurulum ağ kurulumudır: hem “NAT” arayüzü (dünyayla iletişim kurmak için) hem de “yalnızca ana bilgisayar” arayüzü oluşturun (böylece, dosyaları ana makineye ve ana bilgisayardan kolayca kopyalayabilirsiniz ve VM). Öğrencilerinizin programlarını çalıştırırken NAT arayüzünü devre dışı bırakın¹; yalnızca yazılım paketlerini yüklerken veya yükseltirken etkinleştirin.

Sanal makinenin içinde, öğrenci başına bir kullanıcı oluşturun.

İnterface _{NAT arayüzünü kullanıcıların bir beyaz listesiyle sınırlandırabilirsiniz, ancak bu basit, noktaya bir kurulumda ihtiyacınız olandan daha gelişmiş.}

Burada, Chroot'u kullanmanın neden hala uygun bir seçenek olduğu ve neden belirli işletim sistemlerinde tam işletim sistemi veya tam donanım sanallaştırmasının önemsenmediğine dair ayrıntılı bir açıklama yer almaktadır.

Chroot'un bir güvenlik özelliği olmadığı bir efsaneden başka bir şey değildir. chroot dosya sistemini sizin için otomatik olarak oluşturacak araçlar vardır ve Chroot, birçok güvenlik uygulamasına amaçlı bir güvenlik özelliği olarak eklenmiştir.

Popüler inanışın aksine, her durum işletim sisteminin tamamen sanallaştırılmasını veya donanımın tam simülasyonunu gerektirmez. Bu aslında denemek ve örtmek için daha fazla saldırı yüzeyine sahip anlamına gelebilir . sırayla, bir daha az güvenli bir sistem demektir . (daha az bilgili sistem yöneticileri için iddia edilir)

Kurallar oldukça basit: chroot içine gerekli olmayan hiçbir şey koymayın. Bir daemon'u root olarak çalıştırmayın. Bir daemon'u chroot dışında bir daemon çalıştıran herhangi bir kullanıcı olarak çalıştırmayın.

güvensiz uygulamaları, setuid ikilileri, sahipsiz sembolik bağlantıları / hardlinksleri silerek kaldırın. nosuid, noexec ve nodev kullanarak gereksiz klasörleri yeniden birleştirin. Çalışan servisin son kararlı sürümünü kaynaktan derleyin. ve ve hepsinden önemlisi, temel sistemi emniyete alın!

Bunu ekleyeceğim, soru resmen cevaplandıktan sonra: MAGIC: Devrelerde / Çekirdekte Kötü Amaçlı Yaşlanma Ne yazık ki ACM'nin ödeme duvarının arkasında kilitli olan . Kağıdın sonuçta, kullanımda olan devrelerde kullanımda çok küçük genişlik izleri olduğu ve kullanım sırasında yıkıldığı ve sonuçta yıkıldığı görülmektedir. Bir saldırgan doğru talimat (ları) bularak ve tekrar tekrar tekrarlayarak, IC'leri hızla başarısızlığa götürebilir.

VM ya da sanal alan ya da konteyner ya da chroot hapishanelerinin hiçbiri bu tür kötü amaçlı donanım imhasını engellemez. Makalenin yazarları bu tür talimat dizileri ve deneysel olarak donanımın arızalanmasına neden olmuş, ancak talimatları vermemişlerdir, bu nedenle bir süre için gerçek bir tehdit olmayabilir.

BSD'den türetilmiş unixlerde (Mac OS X dahil) denilen bir tesis var sandbox. Manpage diyor ki

AÇIKLAMA sanal tesis uygulamaları gönüllü işletim sistemi kaynaklarına erişimlerini kısıtlamak için izin verir. Bu güvenlik mekanizmasının, bir güvenlik açığından yararlanılması durumunda olası hasarı sınırlaması amaçlanmıştır. Diğer işletim sistemi erişim kontrollerinin yerine geçmez.

Bu, chrootmevcut olan tesisten ayrıdır .