Neden Linux kapsayıcılarınız için Çok Kategori Güvenliği Kullanmalısınız

06.08.2020

Son yazımızda, SELinux u ve kapsayıcı güvenliğini artırmak için nasıl kullanılabileceğini tartıştık. Ayrıca Çok Seviyeli Güvenlik (MLS) ve Çok Kategorili Güvenlik (MCS) modellerine baktık. Bu yazımızda, bu modelleri karşılaştıracağız ve MCS'nin neden kapsayıcı güvenliğine daha iyi bir yaklaşım olduğuna inandığımızı açıklayacağız.

Çoğu zaman SELınux un kapsayıcılar için politikasını "Vegas'ta yaşananlar Vegas'ta kalır" olarak tanımlıyoruz. Bununla kastettiğimiz; işlemleri kapsayıcı dosya sisteminin içinde tutmak için SELinux kullanıyoruz. Bir şekilde kapsayıcı sınırlamasından çıkarsa, SELinux ana bilgisayar dosya sistemlerindeki diğer içerikleri okumasını ve yazmasını engelleyebilir.

SELinux'un dosya sistemi saldırılarına dayalı olarak kapsayıcı kesintilerini engellediği kanıtlanmıştır. MLS'nin amacı da aynı duyarlılık düzeyinde çalışan işlemlerin tüm içeriği aynı seviyede okumasına/yazmasına izin vermesi açısından benzerdir.

Kapsayıcı ortamları, ana bilgisayar dosya sistemini kapsayıcı işlemlerinden korumak için Tür zorlama özelliğini kullanır. Hemen hemen her kapsayıcı SELinux işlem türü container_t ile çalışır. Kapsayıcı içindeki tüm içerik SELinux dosya türü container_file_t ile etiketlenir. SELinux kuralları container_t öğesinin container_file_t etiketli tüm içeriği okuyabileceğini / yazabileceğini / yürütebileceğini belirtir. Bu, container_t'ın yazabileceği tek türdür, bu nedenle bir kapsayıcı bozulursa shadow_t, user_home_t, database_t… gibi başka türlerin yazılması engellenir.

Bir kapsayıcı sisteminde tür zorlaması yeterli değildir, çünkü sistemde aynı anda birden fazla kapsayıcı çalıştırmak istiyoruz. Her kapsayıcı için yeni bir işlem türü oluşturabiliriz, ancak o zaman da yeni dosya türleri oluşturmamız gerekir ve kısa süre içinde sistem yönetilemez hale gelir. Yukarıda belirtildiği gibi, her kapsayıcıdaki tüm kapsayıcı işlemleri container_t olarak çalışır, bu nedenle bir kapsayıcının diğerine saldırmasını önleyen bir mekanizmaya ihtiyacımız vardır.

Bunu başarmak için MCS etiketleri kullanıyoruz. Temelde kapsayıcı motoru (Podman, Docker, Buildah, CRI-O…) iki kategoriye sahip rastgele bir eşsiz MCS Etiketi seçer. Daha sonra motor, kapsayıcı görüntüsünün etiketlerini MCS etiketiyle ve container_file_t türüyle eşleşecek şekilde ayarlar. Görüntü monte edildikten sonra, kapsayıcı motoru kapsayıcı işlemini eşleşen MCS etiketi ile başlatır. Her kapsayıcı farklı bir MCS etiketi ile başlatılır ve çekirdek bir MCS etiketli kapsayıcı işlemlerinin farklı bir MCS etiketi ile etiketlenmiş kapsayıcı dosyalarıyla ve işlemleriyle etkileşmesini önler.

Özetle, bir MCS sisteminde kategoriler, kapsayıcılarda benzersizlik sağlamaktan başka bir şey ifade etmez ve saldırıya uğramış bir kapsayıcının sistemdeki diğer kapsayıcılara saldıramayacağını garanti etmek için kullanılır.

MLS'de duyarlılık ve Kategoriler bir şey ifade eder. MLS, sistemdeki farklı süreçler arasındaki bilgi akışını kontrol etmek için tasarlanmıştır. Bir işlemin, dosya sistemine yazarak veya yuvalar üzerinden iletişim kurarak verilerin duyarlılık düzeyini artırıp arttıramayacağını denetler. MLS, farklı ağ kartlarındaki bilgi akışını kontrol etmek için de kullanılabilir.

Kapsayıcı sistemlerinde, sistemdeki farklı kapsayıcı işlemleri arasındaki tüm bilgi akışını engelliyoruz. Kapsayıcı işlemleri, yalnızca ağ üzerindeki farklı kapsayıcılardaki diğer işlemlerle iletişim kurabilir.

Kapsayıcı sistemleri, kapsayıcıları birbirine bağlamak için sanal özel ağları kullanır. Bu, farklı güvenlik düzeylerinde ve / veya farklı kategorilerde çalışan iş yüklerinin dosya sistemi üzerinden diğer kapsayıcılarla iletişim kuramayacağı ve yalnızca birlikte bağlandıkları kapsayıcılarla ağ üzerinden iletişim kurabilecekleri anlamına gelir. Bu, MLS özelliklerini çok daha az değerli kılar.

MLS tabanlı bir kapsayıcı sisteminin MCS tabanlı olandan daha az güvenli olacağını savunuyorum, çünkü benzer verileri işledikleri için aynı MLS Etiketi ile aynı sistem üzerinde birden fazla farklı kapsayıcı çalıştırma eğiliminde olacaksınız. Ancak bir sistemde MLS1 etiketi ile çalışan bir kapsayıcı saldırıya uğramışsa o zaman bu kapsayıcı işleminin yalnızca kapsayıcıdaki içeriğe (SELinux açısından) erişimi olmaz aynı zamanda dosya sistemi ve de ağ üzerinden aynı MLS etiketi ile çalışan diğer tüm kapsayıcılara erişimi olur. Bir MCS sisteminde, MCS1 olarak çalışan saldırıya uğramış kapsayıcıya, ağ üzeri haricinde sistemdeki diğer kapsayıcılara saldırmasına izin verilmez.

Kapsayıcıların yararlandığımız diğer çekirdek özellikleri özetle şu şekilde:

Ağ Ad Alanları ve VPN'ler

Çekirdek, hangi kapsayıcıların ağ üzerindeki diğer kapsayıcılarla konuşabileceğini denetler

Pid Ad Alanları

Çekirdek, kapsayıcı içindeki işlemi yalnızca kapsayıcıdaki diğer işlemlere gösterir. Bir kapsayıcıdaki işlemleri diğer kapsayıcılardaki işlemler göremez.

Ad alanlarını oluşturma

Her kapsayıcı yalnızca ihtiyaç duyduğu içeriği duyarlılık düzeyinde görür. Ana bilgisayar verileri ve diğer kapsayıcı verileri, kapsayıcı içindeki işlemlerden gizlenir.

Kök gerektiren işlemleri bile kilitlemek için Kullanıcı Ad Alanı

Kök gücünü sınırlamak için düşürülmüş yetenekler

Kabın içindeki işlemler için kullanılabilir sistem çağrılarını sınırlamak için Seccomp sistem çağrı filtrelemesi.

SELinux, dosya sistemine ve işletim sisteminin diğer etiketli parçalarına erişimi kontrol etmek için kullanılır.

Serinin ikinci bölümünde, aynı sistemde farklı hassasiyet seviyelerine sahip kapsayıcılar kullanacaksanız, izolasyonu garanti etmek için MLS yerine MCS ayrımını kullanmanız gerektiğini öğrendik. Bir sonraki gönderimiz, kapsayıcılar aracılığıyla daha güvenli bir veri hattı oluşturmaya odaklı olacak.