login ve su internals

Linux'ta kullanıcı izinlerinin nasıl çalıştığını anlamaya çalışıyorum. Çekirdek önyükleme yapar ve initkök olarak başlar , değil mi? Init daha sonra başlangıç ​​komut dosyalarını çalıştırır ve yine root olarak çalışır getty( agetty). Agetty sadece kullanıcı adını okur ve loginhala kök gibi çalışır , sanırım. Henüz ilginç bir şey yok. Peki giriş yapmak ne işe yarar? "Giriş yapmaya çalışıyor" ifadesinden daha iyi bir şey bulamadım. Girişte parolanın eşleştiğini (ve her zamanki kullanıcı olarak giriş yapmaya çalıştığımızı) varsayalım, kullanıcı kimliğini nasıl değiştirir? Bunun için sistem çağrısı olması gerektiğini düşündüm ama bulamadım (belki sadece körüm?)

Ayrıca, hakkında su. su'setuid' biti ayarlanmış olduğundan, çalıştırdığımızda her zaman kök olarak çalışır. Ancak normal kullanıcı olarak oturum açmasını söylediğimizde, tekrar kullanıcı kimliğini değiştirmesi gerekir. Aynı "büyünün" gerçekleştiğini suve loginne zaman kullanıcıyı değiştirmeleri gerektiğini doğru anladım mı? Eğer öyleyse, neden iki farklı programınız var? Giriş yaparken başka ciddi iş türleri de oluyor mu?

Giriş programlarının yaptıklarının birkaç bölümü vardır. Giriş programları, giriş yapmaya çalışan kullanıcıyla etkileşimleri bakımından farklılık gösterir. İşte birkaç örnek:

• login: bir metin terminalindeki girişi okur
• su: önceden oturum açmış kullanıcılar tarafından çağrılır, verilerin çoğunu komut satırı argümanlarından ve bir terminalden kimlik doğrulama verileri (şifre) alır
• gksu: suX'deki kimlik doğrulama verilerine benzer , ancak kimlik doğrulama verilerini okur
• rlogind: rlogin protokolü üzerinden TCP bağlantısı üzerinden giriş elde eder
• sshd: SSH protokolü üzerinden TCP bağlantısı üzerinden giriş elde eder
• X ekran yöneticileri (xdm, gdm, kdm,…): loginbir X ekranındaki girişe benzer , ancak okuma girişi

Bu programlar benzer şekilde çalışır.

1. İlk bölüm kimlik doğrulamasıdır : program kullanıcıdan bazı girdileri okur ve kullanıcının oturum açma yetkisine sahip olup olmadığına karar verir. Geleneksel yöntem bir kullanıcı adı ve parola okumak ve kullanıcının sistemin kullanıcı veritabanında ve kullanıcının yazdığı parola veritabanında bulunan paroladır. Ancak başka olasılıklar da var (bir defalık şifreler, biyometrik kimlik doğrulama, yetkilendirme transferi,…).

2. Kullanıcının oturum açmaya yetkili olduğu ve hangi hesapta oturum açtığı belirlendikten sonra, oturum açma programı kullanıcının yetkisini belirler, örneğin kullanıcının bu oturumda hangi gruplara ait olacağını.

3. Oturum açma programı hesap kısıtlamalarını da kontrol edebilir. Örneğin, bir oturum açma süresini veya maksimum sayıda oturum açmış kullanıcıyı zorlayabilir veya belirli kullanıcıları belirli bağlantılarda reddedebilir.

4. Son olarak oturum açma programı kullanıcının oturumunu ayarlar. Birkaç alt adım vardır:

   1. İşlem izinlerini yetkilendirmede kararlaştırılan değere ayarlayın: kullanıcı, gruplar, sınırlar,… Bu alt adımın basit bir örneğini burada görebilirsiniz (yalnızca kullanıcı ve grupları işler). Temel fikir, giriş programının bu noktada hala kök olarak çalıştığıdır, bu nedenle maksimum ayrıcalıklara sahiptir; önce kök kullanıcı olmak dışındaki tüm ayrıcalıkları kaldırır ve son olarak setuidbu son fakat en az ayrıcalıktan vazgeçmeye çağırır .
   2. Muhtemelen kullanıcının ana dizinini bağlayın, “postanız var” mesajı vb. Görüntüleyin.
   3. Bazı programları kullanıcı olarak, genellikle kullanıcının kabuğunu çağırır ( loginve için suveya sshdherhangi bir komut belirtilmemişse; bir X görüntüleme yöneticisi bir X oturum yöneticisi veya pencere yöneticisi çağırır).

Günümüzde çoğu unice , giriş hizmetlerini tek biçimli bir şekilde yönetmek için PAM (Takılabilir Kimlik Doğrulama Modülleri) kullanır. PAM işlevselliğini 4 bölüme ayırır : “auth” hem kimlik doğrulama (yukarıda 1) hem de yetkilendirmeyi (yukarıda 2) kapsar; “Hesap” ve “oturum” yukarıdaki 3 ve 4 gibidir; ayrıca girişler için değil, kimlik doğrulama jetonlarını (ör. şifreler) güncellemek için kullanılan “şifre” vardır.

Aradığınız sistem çağrıları gibi şeyler olarak adlandırılır setuidve seteuidtam olarak hangi kullanıcı kimliğini değiştirmeye çalıştığınıza bağlı olarak tam bir etek ailesi olmasına rağmen.

setgidBir sürecin çalıştığı grubu değiştirmek gibi paralel çağrılar da vardır .

logingerektiğinde kök ayrıcalıkları düşer. Kök ayrıcalıklarına ihtiyaç duyan birçok program başlangıçta kök olarak başlayacak, yapmaları gerekeni yapacak ve daha sonra normal bir kullanıcı hesabına düşecek, böylece bir programa erişmek için ikili dosyada hata kullanan bir kişi hakkında endişelenmeleri gerekmez. kök kabuğu. logindoğal olarak ayrıcalıkları daha uzun süre korur, ancak prensip aynıdır.

Aslında kök ayrıcalıklarını bırakmak oldukça önemsizdir. POSIX , sırasıyla kullanıcı ve grup kimliklerinizi değiştiren (kök olarak başlıyorsanız gerçek ve etkili) tanımlar setuid()ve setgid()işlevler. loginbunlara her ikisini de çağırır ve initgroups()sahip olabileceğiniz ek grupları setgidayarlamak için (çünkü yalnızca birincil grup kimliğinizi ayarlamak içindir)

Doğal olarak, işlemin UID / GID'sini değiştirmeyi gerçekten gerçekleştiren çekirdek. Linux çekirdek sistemi çağrılarının uygulamalarını nasıl bulabilirim? sistem çağrıları hakkında çok şey açıklar; çekirdek kaynağımda var:

#define __NR_setgid 144
__SYSCALL(__NR_setgid, sys_setgid)
#define __NR_setuid 146
__SYSCALL(__NR_setuid, sys_setuid)

144 ve 146, makinemdeki bu işlevler için sistem çağrı numaralarıdır

Ne yaptığını sugörmek için kaynağı kontrol etmedim , ancak exec()aynı yöntemi kullanarak bir kabuk oluşturmadan hemen önce kök ayrıcalıklarını bıraktığından şüpheleniyorum.