SELinux Policy Yönetimi ve Sorun Giderme: Derinlemesine Bir Bakış

 · 

SELinux Policy Yönetimi ve Sorun Giderme: Derinlemesine Bir Bakış

SELinux Policy Yönetimi ve Sorun Giderme: Derinlemesine Bir Bakış

SELinux (Security-Enhanced Linux), Linux çekirdeği düzeyinde zorunlu erişim kontrolü (MAC) uygulayan bir güvenlik mekanizmasıdır. Varsayılan olarak birçok Linux dağıtımında etkin olan SELinux, sistem kaynaklarına erişimi sıkı bir şekilde yöneterek yetkisiz erişimi engellemeyi hedefler. Ancak, doğru yapılandırılmadığında veya uygulamaların beklentilerine uymadığında, sistem davranışlarında beklenmedik sorunlara yol açabilir. Bu makalede, SELinux policy'lerini yönetme ve karşılaşılan sorunları giderme konusunda derinlemesine bilgi sunulacaktır.

SELinux Temelleri ve Policy Modelleri

SELinux, Type Enforcement (TE), Role-Based Access Control (RBAC) ve Multi-Level Security (MLS) gibi farklı prensipler üzerine kuruludur. En yaygın kullanılan model TE'dir. TE modelinde, her dosya, dizin, işlem ve portun bir türü (type) bulunur. Politika kuralları, hangi türdeki bir işlemin hangi türdeki bir kaynağa hangi eylemle (okuma, yazma, yürütme vb.) erişebileceğini tanımlar.

SELinux policy'leri genellikle iki ana modda çalışır:

  • Enforcing (Zorlayıcı): Politika kuralları aktif olarak uygulanır ve ihlal durumunda erişim engellenir.
  • Permissive (İzin Verici): Politika kuralları zorlanmaz, ancak ihlaller denetim günlüklerine (audit logs) kaydedilir. Bu mod, policy'leri test etmek ve sorunları anlamak için idealdir.

Yaygın SELinux Sorunları ve Tanılama Araçları

SELinux kaynaklı sorunlar genellikle AVC (Access Vector Cache) denied hata mesajlarıyla kendini gösterir. Bu hatalar, bir işlemin, izin verilmeyen bir kaynağa erişmeye çalıştığını belirtir. Bu tür durumları teşhis etmek için kullanılan temel araçlar şunlardır:

1. Audit Log (Denetim Günlüğü) İncelemesi

SELinux'un tüm erişim denetimi kararları ve reddedilmeleri /var/log/audit/audit.log dosyasında kaydedilir. Bu logları analiz etmek, sorunun kaynağını belirlemek için kritik öneme sahiptir.

sudo ausearch -m AVC -ts recent

Yukarıdaki komut, son zamanlarda meydana gelen tüm AVC denied mesajlarını listeler. Çıktıda, hangi sürecin (PID), hangi kaynağa (file, dir, port vb.) ve hangi izinlerle erişmeye çalıştığı detaylı olarak belirtilir.

2. setroubleshoot ve setroubleshoot-server

Bu araçlar, audit.log dosyasındaki AVC mesajlarını okuyarak daha anlaşılır hata raporları sunar ve olası çözüm önerileri (örneğin, eksik policy modülü veya yanlış etiketleme) sağlar.

sudo systemctl status setroubleshootd

Bu servis çalışır durumda olmalıdır. Hata durumunda, /var/log/audit/audit.log dosyasındaki ilgili satırları sealert komutu ile analiz edebilirsiniz:

sudo sealert -a /var/log/audit/audit.log

3. sestatus

Sistemin mevcut SELinux durumunu (etkin/devre dışı, enforcing/permissive modu) ve loaded policy'sini gösterir.

sudo sestatus

4. getenforce ve setenforce

getenforce mevcut çalışma modunu gösterir. setenforce 0 (Permissive) veya setenforce 1 (Enforcing) komutlarıyla çalışma modu geçici olarak değiştirilebilir. Kalıcı değişiklikler için /etc/selinux/config dosyası düzenlenmelidir.

5. chcon ve restorecon

Dosyaların veya dizinlerin SELinux etiketlerini (context) değiştirmek için kullanılır. chcon manuel etiketleme yaparken, restorecon dosya sisteminin varsayılan policy'ye göre etiketlerini düzeltir.

# Belirli bir dosyanın etiketini değiştirme
sudo chcon -t httpd_sys_content_t /var/www/html/custom_app

# Dizin yapısının etiketlerini varsayılana döndürme
sudo restorecon -Rv /var/www/html

SELinux Policy Yönetimi ve Oluşturma

SELinux policy'leri, /etc/selinux/policy/ dizininde bulunan policy derleyicisi (checkmodule, semodule_package) ve araçları (semanage, audit2allow) kullanılarak yönetilir.

1. audit2allow ile Policy Oluşturma

Bu araç, audit.log dosyalarındaki reddedilmeleri analiz ederek yeni policy kuralları veya modülleri oluşturmak için kullanılır. Genellikle, bir uygulama SELinux nedeniyle çalışmadığında, önce sistemi Permissive moda alıp, ardından uygulamayı çalıştırarak oluşan hataları audit2allow ile policy'ye dönüştürmek yaygın bir taktiktir.

# Önce audit log'dan ilgili AVC'leri filtrele
sudo ausearch -m AVC -ts recent | audit2allow -M my_custom_policy

