Servisleri root yerine kullanıcı ile çalıştırma

Neden her şeyi root olarak çalıştırmamalı?

Root, makinede her şeyi yapabilir: her dosyayı okuyabilir, tüm ayarları değiştirebilir, tüm sistemi silebilir. Bir servisi root olarak çalıştırdığınızda, tüm bu gücü o servise devretmiş olursunuz. Eğer serviste bir saldırganın istismar edebileceği bir hata varsa, saldırgan sadece servisi ele geçirmekle kalmaz, root yetkisini de ele geçirir; root ise tüm sunucu demektir. Ayrıcalıksız bir kullanıcı olarak çalıştırmak, hasarı sınırlar. Sınırlı bir hesap olarak çalışan bir servisteki hata, saldırgana yalnızca o hesabın erişebildiği şeyleri verir; bu da neredeyse hiçbir şey olmalıdır.

Bu, en az ayrıcalık ilkesidir: sistemin her parçasına yalnızca işini yapması için gereken erişimi verin ve daha fazlasını vermeyin. Bu, bir ihlalin etki alanını sınırlamak için en etkili alışkanlıktır ve modern bir sunucuda bunu uygulamak neredeyse hiçbir maliyet gerektirmez.

Her servis için özel bir hesap

Klasik yaklaşım, her servis için ayrı bir sistem kullanıcısı oluşturmaktır; bu kullanıcı yalnızca o servisin dosyalarına sahip olmalı ve oturum açamamalıdır. Bir web uygulaması için sistem hesabı şu şekilde görünebilir:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

Her bayrak önemlidir. --system onu bir insan girişi değil, bir servis hesabı yapar. --no-create-home ihtiyaç duyulmayan bir ana dizini (home directory) atlar. --shell /usr/sbin/nologin ise saldırgan hesabı bir şekilde ele geçirse bile, onunla bir shell açamayacağı anlamına gelir. Hesap yalnızca bir sürece ve onun dosyalarına sahip olmak için mevcuttur.

Ardından, o kullanıcıya yalnızca ihtiyacı olan dosyaları verin ve daha fazlasını vermeyin:

sudo chown -R appsvc:appsvc /opt/myapp

Artık servis kendi dizinini okur ve yazar ve disk üzerinde başka hiçbir yerde işi yoktur. Eğer bir şekilde istismar edilirse, saldırganın değiştirebileceği dosyalar /opt/myapp ile sınırlıdır; hesap hala dünya tarafından okunabilir olan her şeyi okuyabilir, ancak sistemin geri kalanını değiştiremez.

Servisi o kullanıcı olarak systemd ile çalıştırın

Hesap oluşturulduktan sonra, systemd'ye servisi bu hesapla çalıştırmasını söyleyin. Unit dosyasında, tek bir satır bunu yapar:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc, sürecin root yerine o hesabın sınırlı ayrıcalıklarıyla başlaması anlamına gelir. Bu, systemd altında bir uygulamayı çalıştırmanın normal ve yaygın yoludur ve unit yazdığınız her servis için bunu yapmaya değer.

Veya DynamicUser ile hesabı tamamen atlayın

systemd bir adım daha ileri giderek sizin için geçici bir kullanıcı oluşturabilir; bu kullanıcı yalnızca servis çalıştığı sürece mevcuttur. DynamicUser=yes ayarını yapın ve bir hesabı hiç yönetmeyin:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

Başlangıçta systemd kullanılmayan bir kullanıcı kimliği (UID) atar; durdurulduğunda ise bunu serbest bırakır. Servis ayrıca özel bir /tmp (dosya sisteminin çoğunun salt okunur görünümü) ve /var/lib/myapp altında StateDirectory= tarafından kurulan ve kendisine verilen yazılabilir bir durum dizinine (state directory) sahip olur. Yalnızca kendi durum dizinine ihtiyaç duyan, kendi içine kapalı bir servis için DynamicUser=yes, güçlü izolasyon sağlamanın en az çaba gerektiren yoludur; çünkü saldırganın hedef alabileceği uzun süreli bir hesap yoktur.

