SELinux deyince çoğu Linux yöneticisinin yüzü hafifçe gerilir. Haklılar da açıkçası. Teorisi güzel, pratikte ise yanlış bir context yüzünden servis ayağa kalkmıyor, log’lar doluyor taşıyor, sonra herkes birbirine bakıyor. Ama lafı gevelemeden söyleyeyim: doğru kurulduğunda SELinux, sistemin arka planda en sağlam bekçilerinden biri haline geliyor — sessiz çalışıyor, gürültü çıkarmıyor, saldırıyı tam kapıda kesiyor.
Şöyle söyleyeyim, Ben bu konuyla ilk kez 2019’da Ankara’daki bir kurum projesinde uğraşmıştım. Bir web servisi, dosyaları /tmp altına bırakıyor diye gece yarısı alarm düşmüştü (en azından benim deneyimim böyle). Dosya izinleri tamam görünüyordu ama SELinux “dur bakalım” dedi ve işi kesti. O gece anladım ki klasik chmod/chown mantığı tek başına yetmiyor; yetmediği gibi insan sizi güvende hissettirip aslında açık bırakabiliyor. İşte tam da bu noktada Puppet gibi araçlarla deklaratif yönetim devreye giriyor — insan hatasını törpülüyor, sistemi her seferinde aynı yerde tutuyor.
SELinux neden hâlâ önemli?
Bak şimdi, SELinux’u sadece “ekstra güvenlik katmanı” diye anlatmak biraz eksik kalır. Asıl mesele şu: bu sistem erişimi yalnızca kullanıcıya ya da gruba göre değil, bağlama göre de denetliyor. Yani bir süreç root olsa bile, yanlış (belki yanılıyorum ama) etikete sahip bir dosyaya dokunamıyorsa iş orada bitiyor. Kağıt üstünde süper; pratikte bazen can sıkıcı, ama güvenlik tarafında baya iş görüyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Eh, Rocky Linux 9, AlmaLinux 9, RHEL 9 ve Fedora gibi dağıtımlarda SELinux’un varsayılan açık gelmesi boşuna değil. Kurumsal dünyada artık “açalım mı açmayalım mı?” sorusu pek sorulmuyor; soru daha çok “bunu düzgün nasıl yönetiriz?” oluyor. Çünkü elle yönetilen SELinux kısa sürede dağılabiliyor — bir sunucuda permissive unutuluyor, diğerinde restorecon atlanıyor, üçüncüsünde de politika kayıyor. Fark edilene kadar da iş işten geçiyor.
İlginç olan şu ki, Geçen yıl İzmir’de bir arkadaşımın küçük SaaS ortamında buna benzer bir şey yaşandı. Beş sunucu vardı, hepsi aynı imajdan çıkmıştı ama iki tanesinde web uygulaması dosya yükleyemiyordu. Sorun kodda değildi; biri sonradan elle düzeltilmişti, diğeri hiç restore edilmemişti. Hani şu “aynı makine gibi görünüyor ama değil” vakası… SELinux’ta drift dediğimiz şey tam da bu.
Evet, doğru duydunuz.
MAC modeli ne kazandırıyor?
Klasik Unix izinleri “kim neyi okuyabilir/yazabilir?” sorusuna cevap veriyor. MAC yani mandatory access control ise “bu süreç gerçekten bunu yapmalı mı?” diye soruyor. Fark küçük görünse de etkisi büyük; çünkü bir saldırgan web servisini kandırıp zararlı dosya bıraktırsa bile context yanlışsa iş orada kilitlenebiliyor.
SELinux’un en sevdiğim tarafı şu: hata yaptığınızda bile bazen sizi kurtarıyor. Tabii doğru ayarlanmışsa… aksi halde sadece log yığını bırakıyor.
Elle yönetmek niye yorucu?
Neyse uzatmayalım; manuel SELinux yönetimi birkaç sunucuda idare eder gibi görünür ama ölçek büyüyünce gerçekten bela oluyor. En tipik üç sorun var: setenforce ile modun yanlış kalması, yeni kopyalanan dosyalara uygun context verilmemesi. Yeniden kurulumlarda ayarların uçup gitmesi.
Bunu ben 2023’te Bursa’daki bir üretim ortamında birebir yaşadım — ya da yaşananı birebir gördüm desem daha doğru. Konfigürasyon yönetimi vardı ama SELinux kısmı “sonra bakarız” diye ötelenmişti. Sonra ne oldu? Apache açılıyor ama özel dizindeki içerikleri göremiyordu. Dışarıdan bakan biri için servis çalışıyor gibi, içeride ise sayfa boş dönüyor ya da 403 veriyor. Klasik hayal kırıklığı.
Evet, doğru duydunuz.
| Sorun | Elle Yönetimde Etki | Puppet ile Ne Olur? |
|---|---|---|
/etc/sysconfig/selinux |
Sürümler arasında farklılaşır | Deklaratif şekilde sabitlenir |
restorecon |
Sık unutulur | Kaynakla birlikte otomasyona alınır |
| Enforcing/Permissive modu | Elde değiştirilir | Tutarlı biçimde uygulanır |
| Kontekst sapması (drift) | Zamanla büyür | Puppet run ile geri çekilir |
confdroid_selinux ne yapıyor?
Bakın, İşin aslı şu: confdroid_selinux, Rocky 9 tabanlı sistemlerde SELinux yönetimini Puppet üzerinden toparlayan deklaratif bir modül fikrinden yola çıkıyor. Yani “şu an ne durumda?” yerine “hangi durumda olmalı?” sorusuna odaklanıyor — valla güzel iş çıkarmışlar —. Bu yaklaşımı seviyorum çünkü güvenlikte belirsizlik istemezsiniz — ya var ya yok, ya doğru ya yanlış. Daha fazla bilgi için PostgreSQL’de Bağlantı Patlaması: PgBouncer ve Supavisor yazımıza bakabilirsiniz.
Dürüst olmak gerekirse, Modülün yaptığı şeyler kulağa sade geliyor ama etkisi fena değil: gerekli araçları kuruyor, ana yapılandırma dosyasını yönetiyor, global modu belirliyor ve diğer Confdroid modüllerinin ürettiği dosya/dizinler için doğru context düzenini korumaya yardımcı oluyor. Bu ne anlama geliyor? Bir de önemli bir nokta var, şunu atlamamak lazım: bu iş tek başına değil, ekip işi gibi düşünülmeli — Apache varsa Apache’nin context’i, Gitea varsa onunki, hepsi aynı orkestrada çalmalı, yoksa bir yerden patlıyor (ilk duyduğumda inanamadım)
Neden özellikle Puppet ile iyi gidiyor?
Şöyle söyleyeyim, Puppet’ın gücü tekrarlanabilirlikten geliyor. Bir sunucuya elle girip düzeltme yapmak kolaydır, tamam. Ama onuncu sunucuda iş karışmaya başlar; ellinci sunucuda ise felaket resmen kapıya dayanır. confdroid_selinux burada merkezi kontrol sağlıyor ve farklı makinelerdeki ufak sürprizleri törpülüyor.
Daha açık söyleyeyim, i̇lginç olan şu ki, Küçük bir startup için bu yaklaşım hızlı kazanım demek olabilir: tek bir repo içinde güvenlik politikalarını toparlarsınız, yeni makine ayağa kalkınca aynı standart gelir, kimse “acaba bu sunucuya restorecon çalıştırdık mı?” diye sorgulamaz. Enterprise tarafta ise olay daha ciddi — denetim izi lazım, audit log lazım, değişiklik geçmişi gerekir… Puppet burada şaşırdım açıkçası, bayağı rahatlatıyor.
Kullanım senaryosu: startup mı kurumsal yapı mı?
Küçük ekiplerde iş nasıl yürür?
Küçük ekiplerde genelde iki kişi hem DevOps hem sistem hem güvenlik işini sırtlıyor — evet, biraz fazla yük var orada, abartmıyorum. Böyle yerlerde confdroid_selinux gibi modüller zaman kazandırır çünkü tekrar eden işleri elimden alır. En çok da test ortamından canlıya geçerken aynı policy’nin korunması önemli; yoksa her deploy sonrası küçük yangın çıkar, o yangını söndürürken de başka şeyler yana kalır.
Size bir şey söyleyeyim, Bana kalırsa küçük ekiplerin en büyük avantajı esneklik, en büyük dezavantajı ise kayıt tutmanın gevşek kalmasıdır. Modül tabanlı yaklaşım bu gevşekliği biraz toparlıyor ama bayağı sihirli değnek değil (en azından benim deneyimim böyle). Yine de politika tasarımını sizin düşünmeniz gerekiyor — bunu atlatmanın kestirme yolu yok maalesef (ki bu çoğu kişinin gözünden kaçıyor) Bu konuyla ilgili İmza Kaçınca Ne Olur?: Kendini Değiştiren Zararlı Yazılım yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili 3 Katmanlı Design Token Neden Önemli? yazımıza da göz atmanızı tavsiye ederim.
Büyük yapılarda fark nerede hissediliyor?
Büyük yapılarda mesele hızdan çok tutarlılık oluyor. Onlarca uygulama var, farklı ekipler var, farklı host grupları var… SELinux’u elle bu kadar yerde taşımak neredeyse imkânsız hale geliyor. Puppet sayesinde rol bazlı dağıtım yapılınca herkes kendi alanını görüyor ama temel güvenlik standardı bozulmuyor.
Açık söyleyeyim: enterprise ortamda asıl beklenti “çalışsın” değil, “her yerde aynı çalışsın.” İşte confdroid_selinux’un kıymeti tam burada ortaya çıkıyor — global modu tek yerden yönetirken diğer modüllerin context davranışını da hizaya sokuyor.
- Daha az manuel müdahale
- Daha tutarlı audit çıktısı
- Daha az konfigürasyon sapması
- Daha öngörülebilir servis davranışı — ciddi fark yaratıyor
Saldırıları nasıl durduruyor?
Bazen güvenliği soyut anlatıyoruz da konu gözde canlanmıyor. Somutlaştırayım: zararlı bir script web dizinine bırakıldı diyelim. Dosya izni uygun olabilir, hatta executable bile yapılmış olabilir. Ama context yanlışsa SELinux kapıyı kapatıyor. Bu kadar net.
Editör masasında bu haberi hazırlarken aklıma hemen eski bir test ortamı geldi. 2024 baharında İstanbul’da kurduğum küçük lab’da bilerek hatalı label vermiştim. Dosya oradaydı ama servis göremiyordu. İşte tam o anda anlıyorsunuz — geleneksel izinler başka bir dil konuşuyor, SELinux bambaşka bir şey söylüyor (şaşırtıcı ama gerçek). Siz hiç denediniz mi? Biri anahtar deliği, diğeri kapının kendisi gibi düşünün.
# Basit fikir akışı
1) Dosya oluşturulur
2) Puppet doğru context'i uygular
3) Sistem enforcing modda kalır
4) Yanlış erişim denemesi audit'e düşer
5) Servis çalışmaya devam eder
6) Saldırı sessizce engellenir
Nerede güçlü, nerede ham kalıyor?
Güçlü yani belli: otomasyon, tutarlılık, azalan insan hatası… Bunlar gerçek. Ama dürüst olayım, biraz ham tarafı da var. SELinux politikaları ilk kurulumda uğraştırabiliyor; özellikle — itiraz edebilirsiniz tabi — custom uygulamalarda doğru label setini bulmak ciddi zaman alabiliyor. Yani ürün iyi, ama sihir değil. Hmm, nasıl desem — iskelet sağlam ama üstünü giydirmek hâlâ size kalıyor.
Puppet modülü size iskeleti veriyor; ince ayar hâlâ sizde. Bu kötü mü? Bence değil, hatta bir düşüneyim… iyi tarafı bu — görmediğiniz karmaşıklığı gizlemek yerine onu düzenli hale getiriyor. Bir kere oturdu mu rahat ediyorsunuz, ama ilk günlerde birkaç kez kafayı duvara vurmanız gayet normal, benden söylemesi.
Sıkça Sorulan Sorular
SELinux permissive ile enforcing arasındaki fark nedir?Permissive modda SELinux ihlalleri engellemez, sadece log’a yazar. Enforcing modda ise kural ihlali doğrudan bloklanır. Test ortamında permissive işe yarayabilir ama canlı sistemde genelde enforcing tercih edilir.
Puppet ile SELinux yönetmek neden avantajlı?Puppet tekrarlanabilir. Merkezi yönetim sağlar.
Elle yapılan değişiklikleri azaltır ve drift riskini düşürür.
Mesela çok sunuculu ortamlarda ciddi rahatlık verir.
Kendi uygulamam için özel SELinux policy yazmam gerekir mi?Bazen evet.
Standart context yeterli olmazsa özel policy ya da ek label tanımı gerekebilir.
Ama önce mevcut kurallarla çözmeye çalışmak daha mantıklı olur (evet, doğru duydunuz)
Sadece Rocky Linux üzerinde mi kullanılabilir?Hayır, mantık diğer RHEL tabanlı dağıtımlara da uyarlanabilir. Yine de test edilen platformu esas almak en doğrusu olur. Üretime geçmeden önce küçük bir lab kurulumu şarttır.
Dikkat etmeniz gereken pratik noktalar
💡 Bilgi: Eğer sisteminizde sürekli “permission denied” görüyorsanız hemen chmod’a saldırmayın; önce /var/log/audit/audit.log, sonra context kontrolü yapın.
Çoğu zaman sorun izin değil etikettir.
Elle yapılan değişiklikleri azaltır ve drift riskini düşürür.
Mesela çok sunuculu ortamlarda ciddi rahatlık verir.
Kendi uygulamam için özel SELinux policy yazmam gerekir mi?Bazen evet.
Standart context yeterli olmazsa özel policy ya da ek label tanımı gerekebilir.
Ama önce mevcut kurallarla çözmeye çalışmak daha mantıklı olur (evet, doğru duydunuz)
Sadece Rocky Linux üzerinde mi kullanılabilir?Hayır, mantık diğer RHEL tabanlı dağıtımlara da uyarlanabilir. Yine de test edilen platformu esas almak en doğrusu olur. Üretime geçmeden önce küçük bir lab kurulumu şarttır.
Dikkat etmeniz gereken pratik noktalar
💡 Bilgi: Eğer sisteminizde sürekli “permission denied” görüyorsanız hemen chmod’a saldırmayın; önce /var/log/audit/audit.log, sonra context kontrolü yapın.
Çoğu zaman sorun izin değil etikettir.
Dikkat etmeniz gereken pratik noktalar
/var/log/audit/audit.log, sonra context kontrolü yapın.Çoğu zaman sorun izin değil etikettir.
Neyse uzatmayayım; benim sahada gördüğüm en yaygın hata şu oluyor:
insanlar SELinux’u kapatmayı çözüm sanıyor. Kısa vadede nefes aldırır,
uzun vadede güvenliği delersiniz. Bunun yerine otomasyonu düzgün kurup log okumayı öğrenmek daha temiz yol.
E tabi biraz disiplin istiyor:
hangi dizin hangi role ait,
hangi servis hangi label ile çalışacak,
deploy sırasında hangi adımlar koşacak…
bunları yazmadan ilerlerseniz Puppet bile sizi kurtaramaz.
Ama bunları netleştirince hayat bayağı kolaylaşıyor.
Bir de şu var:
uygulama geliştiricileriyle sistem yöneticileri konuşmazsa problem büyüyor;
bir taraf kodu atar,
öbür taraf policy’ye bakar,
ortada kalan yine siz olursunuz!Google Meet Slack ve RAG ile Toplantı Hafızası Kurmak:
Node.js Lokalde Çalışıp VPS’de Çökünce Ne Yapmalı?:
Playwright ile Uçtan Uca Test Tam Kapsamlı Rehber:
Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