# Oluşan modülü yükle
sudo semodule -i my_custom_policy.pp

audit2allow çıktısı bir .te (Type Enforcement) dosyası ve bir .pp (Policy Package) dosyası üretir. .pp dosyası doğrudan yüklenebilir.

2. semanage ile Yönetim

semanage, SELinux'un yönetim aracıdır. Portlar, dosya bağlamları, kullanıcı eşlemeleri gibi SELinux nesnelerini yönetmek için kullanılır.

# Yeni bir portun httpd tarafından dinlenmesine izin verme
sudo semanage port -a -t http_port_t -p tcp 8080

# Belirli bir dizin için varsayılan SELinux bağlamını ayarlama
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/my_app(/.*)?"

# Değişiklikleri uygulama
sudo restorecon -Rv /srv/my_app

3. semodule ile Modül Yönetimi

semodule komutu, özel SELinux policy modüllerini yüklemek, kaldırmak ve yönetmek için kullanılır. audit2allow tarafından oluşturulan .pp dosyaları bu komutla yüklenir.

# Mevcut özel modülleri listeleme
sudo semodule -l

# Özel bir modülü kaldırma
sudo semodule -r my_custom_policy

Gerçek Production Senaryoları

Senaryo 1: Özel Web Uygulaması İçin SELinux Engeli

Sorun: Bir production sunucusunda, Nginx web sunucusu ile özel olarak geliştirilmiş bir Python uygulamasının entegrasyonu sırasında, uygulama beklenmedik bir şekilde duruyor veya 500 Internal Server Error veriyordu. Nginx loglarında özel bir hata yoktu, ancak audit.log dosyasında sürekli olarak AVC denied mesajları görülüyordu. Mesajlar, Nginx'in (httpd_t) uygulamanın çalıştığı belirli bir dizindeki (örneğin, /opt/my_webapp/data) dosyalara yazma izni olmadığını gösteriyordu.

Çözüm:

  1. Sistemi Permissive moda aldık: sudo setenforce 0
  2. Uygulamayı tekrar başlattık ve hatanın devam edip etmediğini kontrol ettik. Hata devam ediyordu.
  3. audit.log dosyasını audit2allow ile analiz ettik: sudo ausearch -m AVC -ts recent | audit2allow -M nginx_webapp
  4. Oluşan nginx_webapp.te dosyasını inceledik. Bu dosya, httpd_t türünün my_webapp_data_t türündeki dosyalara write izni olması gerektiğini belirtiyordu.
  5. Bu kuralı içeren .pp dosyasını yükledik: sudo semodule -i nginx_webapp.pp
  6. Sistemi tekrar Enforcing moda aldık: sudo setenforce 1
  7. Uygulamanın sorunsuz çalıştığını ve loglarda yeni AVC hatası olmadığını doğruladık.
  8. Ayrıca, uygulamanın veri dizininin doğru SELinux etiketine sahip olduğundan emin olmak için restorecon kullandık (eğer manuel chcon yapıldıysa bu adım gerekebilir): sudo restorecon -Rv /opt/my_webapp/data

Senaryo 2: Veritabanı Bağlantı Sorunu

Sorun: Bir PostgreSQL veritabanı sunucusunda, belirli bir uygulamanın veritabanına bağlanmakta zorlandığı rapor edildi. Uygulama logları bağlantı zaman aşımı veya reddedildiğini belirtiyordu. audit.log'da, uygulamanın çalıştığı işlem türünün (örneğin, mysqld_t veya özel bir uygulama türü) PostgreSQL'in dinlediği port olan 5432'ye erişiminin engellendiğine dair AVC mesajları vardı.

Çözüm:

  1. semanage port -l | grep 5432 komutu ile 5432 portunun hangi SELinux türleri tarafından dinlenebildiğini kontrol ettik. Genellikle postgresql_port_t olarak etiketlenmiştir.
  2. Uygulamamızın hangi SELinux türüne sahip olduğunu bulduk (örneğin, psql_app_t).
  3. semanage port -a -t postgresql_port_t -p tcp 5432 komutu ile doğrudan bir izin eklemek yerine, uygulamanın türünün PostgreSQL portuna erişebilmesi için bir policy modülü oluşturmak daha güvenli bir yaklaşımdır.
  4. Bu durumda, audit2allow yine devreye girer. Uygulamanın çalıştırılması sırasında oluşan AVC denied mesajları analiz edilir ve psql_app_t türünün port 5432'ye bind ve connect izni verecek bir policy modülü oluşturulur.
  5. Oluşturulan modül yüklendikten sonra sorun çözülür.

Sonuç

SELinux, sunucu güvenliğini önemli ölçüde artıran güçlü bir araçtır. Ancak, yönetimi ve sorun gidermesi karmaşık olabilir. audit.log'u etkin bir şekilde kullanmak, audit2allow ve semanage gibi araçlarla policy'leri anlamak ve yönetmek, SELinux'un getirdiği güvenlik avantajlarından ödün vermeden sistemlerin sorunsuz çalışmasını sağlamanın anahtarıdır. Permissive mod, geliştirme ve sorun giderme süreçlerinde vazgeçilmez bir adımdır, ancak production ortamlarında enforcing modun kullanılması tavsiye edilir.

← Blog Listesine Dön