Unit dosyalarını elle yazmak zahmetlidir ve asıl değer, sıkılaştırma direktiflerini doğru ayarlamaktır. systemd servis ve timer kılavuzundaki generator, unit dosyasının ilk seferde doğru olması için bu seçenekleri sizin yerinize doldurabilir.

Bu durumun geri kalanıyla ilişkisi

En az ayrıcalık bir katmandır ve diğerlerinin yerini almak yerine onlarla birlikte çalışır. Bir varsayılan reddetme (default-deny) firewall servise neyin ulaşabileceğini kontrol eder; servisi ayrıcalıksız bir kullanıcı olarak çalıştırmak, servis ihlal edilirse ne yapabileceğini kontrol eder; ve sıkılaştırılmış SSH saldırganların en başta makineye girmesini engeller. Bunların hiçbiri tek başına yeterli değildir; birlikte kullanıldıklarında, bir servisteki hatanın tüm sunucunun ele geçirilmesine neden olmayacağı anlamına gelirler.

Devam etmeden önce, tüm makine için bir sıkılaştırma kontrol listesini gözden geçirin ve üzerinde çalışmak üzere kişiselleştirilmiş bir kopya oluşturun:

FAQ

Neden bir servisi root olarak çalıştırmamalıyım?

Çünkü root makinede her şeyi yapabilir; root olarak çalışan ve istismar edilen bir servis, saldırgana sadece servisi değil, tüm sunucuyu teslim eder. Servisi sınırlı, ayrıcalıksız bir hesap olarak çalıştırmak, hasarı o hesabın erişebildiği şeylerle sınırlar. Root'u yönetime ayırın ve her uzun süreli servisi kısıtlı bir kullanıcı olarak çalıştırın.

Giriş yapamayan bir kullanıcıyı nasıl oluştururum?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME komutunu çalıştırın. nologin shell, kimlik bilgileri çalınsa bile hesabın etkileşimli bir oturum açamayacağı anlamına gelir, --system onu bir servis hesabı olarak işaretler ve --no-create-home ihtiyaç duyulmayan bir ana dizini atlar. chown ile ona yalnızca kendi dosyalarının sahipliğini verin.

systemd DynamicUser nedir?

DynamicUser=yes, systemd'ye servis için yalnızca o çalıştığı sürece var olan geçici bir kullanıcı oluşturmasını söyler, böylece hiçbir zaman uzun süreli bir hesabı yönetmezsiniz. Ayrıca servise özel bir /tmp (çoğunlukla salt okunur bir dosya sistemi görünümü) ve yönetilen bir durum dizini sağlar. Kendi içine kapalı bir servisi geçici, düşük ayrıcalıklı bir kimlik altında çalıştırmanın en az çaba gerektiren yolu budur.

Ayrıcalıksız bir kullanıcı olarak çalıştırmak bir firewall'un yerini tutar mı?

Hayır. Farklı şeyleri korurlar. Ayrıcalıksız bir kullanıcı olarak çalıştırmak, bir servis ihlal edilirse ne yapabileceğini sınırlar; bir firewall ise servise neyin ulaşabileceğini sınırlar. Her katmanın diğerlerinin kapsayamadığını kapsaması için her ikisini de sıkılaştırılmış SSH ile birlikte kullanın.

Servis kullanıcısı hangi dosyalara sahip olmalıdır?

Yalnızca servisin gerçekten ihtiyaç duyduğu dosyalara ve daha fazlasına değil. Hesaba kendi çalışma dizininin ve verilerinin sahipliğini verin ve geri kalan her şeyin root tarafından sahiplenilmesine izin verin. İyi bir yöntem, uygulama dizini için sudo chown -R svc-app:svc-app /opt/svc-app kullanmaktır; /etc altındaki konfigürasyonlar ise root sahipliğinde kalmalı ve yalnızca servis tarafından okunabilmelidir. Amaç, süreç bir şekilde ele geçirilirse, değiştirebileceği dosyaların sistemin geri kalanı değil, yalnızca kendi verileri ile sınırlı olmasıdır.