kullanici1
Mart 17, 2026

Linux sistemlerde bir saldırının “kritik” seviyeye yükselmesi çoğu zaman tek bir zafiyetle değil, küçük zayıflıkların birleşmesiyle olur. Saldırgan düşük yetkili bir kullanıcıyla sisteme eriştikten sonra, yerel yetki yükseltme (Local Privilege Escalation – LPE) ile root veya root’a eşdeğer ayrıcalıklara ulaşmayı hedefler. Bu eşik aşıldığında dosya sistemi üzerinde tam kontrol, güvenlik kontrollerini devre dışı bırakma, kimlik bilgisi çıkarma ve ağ içinde ilerleme gibi adımlar kolaylaşır. Bu yüzden Linux LPE, hem sızma testlerinde hem de savunma tarafında yüksek öncelikli bir konudur.
Linux tarafında LPE’nin sık tekrar eden üç kaynağı vardır: sudo yapılandırmaları, SUID/SGID bitine sahip ikililer ve cron/zamanlanmış görevler. Bu başlıkların ortak noktası şudur: “bir şey” normal kullanıcıdan daha ayrıcalıklı çalışıyordur ve bu ayrıcalık ya gereğinden geniştir ya da yanlış bir şekilde devredilmiştir. Bu makale, bu üç alanı saldırı adımlarına girmeden, risk mantığı ve savunma önlemleri üzerinden ele alır.
Yerel yetki yükseltme, bir kullanıcının aynı makinede sahip olmadığı ayrıcalıklara ulaşmasıdır. Linux’ta ayrıcalıklar temelde kullanıcı/ grup kimlikleri (UID/GID), dosya izinleri (rwx), özel bitler (SUID/SGID/sticky), yetenekler (capabilities) ve zorunlu erişim kontrolü (SELinux/AppArmor) gibi mekanizmalarla yönetilir. Root kullanıcısı (UID 0) en geniş yetkilere sahiptir; bu yüzden LPE çoğunlukla root erişimini hedefler.
LPE riskini anlamak için iki soru kritik önemdedir: (1) Hangi işlemler “daha yüksek yetkiyle” çalışıyor? (2) Bu işlemlerin girdileri, dosyaları veya yürüttüğü komutlar normal kullanıcı tarafından etkilenebiliyor mu? Bir kullanıcı, root’un çalıştırdığı bir dosyayı değiştirebiliyorsa veya root’un çalıştırdığı komutun parametrelerini manipüle edebiliyorsa, LPE ihtimali yükselir. Bu nedenle LPE, yalnızca kernel CVE’lerinden değil, yanlış izin ve yanlış operasyonel pratiklerden de doğar.
Sudo, belirli kullanıcıların belirli komutları geçici olarak daha yüksek yetkiyle çalıştırmasına imkân veren bir mekanizmadır. Kurumlar açısından sudo, root parolasını paylaşmadan yönetim yapmayı sağladığı için değerlidir. Ancak sudoers politikası geniş tutulduğunda veya dikkatli yönetilmediğinde, ‘kısıtlı’ gibi görünen izinler pratikte root yetkisine yakın sonuçlar doğurabilir.
Sudo tarafında savunma açısından odak noktaları şunlardır: Komut kapsamının dar olması (allowlist), parametrelerin kontrol edilebilirliği, NOPASSWD gibi parolasız çalıştırma istisnalarının sınırlanması, audit kayıtlarının tutulması ve gereksiz kullanıcıların sudo grubundan çıkarılması. Ayrıca “sudo üzerinden çağrılan programın” kendi içinde kabuk açma, dosya okuma-yazma veya sistem çağrısı yapma yetenekleri varsa, komut seçiminin güvenlik etkisi büyür. Bu yüzden sudo, yalnızca ‘hangi komut’ değil, ‘o komutun güvenlik davranışı’ düşünülerek tasarlanmalıdır.
SUID (Set User ID) ve SGID (Set Group ID), bir ikili dosyanın çalıştırıldığında dosya sahibinin veya grubunun kimliğiyle işlem yapmasını sağlar. Bu özellik, örneğin sistemde bazı yönetim işlerini normal kullanıcıya sınırlı şekilde açmak için kullanılır. Fakat SUID/SGID, yanlış uygulandığında veya riskli programlara verildiğinde LPE için güçlü bir zemin oluşturur; çünkü programın yaptığı her şey daha yüksek yetkiyle gerçekleşebilir.
SUID/SGID riskleri genellikle şu durumlarda artar: eski/patch’siz ikililer, gereksiz SUID verilmiş araçlar, geniş dosya sistemi yazma izinleriyle birleşen senaryolar, PATH/ENV gibi çevresel etkilerden etkilenen programlar ve güvenli programlama pratikleri zayıf uygulamalar. Savunma tarafında hedef; SUID/SGID kullanımını minimuma indirmek, düzenli envanter çıkarmak, değişiklikleri izlemek ve mümkün olduğunda daha modern mekanizmalara (capabilities, policy-based erişim) geçmektir.
Cron, belirli aralıklarla komut çalıştırmayı sağlayan zamanlayıcı sistemidir ve sunucularda yedekleme, log döndürme, bakım, veri senkronizasyonu gibi görevler için yaygın biçimde kullanılır. Cron görevleri çoğunlukla root veya servis hesaplarıyla çalıştığı için, görev tanımlarındaki veya çağrılan dosyalardaki küçük bir hata LPE’ye dönüşebilir.
Cron kaynaklı riskler savunma perspektifinden genelde şu başlıklarda toplanır: cron tarafından çalıştırılan scriptlerin veya binarilerin normal kullanıcı tarafından yazılabilir olması, dosya/klasör izinlerinin gevşekliği, görevlerde göreli yol (relative path) veya beklenmeyen environment kullanımının bulunması, logların/hata çıktılarının hassas bilgi sızdırması ve job’ların beklenmedik şekilde tetiklenmesi. Sağlam bir cron tasarımı, ‘root çalıştırıyor’ gerçeğini kabul edip; dosya sahipliği, izinler, path sabitleme ve kod bütünlüğü kontrollerini sıkı tutmalıdır.
Linux LPE’yi erken fark etmek için tek bir log kaynağı yetmez; sistem ve uygulama telemetry’si birlikte ele alınmalıdır. Savunma ekiplerinin izleyebileceği pratik sinyaller şunlardır:
Bu sinyallerin anlam kazanması için merkezi log toplama (SIEM), dosya bütünlüğü izleme (FIM) ve uç nokta telemetrisi (EDR/eBPF tabanlı izleme) gibi bileşenler faydalıdır. Amaç, tekil bir olayı yakalamaktan çok, “normalin dışına çıkan” trendi erken görmektir.
Sudo, SUID ve cron kaynaklı LPE riskini düşürmek için en etkili yaklaşım; ayrıcalığı daraltmak, dosya izinlerini sıkılaştırmak ve değişiklikleri görünür kılmaktır: