Süper kullanıcı hangi erişim haklarını ihlal edemez?

Fr. Br. George , derslerinden birinde ( Rusça), süper kullanıcının ihlal edemeyeceği bazı erişim haklarının olduğunu söyledi. Bu, süper kullanıcının bir şey yapmasını yasaklayabilen bir erişim hakkı vardır.

İnternette bu bilgiyi bulamadım ve ne olduklarını merak ediyorum. Bu muhtemelen sistemin çekirdek uygulaması ile ilgili bir şey, değil mi? Belki bazı sistem işlemlerini durduramaz? Ya da belki gerçek modda bir işlem yürütemez?

Bu soru SELinux ile ilgili değildir (George, sorudan hemen önce bunun hakkında konuşuyordu).

erişim kök reddetti :

rootdoğrudan ağ erişimi reddedilebilir. Bu, internete bağlı ana bilgisayarlarda yararlıdır, çünkü smithdaha sonra oturum açmanızı gerektirir sudo.

bazı şeyler kök yapamaz :

Bu bir ayrıcalık eksikliği için DEĞİLDİR. Kökün yapamayacağı bir şey göremiyorum, ancak bazı teknik sorunlar "yasak" olarak yaşanmış olabilir.

Kökündüm, neden sıradan bir kullanıcı yapabilirken bu dosyayı neden oluşturamıyorum / silemiyorum?

NFS / samba paylaşımındasınız ve belirli ( access=) bir izin vermediniz . Sıradan bir kullanıcı genel yasaya uymuyor. (aşağıdaki yerel vs uzak kök dizinine bakın)

Kökündüm, neden bu işlemi öldüremiyorum?

Bekleyen bir G / Ç var ve fiziksel sürücü / uzak LUN bağlantısı kesildi, işlem yalnızca yeniden başlatmayla öldürülebilir.

Kökündüm, archar’ın şifresini nasıl alabilirim?

Bir su - archemaröncekini bilmeden, tamam şifresini değiştirebilirsiniz veya şifresini değiştiremezsiniz, ancak şifreler tek yönlü bir karma kullanarak saklanır, çünkü bunu okuyamazsınız (bir anahtar günlüğünün kısaltması).

yerel ve uzak kök

• İstasyonunuzda / PC'nizde root olabilir ve bir şirket / kolej / üniversite / sağlayıcı NFS paylaşımını kullanabilirsiniz.
• Ardından, NFS'yi dışa aktaran bilgisayarda yalnızca kök olmayan bir giriş yapabilirsiniz.

şimdi

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

sadece NFS sunucusuna giriş yapın, çalıştırın ./bashve şirket / üniversite sunucusuna ihtiyacınız var.

Her zamanki gibi, bu yanlıştır - Süper kullanıcı sistemin sağladığı herhangi bir işlevsellik için ayrıcalıklara / izinlere sahiptir (1). Bu kuralın bozulduğu yer, SELinux'u karışıma attığınız zamandır. SELinux ile, kök işlemlerin bile belirli eylemlere izin vermeme haklarını kısıtlamak mümkündür. Bununla birlikte, izin verilmeyen belirli eylemler yerel makinenin SELinux yapılandırmasına büyük ölçüde bağımlıdır, bu nedenle SELinux ile bile, bu soru genel anlamda cevaplanamaz.

(1) - bir sistem belirli bir özellik sağlamazsa, örneğin gerçek zamanlı çekirdek işlevselliği yoksa, o zaman "kökün bu işlevselliğe erişimi yok" ifadesinin yanlış olduğunu düşünüyorum, çünkü bu ifade bir yanlış varsayım (yani, verilen özelliğin bu sistemdeki herhangi biri tarafından kullanılabileceği)

Bir yandan, hiçbir kullanıcının yapamayacağı şeyler var, örneğin:

• bağlayıcı dizinler (dosya sistemi sınırlamaları nedeniyle)
• önceden yazılmış bir CD-ROM'a yazma (çünkü fizik)

Ancak bunlar imtiyaz değil, çünkü onlara verilemiyor, kimseye mümkün değil.

Daha sonra, tüm sistem veya bunun açılıp kapatılabilecek kısımları için kısıtlamalar vardır.
Örneğin, OS X'te, yalnızca Apple tarafından imzalanmışsa kodun çalışmasına izin verme seçeneği vardır.

Bunun da gerçek bir ayrıcalık olduğunu düşünmüyorum, çünkü süper kullanıcı yapamazsa, hiçbir kullanıcıya sahip olamaz. Bunu yalnızca küresel olarak devre dışı bırakabilirsiniz.

Düzenleme:
Yürütülebilir bit olmadan bir dosya fikriniz de bu kategoriye girer, çünkü gerçekten kimse bunu yapamaz ve kimseye bu izin verilemez.
Ve başka bir kullanıcıya veya gruba bu dosyayı yürütme izni verirken, ancak kök veya bir kullanıcı grubu kökü bulunmadığında bile, kök bu dosyayı çalıştırabilir (OS X 10.10, 10.11 ve Ubuntu 15.04 sunucusunda test edilmiştir).

Bu durumların dışında, kökün yapamayacağı hiçbir şey yok.
Bununla birlikte, çekirdek modu adı verilen bir şey vardır (kullanıcı modunun aksine).

Bildiğim kadarıyla, aklı başında bir sistemde sadece çekirdek, çekirdek uzantıları ve sürücüler çekirdek modunda çalışır ve diğer her şey (root olarak giriş yaptığınız kabuk dahil) kullanıcı modunda çalışır.
Bu nedenle “kök olmanın yetmediğini” iddia edebilirsiniz. Bununla birlikte, çoğu sistemde kök kullanıcı, çekirdek modunda çalışacak olan çekirdek modüllerini yükleyebilir, bu da etkin bir şekilde kök modunda çekirdek modunda kod çalıştırmanın bir yolunu verir.

Bununla birlikte, (iOS gibi) bunun mümkün olduğu (keyfi olarak) mümkün olmadığı, en azından güvenlik önlemlerinden yararlanmadan yapılan sistemler vardır. Bu çoğunlukla, kod imzalama zorunluluğu gibi artan güvenlik nedeniyledir.
Örneğin, yalnızca çekirdek modundan erişilebilen iDevices işlemcilerinde yerleşik AES şifreleme anahtarları vardır . Çekirdek modülleri olabilir olanlar erişmek, ancak bu çekirdek modüller kodu da bunları kabul çekirdek için sırayla Apple tarafından imzalanacak gerekecekti.

OS X'te, sürüm 10.11'den (El Capitan) bu yana, aynı zamanda "köksüz mod" olarak da adlandırılan (kök hala var olduğu için ad yanıltıcı olmasına rağmen) da vardır, bu da yükleyicilerin yapabileceği bazı şeyleri etkin bir şekilde yasaklar.
Alıntı AskDifferent bu mükemmel cevap :

İşte kökten bile kısıtladığı şey:

• / System, / bin, / sbin veya / usr içindeki hiçbir şeyi değiştiremezsiniz (/ usr / local dışında); veya yerleşik uygulamalardan ve yardımcı programlardan herhangi biri. Yalnızca Yükleyici ve yazılım güncellemesi bu alanları değiştirebilir ve hatta yalnızca Apple imzalı paketleri yüklerken bunu bile yapabilir.

Bahsettiğiniz "sistem çekirdek uygulaması", rootörneğin yüklenebilir çekirdek modülleri aracılığıyla kontrol altında . Elbette, bu yükleme çekirdek modüllerinin çekirdek tarafından desteklendiğini varsayar, hiç kimse bile mümkün olmayan eylemleri gerçekleştiremez root.

Aynısı sistem işlemleri için de geçerlidir. rootherhangi bir süreci öldürmesine izin verilir, ancak çekirdek bütünlüğünden ödün vermeden çekirdek modunda çalışan bir işlemi durdurmak mümkün değildir, bu yüzden hemen böyle bir işlemi durdurmak mümkün değildir. Not rootsadece hiçbir etkisi olmayacaktır kendisini öldürme, bu süreçleri öldürmek için inkar edilemez.

Son olarak, gerçek mod: Linux çekirdeği bunun için bir desteğe sahip değil, bu yüzden yine kimse mümkün olanı bile yapamaz root.

@Siguza, xizinsiz dosyaların çalıştırılmasından bahsetti , bu rootkullanıcı için oldukça muhtemel :

/lib/ld-linux.so.2 /path/to/executable

Bir örnek değişmez dosyasının değiştirerek olabilir: Bir dosya özniteliği ayarlayabilirsiniz iile chattrbile root için dosya değişmez hale getirir. Örneğin:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Dosyanın ls -lçıktıda normal yazılabilir dosya olarak göründüğünü unutmayın :

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Özelliği görmek iiçin kullanmanız gerekir lsattr:

# lsattr god
----i----------- god

Chattr ' in manuel sayfası , iözniteliği takip eder :

'İ' özelliğine sahip bir dosya değiştirilemez: silinemez veya yeniden adlandırılamaz, bu dosyaya bağlantı oluşturulamaz ve dosyaya veri yazılamaz. Yalnızca süper kullanıcı veya CAP_LINUX_IMMUTABLE özelliğine sahip bir işlem bu özelliği ayarlayabilir veya silebilir.

Yine de, kök değişmezliği kolayca geri alabilir:

# chattr -i god
# rm -v god
removed ‘god’

FreeBSD'de gmirrorönceden kurulmuş bir bölümde, hatta root olarak kullanamazsınız :

gmirror etiketi -v -b, gm0s1 ad4s1'i tercih eder gmirror
: meta4a ad4s1'de depolanamaz: İşleme izin verilmez.

Bunu yapabilmek için bir sysctl( kern.geom.debugflags=16) ayarlamanız gerekir.

rootayrıcalıklı bir kullanıcıdır, ancak bu haklar çekirdek tarafından verilir. Yani çekirdeğin ondan daha fazla imtiyazı var root.

Kök kullanıcının kendisinden işbirliğini rootüstlenerek, FUSE bağlantılarına ( allow_otherveya allow_rootseçenekleriyle) erişmesi engellenebilir , ancak bunun nedeni FUSE'nin bu şekilde davranmasıdır. FUSE sanal bir katman üzerinde bulunduğundan, mümkün olduğunca şeffaf ve ince olmaya çalışan ortak blok cihaz modüllerinin aksine izinleri başka bir katmana devretmek yerine, mantığa dayalı herhangi bir hatayı geri getirebilir.

Bu, dosya sistemini salt okunur yapmazsanız, kök kullanıcının seçeneği devre dışı bırakmasını veya FUSE modülünü seçeneği sessizce atan bir seçenekle değiştirmesini engellemez. Ancak, bu yalnızca “bekçileri izleyen” durumuna yol açar: sistemin yalan söylemediğini nasıl doğrulayabilirsiniz? Kabuk, size meşru bir FUSE modülünü gösteren bir chroot içinde oturuyor olabilirken, çekirdek aslında bunun kötü niyetli bir sürümünü çalıştırıyor.

Çalıştırılamayan dosyaları yürütememenin dosya izinlerine bağlı olduğu için önemsiz bir sınırlama olduğunu söyleyebilirim. (Bu, dışlanamayan bir dosya için /lib64/ld-linux-x86-64.so.2 kullanılarak çözülebilir, ancak çalıştırılmayan bir bağdaki dosya değil)

Ayrıca, bir dosya şu anda bir işlem tarafından kullanılıyorsa, dosya düzenlemesini engelleyen zorunlu dosya kilitleri sorunu da vardır, ancak süper kullanıcı işlemi öldürebilir.

Bir noktada, süper kullanıcı cihaz meşgulken bir cihazın bağlantısını kesemedi, ancak bu şimdi tembel bir miktar kullanarak yapılabilir.

Diğer sınırlamalar:

değiştirilemez dosyaları değiştiremez ve yalnızca yalnızca eklenmiş dosyaları ekleyebilir (linux, süper kullanıcının değiştirilemezleri kaldırmasına ve herhangi bir çalışma düzeyinde yalnızca bayrakları eklemesine izin verir, ancak kısmen amaçlarını yitirmesine izin verir)

salt okunur bir bağlama yazamıyor ya da bir yürütme olmayan bağda herhangi bir şeyi yürütemiyor

birleştirilemez bir montajı bağlayamıyor

blok aygıtı salt okunur ise, bir dosya sistemini salt okunur olarak yeniden kuramazsınız

allow-other veya allow-root-root-root-root-root-root-Root-root-root-root-root-Root-root-root-root-root-Ro-Ro-root-Ro-Ro-Ro-Ro-Ro-root-Ro-Ro-Ro-Ro

SELinux ayarlarını ihlal edemez

Kök etkileyen sistemin kendisinde bulunan kasıtlı sınırlamalar:

bir dosyanın c-zamanını doğrudan ayarlayamıyor (ya da daha önce uygulanmışsa doğum zamanını)

şifreleri düz metin olarak görüntüleyemiyorum