Bir sunucuda küçük bir sorun yaşıyoruz. Bazı kullanıcıların örneğin sudoroot ve root olmasının mümkün olmasını istiyoruz , fakat kullanıcının root şifresini değiştiremeyeceği kısıtlamasıyla. Diğer bir deyişle, diğer kullanıcıların ne yapacaklarından bağımsız olarak bu sunucuya giriş yapabileceğimiz ve kök olacağımızın garantisi.

Mümkün mü?

Bazı kullanıcıların örneğin yapabilmelerini sudove kökleşmelerini istiyoruz.

Şey, sudo çözmek için tasarlanan problem bu, bu kısım yeterince kolay.

ancak kullanıcı kısıtlama ile root şifresini değiştiremez.

SHW'nin bir açıklamada işaret ettiği gibi , sudo'yu yalnızca belirli kullanıcıların belirli kullanıcılar tarafından root olarak alınmasına izin verecek şekilde yapılandırabilirsiniz. Yani, kullanıcı1 yapmasına sudo services apache2 restartizin verebilir, kullanıcı2'nin sudo rebootsistem yöneticisi olarak işe alınmasına izin verirken başka hiçbir şey yapmasına izin user3vermez sudo -i. Sudo'yu nasıl ayarlayacağınız konusunda bir sürü soru var ya da burada arama yapabilir (veya sorabilirsiniz). Bu çözülebilir bir problem.

Bununla birlikte, bir kabuğa sudo -iveya sudokabuğa yeteneği ( sudo bashörneğin) verilen bir kullanıcı her şeyi yapabilir. Bunun nedeni, sudo'nun kabuğu başlattığı zaman, sudo'nun kendisi resmin dışında kalmasıdır. Farklı bir kullanıcının güvenlik bağlamını sağlar (çoğunlukla kök), ancak yürütülen uygulamanın ne yaptığını söylemez. Eğer sırayla bu uygulama başlarsa, passwd rootsudo'nun yapabileceği bir şey yoktur. Bunun diğer uygulamalar üzerinden de yapılabileceğini unutmayın; örneğin, daha gelişmiş editörlerin çoğu, bu düzenleyici işlemin (yani, kök) etkin kullanıcı kimliği ile çalıştırılacak olan bir kabuk olan kabuk üzerinden bir komut çalıştırma olanakları sağlar .

Diğer bir deyişle, diğer kullanıcıların ne yapacaklarından bağımsız olarak bu sunucuya giriş yapabileceğimiz ve kök olacağımızın garantisi.

Üzgünüm; Eğer gerçekten "Kök erişimi olan biri ne yaparsa yapsın sisteme giriş yapıp sistemi kullanabileceğimize emin ol" demek istiyorsan, (tüm niyet ve amaçlar için) yapılamaz. Çabuk bir "sudo rm / etc / passwd" veya "sudo chmod -x / bin / bash" (ya da hangi kabuk kökü kullanırsa) ve yine de çok fazla hortumlanacaksınız. "Oldukça fazla hortumlanmış" anlamı "yedekten geri yüklemeniz gerekecek ve bir parmak parmağından daha kötü bir şey yapmadıklarını ummak zorunda kalacaksınız". Kullanılmaz bir sisteme yol açan kazayla yanlış bir taarruz riskini azaltmak için bazı adımlar atabilirsiniz , ancak kötüye kullanımın sistemi sıfırdan veya en azından bilinen bir şekilde yeniden inşa etme ihtiyacı dahil olmak üzere çok ciddi sorunlara neden olmasını önleyemezsiniz. iyi yedeklemeler.

Bir kullanıcıya, sistemde sınırsız bir kök erişimi vererek, o kullanıcıya (kötü niyetli bir niyete sahip olmadığından ve kazayla karışmadığından, bu kullanıcıya (yürütmeyi seçebilecekleri herhangi bir yazılım dahil, ls gibi sıradan bir şey dahil) güvendiğinizden emin olabilirsiniz. Kök erişiminin doğası budur.

Örneğin sudo üzerinden sınırlı kök erişimi biraz daha iyidir, ancak herhangi bir saldırı vektörünü açmamaya dikkat etmeniz gerekir. Kök erişiminde, ayrıcalık yükselme saldırıları için birçok olası saldırı vektörü vardır.

Onlara kök olmanın gerektirdiği erişim düzeyine güvenemiyorsanız, çok sıkılmış bir sudo yapılandırmasına veya yalnızca söz konusu kullanıcıya kök erişimini sudo veya başka bir yöntemle yapmamanız gerekir .

Bu neredeyse imkansız. Her şeyden önce, onlara kök olma gücünü verirseniz, bir şey yapmalarını önlemek için yapabileceğiniz hiçbir şey yoktur. Kullanım durumunuzda, sudokullanıcılarınıza bazı kök yetkileri verirken, bazılarının kök olmalarına izin vermeden kısıtlamaları için kullanılmalıdır .

Senin senaryoda, erişimi kısıtlamak gerekir suve passwdbaşka hemen hemen her şeyi komutları ve açık erişim. Sorun şu ki, kullanıcılarınızın doğrudan düzenlemelerini /etc/shadow(veya /etc/sudoersbu konuda) doğrudan yapmaktan ve kökü kaçırmak için yedek bir kök parolasını bırakmamak için yapabileceğiniz hiçbir şey yok . Ve bu sadece mümkün olan en basit "saldırı" senaryosudur. Bir veya iki komut haricinde sınırsız güce sahip Sudoers, tam kök erişimini ele geçirme kısıtlamaları etrafında çalışabilir.

Tarafından önerildiği gibi tek çözüm, yorumlardaki DSİ kullanmaktır sudokullanıcıların yerine komutların kısıtlı setine erişim izni vermek.

Güncelleme

Kimlik doğrulama için Kerberos biletleri kullanıyorsanız, bunu yapmanın bir yolu olabilir. Dosyanın kullanımını açıklayan bu belgeyi okuyun .k5login.

İlgili bölümden alıntı yapıyorum:

Diyelim ki kullanıcı alice kendi dizinde şu satırı içeren bir .k5login dosyasına sahip olduğunu varsayalım:
bob@FOOBAR.ORG
Bu bob'un, bob'un Kerberos biletlerini kullanarak alice'nin hesabına erişmek için ssh (1) gibi Kerberos ağ uygulamalarını kullanmasına izin verir.
...
Bob, Kerberos biletlerini kendi ana sorumlusu olarak sakladığından, alice'nin biletlerini bob@FOOBAR.ORGgerektiren herhangi bir sitenin ana bilgisayarına root erişimi veya alice'nin şifresini değiştirme kabiliyeti gerektiren herhangi bir ayrıcalığa sahip olmayacağına dikkat edin.

Yine de yanılmış olabilirim. Hala belgeleri gözden geçiriyorum ve henüz Kerberos'u kendim denemedim.

Gerçek yöneticiniz berbat olsa bile "acil durum yöneticisi" erişiminiz olduğundan emin olmak istediğinizi farz ediyorum (ancak bunun dışında ana yöneticiye tamamen güveniyorsunuz).

Popüler bir yaklaşım (çok aceleci olsa da) , genellikle adlandırılmış (root geriye doğru) olan ikinci bir kullanıcıya sahipuid=0 olmaktır toor. Farklı bir şifreye sahiptir ve yedek erişim işlevi görebilir. Eklemek için büyük olasılıkla düzenlemeniz /etc/passwdve /etc/shadow( rootsatırları kopyalamanız ) gerekir.

Her şey başarısız ancak güvenli değil, ancak yalnızca "ana yöneticinin" şifreyi önceden haber vermeksizin değiştirmesine karşı güvenceye almanız gerekiyorsa, çalışacaktır. toorHesabı kaldırarak etkisizleştirmek çok önemlidir ; bu nedenle, tek fayda ayrı bir parola sahip olmaktır.

Alternatif olarak, alternatif kimlik doğrulama mekanizmalarına, yani sshanahtarlara libnss-extrausers, LDAP'a vb. Bakmak isteyebilirsiniz .

Yöneticinin hala kötü bir şekilde vidalanabileceğini unutmayın. Örneğin, güvenlik duvarını engelleyerek.

Çok güvenli bir sisteme sahip olmak istiyorsanız, unix kullanıcısının da (örn. Root) çok daha iyi taneli olabilen bir rolle geldiği SELinux'u kullanmayı düşünün. Yönetici kök erişiminize izin vermek, ancak yalnızca sınırlı bir rol vermek isteyebilirsiniz (örneğin, yalnızca apache'yi yönetmek için). Ancak bu, politikayı doğru bir şekilde yapılandırmak için sizin tarafınızdan oldukça fazla çaba gerektirecektir.

Kökün özü, sistemin sınırsız bir şekilde yönetilmesidir. Bunu SELinux ile çimdikleyebilirsiniz (eskiden herkesin root olarak giriş yapabileceği bir demo sitesi vardı, ancak gücü erişim sistemi üzerinden sakat kalmıştı), ama mesele bu değil. Mesele şu ki, bu probleminizin yanlış çözümü.

Şimdi, sorununun ne olduğunu söylemediniz, ancak bu kullanıcıların ellerini parola parolasından uzak tutmaları konusunda güvenmiyorsanız, iş yapmalarının kökleri olmaz. Web sunucusunu veya çeşitli donanım aygıtlarını veya warp sürücüsünü veya her neyse yönetmeleri gerekiyorsa, bunun için bir çözüm oluşturun. Süper güçlü bir grup oluşturun, ihtiyaç duyduğu tüm erişimi verin ve ekleyin. Yalnızca kök sistem çağrıları yürütmeleri gerekiyorsa, bazı setuid programları yazın.

Elbette bu tür erişime sahip (ve biraz bilgi alan) bir kullanıcı muhtemelen sistemi kolayca kesebilir, ama en azından işletim sistemi güvenlik modeli ile çalışıyorsunuz, buna karşı değilsin.

PS. Parola olmadan kendinize kök erişimi düzenlemenin birçok yolu vardır; Eğer iseniz biri için, /etc/sudoers(kısıtlama olmaksızın) sadece ile, örneğin kök olmak kendi şifrenizi ihtiyaç sudo bash. Ama oraya gitmene gerek yok.

Muhtemelen, en azından teoride SELinux kullanarak bunu yapmak mümkündür . Bu, bir kullanıcının veya sürecin ne yapmasına veya izin verilmediğine ilişkin çok daha kesin kurallar belirlemenizi sağlar. SELinux ile bile, bir kullanıcının root şifresini değiştirmesini imkansız hale getirmek zor olabilir, ancak yine de yapması gerekeni yapabilir.

Gerçekten de, root şifresini değiştirmesine izin verilmeyen kullanıcının aslında yapması gerekenlere bağlıdır. Bunun ne olduğunu çözmek ve özellikle sudo kullanarak bu izinleri vermek muhtemelen daha kolay ve güvenli olacaktır.

Belki de kullanıcıların bir sanal makineye veya LXC kabına kök erişimi sağlamalarını düşünmelisiniz. Bu, bir sisteme tam kök erişimine sahip olmalarını sağlar, onların ana bilgisayara giriş yapmalarını veya idari işlemlerde bulunmalarını engellemelerine izin vermez.

Pratik olarak uygulanabilir olacağını bilmiyorum ama burada bir kirli kesmek:

1. /etc/passwdfiili çağırmadan önce dosyayı başka bir yere kopyalayacak bir sarmalayıcı komut dosyası / programı yazınsudo
2. Normal kullanıcının kullanmasına izin ver sudo
3. Görevini tamamladığında veya sudodan çıktığında /etc/passwddosyayı geri yükle

Biliyorum, bunu başarmak için göz önünde bulundurmanız gereken birçok eksi şey var. Sonuçta, kirli bir kesmek

Deyimi sudosadece kök verilmesi içindir ve bundan sonra herhangi bir koruma olmaz pervasızca yanlıştır.

visudoSudoers dosyasını değiştirmek için kullanın . İşte örnek bir satır:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroizin verdiğimiz kullanıcı adı. %Bir gruba uygulanmasını sağlamak için önüne bir koyun .
• ALLbu kural için bir isimdir. Sudoers, küresel izinler vermekten çok daha fazlasını yapabilir. Yine de karmaşıklaştığı yer burası.
• = açıklama gerektirmez
• ALL:ALLolarak okur (who_to_run_it_as: what_group_to_run_it_as). Bu şekilde bir komutun çalıştırılmasına izin verebilirsiniz, ancak yalnızca belirli bir kullanıcı veya grup bağlamında.
• NOPASSWD: şifre istemini kapatmasını söyler.
• /path/to/command Belirli komutları belirtmenize izin verir path_to_commmand, another_command

Hatırlanması gereken şey sudo, çoğunlukla ev kullanıcıları tarafından kök ayrıcalıklarına tırmanmak için kullanılırken, belirli komutlara erişimi çok daha ayrıntılı bir şekilde kontrol etmek için kullanılabiliyor ve kullanılıyor.

Referanslar

• buradaki diğer cevabımdan

(Ubuntu'yu tanımıyorum, ancak Fedora / Red-Hat'a benzemeli)
Kök şifresini değiştirmeye erişimi kısıtlamayı hayal edebildiğim tek şey tam root erişimi vermiyor, belki sudo ile veya erişimi kısıtlamak için SElinux kullanmak şifre dosyasına ... ancak kök, genellikle sınırsız erişime sahip olduğundan ve SElinux’i güncelleyebildiğinden veya şifre dosyasını yeniden etiketleyebildiğinden veya şifreyi değiştirmek için önceden hazırlanmış bir program çalıştırabildiğinden, çok fazla erişime güvenmem.

Parolayı değiştirmeyecek kadar güvenmiyorsanız, muhtemelen onlara kök erişimi vermemelisiniz. Aksi takdirde kazalardan kaçınmaya çalışıyorsunuzdur.

Yalnızca köke erişiminizi korumaya çalışıyorsanız, kök parolayı geri yükleyebilecek bir program kurun, böylece değiştirilse bile minimum erişimle geri yüklenebilir. (sudo kendi başına iyidir)

İhtiyacınız:

Bir sunucuda [...] küçük bir sorun yaşıyoruz, yani, diğer kullanıcıların ne yapacağına bakılmaksızın, o sunucuya hala giriş yapıp kök olabileceğimizin garantisi.

Sorunuzdan, sisteminizi tahrip etmeyi amaçlayan rastgele kötü niyetli kullanıcılarla karşı karşıya kalmıyorsunuz, bunun yerine şimdi ve sonra yaramazlıklara neden olabilecek yarı-güvenilir kullanıcılar varmış gibi görünüyor (belki öğrenciler?). Önerilerim bu durumu ele alıyor, kötü niyetli kullanıcılar tarafından yapılan bir all-out saldırısı değil.

1. Sunucuyu sanal bir ortam içerisinde çalıştırın. Sunucunun dosya sistemini bağlayabilecek ve değiştirilmiş dosyaları bilinen iyi sürümlerle değiştirebileceksiniz. Beklediğiniz olası hasara bağlı olarak, tüm kritik dizinlerin (/ bin, / sbin, / etc, / usr, / var, vb.) Anlık görüntülerini alabilir ve geri kalanını bırakırken hasarlı dosyaların üzerine yazmak için anlık görüntüyü genişletebilirsiniz. sistem bozulmamış.

2. Sistemi salt okunur, örneğin bir DVD-R'den çalıştırın. Bir sonraki yeniden başlatmaya kadar sistemin çoğu parçasının durağan olması ile yaşayabilirseniz, bu iyi bir seçenektir. Ayrıca, sanal ortamı olan bir salt okunur destek deposu kullanabilir veya temel sistemi ağ üzerinden yükleyerek yeniden başlatmalar arasında değişiklik yapmayı, yeni bir DVD-R yazmaktan çok daha kolay hale getirebilirsiniz.

3. Çekirdek modülleri. Çekirdeğin Linux Güvenlik Modülleri (LSM) güvenli modüller oluşturmak için temel sağlar. LSM, SELinux tarafından kullanılır, ancak Smack, TOMOYO ve AppArmor gibi daha az bilinen ve daha basit sistemler tarafından da kullanılır. Bu makalede , seçeneklere genel bir bakış vardır. Şanslar, / etc / passwd, / etc / shadow veya istediğiniz diğer dosyalara root tarafından bile yazılmasını engellemek için kullanıma hazır olarak yapılandırılabilir.

4. # 1 ile aynı fikir, ancak sunucu sanal bir ortamda olmadığı zaman. Sunucuyu, sunucunun dosya sistemini otomatik olarak bağlayacak ve bilinen iyi kopyalarla her önyüklemedeki temel sistemin üzerine yazacak olan, canlı bir CD gibi salt okunur bir işletim sistemine yüklemesini sağlayabilirsiniz. Salt okunur işletim sistemi ana işletim sistemine önyükleme yapar.

5. Yine, bunların bir üst seviyeye (öğretmen / patron) sorumlu olan yarı-güvenilir kullanıcılar olduğu varsayılarak, en iyi cevap Linux Denetimi olabilir . Bu yolla, güvenlikle ilgili her eylemi ve kimin attığını bileceksiniz (kimin kullandığını bileceksiniz çünkü tüm kullanıcılar kök hesabı paylaşsalar bile, ilk önce kullanıcı hesaplarından ayrılacaklardır). Aslında denetim günlüğünü gerçek zamanlı olarak ayrıştırabilir ve hasarlı dosyaları değiştirebilirsiniz. / etc / shadow üzerine yazılsın mı? Hiç sorun değil, sadece izleme sunucusunu anında iyi bilinen bir sürümle değiştirmesini isteyin.

Gereksinimlerinize göre araştırmak isteyebileceğiniz diğer teknolojiler:

• Linux Bütünlüğü Ölçüm Mimarisi / Genişletilmiş Doğrulama Modülü (IMA / EVM) ve
• Güvenilir Platform Modülleri (TPM).

Diğer cevapları tamamlamak için, senaryonun kök kontrolünü kaybettiğinizde nadir görülen bir durum olduğunu algıladığınız ve bu durumlarda bir sunucunun yeniden başlatılmasına izin verildiğini kabul edeceğim. (Sonuçta, makinenin ele geçirildiğini düşünüyorsanız, yine de çevrimdışı duruma getirmek isteyeceksiniz.)

Bunun en büyük avantajı yapılandırılacak hiçbir şey olmamasıdır. Sorunuz şu şekilde olur: " Kök şifresini unuttum, nasıl geri döneceğim? " Ve bunun cevabı yeniden başlatmak ve makine açıldığında tek kullanıcılı modu seçmek. Bu size şifreyi bilmenize gerek kalmadan bir kök kabuğu verir. Bu noktada yeni bir şifre belirleyebilirsiniz. (Git ve herhangi bir hasarı tamir etmenin yanı sıra ...)

Sunucunuzu bir VM'ye ( VirtualBox gibi ) klonlarsanız, insanlara sınırsız kök erişimi verebilir ve yine de konuk işletim sisteminin bölümlerine her zaman doğrudan erişime sahip olacağınızı ve bu nedenle son kontrolün /etc/passwdve gibi, çünkü ana sistem üzerinde kök olacaktır.

Tabii ki, sınırsız root erişimi vermek hala doğru çözüm olmayabilir: eğer veri güvenliği bir konuda veya sizin sorumluluğunuzda ise, root erişimi veremezsiniz.

Gereklilik teknik olarak mümkün değildir. Daha önce açıkça yorumlandığı gibi, sudobir kullanıcıya sınırsız veya daha sınırlı haklar verilmesi, o kullanıcıya güvendiğiniz anlamına gelir . Kötü niyetleri olan ve yeterli teknik kabiliyet ve azim olan biri, ortaya konan herhangi bir engelden geçebilir.

Bununla birlikte, kullanıcılarınızın kötü niyetli olmadıklarına güvenebileceğinizi varsayarsak , bir politika sorununda şifre değiştirmedeki kısıtlamaları yapabilirsiniz . passwd"Lütfen root şifresini değiştirmeyin" u hatırlatacak program için bir sarmalayıcı oluşturabilirsiniz . Bu, sorunun kaynağını, kök şifresini değiştiren kullanıcıların, yanlış anlama nedeniyle yaptıklarını (belki yaptıktan sonra kendi şifrelerini değiştirdiklerini düşünüyor gibi) olduğu varsayılmaktadır sudo bash.

Özel (nadir) koşullar altında, eğer tam bir güven mümkün değilse ve sudoyeterli ancak makul derecede güvenli parçalara erişimin kesilmesi mümkün değilse , parola değiştirmeye (veya herhangi bir diğer sistem kurcalama biçimine) karşı kurumsal yaptırımlar oluşturmayı düşünebilirsiniz ; Kritik kaynakların izlenmesi, böylece , belirlenen politikaları aşmak için tespit edilmek kolay değildir - ve kullanım kuralları ve izleme konusunda kamuya açık ve şeffaf olun.

İzleme ve keşif yönü, bu yolda yürümeyi seçmeniz durumunda, başka bir sorudan yararlanan zor teknik bir sorundur. Bana öyle geliyor ki ihtiyacımız olacak

1. Bir kullanıcının kimliğini ne zaman root olarak değiştirdiğini tespit et ve oluşturulan tüm işlemleri takip et;
2. Her süreçten sorumlu orijinal kullanıcının kim olduğunu görmek ve bundan sonra yarı güvenilir kullanıcıların günlükleri gönderme erişiminin olmadığı uzaktaki bir bilgisayarı kullanarak süreç oluşturma işlemlerini günlüğe kaydedin;
3. ne olduğunu günlüğe kaydetmek ve daha sonra politika ihlalinin arkasında kimin olduğunu bulabilmek için bir tür sistem izlemesi kullanmak .

En azından yazma, işlem oluşturma exec()ve elbette ağ oluşturma girişimi için güvenli dosya kümesinin dışında bir oturum açmamız gerekiyor .

Uygulama, değiştirilmiş libc veya (çok daha iyi) sistem çağrı takibi ile yapılabilir.

Tabii ki, böyle bir izleme ve günlüğe kaydetmenin% 100 doğru çalışmasını sağlamak imkansızdır, uygulanması kolay değildir ve ayrıca çalışması için ek kaynaklar gerektirir. Bu , parola değişikliğini veya diğer istenmeyen sistem değişikliklerini durduramaz , ancak suçlu kullanıcıyı bulmayı veya en azından izlenmesi ve bazı kötü niyetli kullanıcılar için daha az davet edilmesini sağlayacak bir yanılsama yaratmasını mümkün kılar (ama Yerine getirilen teknik önlemlerin temel boşluğunu gören bazı sorun seven bilgisayar korsanlarının, bu zorluğu benimsemeleri ve sistemi sadece eğlenmek için atlatmaya çalışmaları teşvik edilebilir.

Orijinal formüle edilmiş soru işe yaramaz. Asıl amaç "hala giriş yapmak" gibi gözüküyor, bu nedenle başka bir kişiye verilen root erişimi olsa bile çalışmaya devam eden bazı acil durum girişlerinden bahsediyoruz. Bunu açıkça belirten Anony-Mousse'a şerefe.

Sorun şudur: Eğer sahibi kutuya fiziksel erişime sahipse, sisteme mantıksal erişimleri kolayca kurtarabilir (hala canlı olmasını sağlar :). Olmazsa - root şifresini saklamak, örneğin sshd down veya bad network kurulumundan kurtarılmaz, bu nedenle sisteme hala erişilemez.

Sistemin idari ayrıcalıklara sahip bir kişi tarafından zarar görmesini önleme konusu, SE soru biçimine uyacak kadar geniş görünüyor.

Uzaktan acil durum giriş çözümünden bahsetmek en iyi yol, eğer uygunsa IPMI'dir (bence). Sistem sahibi sanal sürücüyü istediği zaman atabilir, önyükleyebilir ve sistem kurtarma işlemine başlayabilir.

IPMI mevcut değilse, yukarıda daha önce önerildiği gibi uygun bir sanallaştırma teknolojisi çalışabilir.

/etc/sudoersDosyanızda sudo erişimini sınırlayabilirsiniz

/ Etc / sudoers sözdizimini tam olarak açıklamak için bir örnek kural kullanacağız ve her sütunu parçalayacağız:

jorge  ALL=(root) /usr/bin/find, /bin/rm

İlk sütun, bu sudo kuralının hangi kullanıcı veya gruba uygulanacağını tanımlar. Bu durumda, kullanıcı jorge. Bu sütundaki sözcük% sembolünden önce geliyorsa, sistem aynı adı taşıyan kullanıcılara ve gruplara sahip olabileceğinden, bu değeri kullanıcı yerine grup olarak belirtir.

İkinci değer (ALL), bu sudo kuralının hangi ana bilgisayara uygulanacağını tanımlar. Bu sütun en çok birden fazla sistemde bir sudo ortamı dağıttığınızda kullanışlıdır. Masaüstü Ubuntu sistemi veya sudo rollerini birden fazla sisteme dağıtmayı planlamadığınız bir sistem için, bu değeri tüm ana bilgisayarlarla eşleşen bir joker olan ALL olarak ayarlanmış olarak bırakabilirsiniz.

Üçüncü değer parantez içinde belirlenir ve birinci sütundaki kullanıcının hangi kullanıcı veya kullanıcıları bir komut olarak çalıştırabileceğini tanımlar. Bu değer root değerine ayarlanmıştır, yani son sütunda belirtilen komutları root kullanıcısı olarak çalıştırması için jorge'a izin verileceği anlamına gelir. Bu değer, jorge'nin komutları sistemdeki herhangi bir kullanıcı olarak çalıştırmasını sağlayan ALL joker karakterine de ayarlanabilir.

Son değer (/ usr / bin / find, / bin / rm), birinci sütunda bulunan kullanıcının üçüncü sütunda kullanıcı (lar) olarak çalıştırabileceği virgülle ayrılmış bir komut listesidir. Bu durumda, Jorge'nin kök olarak bulup çalıştırmasına izin veriyoruz. Bu değer, jorge'nin sistemdeki tüm komutları root olarak çalıştırmasını sağlayacak ALL joker karakterine de ayarlanabilir.

Bunu akılda tutarak, X komutlarına virgülle ayrılmış bir şekilde izin verebilirsiniz ve buna eklemediğiniz passwdsürece iyi olmalısınız

1/2 kök yoktur :) Kök ayrıcalıklarını verdikten sonra istediklerini yapabilirler. Alternatif olarak, kısıtlanmış bir bash kabuğu çalıştırmak için sudo'yu kullanabilir veya root ayrıcalıklarına sahip olmayan bir kaba bürü çalıştırabilirsiniz.

Sunucuya root olarak giriş yapmak için güvenli olmayan bir mekanizmaya sahip olmak istiyorsanız, başka bir kullanıcı oluşturabilir uid=0veya kök şifresini periyodik olarak sıfırlayacak basit bir cron oluşturabilirsiniz.

Sudo kullanmak yerine bir tekerlek grubu eklemeyi deneyin. sudo, kullanıcının rootmuş gibi çalışmasına izin verir; bu, çalıştırmaktan farklı olmadığı anlamına gelir:

su -

kök olmak için. Kök kimliği = 0; tekerlek kimliği = 10. İnsanlar adları kullanır ancak işletim sistemi kullanıcı kimliğini kullanır. Belirli komutlar, tekerlek grubunun bir üyesi tarafından çalıştırılamaz. (Eğer tekerlek kullanıyorsanız, kök grup üyesi olarak kök ekleme hatasını yapmayın). Tekerleğin ne olduğunu bilmiyorsanız Red Hat belgelerine bakın.

Diğer bir seçenek ise şifre yerine ssh tuşunu kullanmaktır. Sudo kullanan kişilerin ortak anahtarlarını ~ / .ssh / yetkili anahtarlar dosyasına eklemeyeceğinden emin olabilirsiniz, bu kök şifrenin değişmesiyle ilgili herhangi bir sorun yaşar çünkü kök şifresi etkili bir şekilde yoksayılır.

Bu kullanıcılara duyulan güveni arttırmayı tercih ediyorsanız (kendi ortak anahtarlarını eklememek için) genişletilmiş dosya özniteliklerini kullanmayı ve Immutable bit'i kullanmayı deneyin. ~ / .Ssh / yetkili anahtarlar dosyanızı oluşturduktan sonra / etc / ssh / sshd_config ve / etc / ssh / ssh_config 'u yapılandırdıktan sonra, Immutable bit' i ayarlayın. Tabii, bununla da uğraşmanın yolları var - hiçbir şey mükemmel değil.

Herhangi bir sistemde, içerdekiler en yüksek risktir. Gösteriyi yöneten kişi yığının tepesinde. İlgili bir düşünce sözleşmelere aittir. Avukatlar size "Asla iş yapmak için bir sözleşmeye ihtiyacınız olan birisiyle iş yapmayın" diyecekler. Sağduyu bize, "Asla bir sözleşme yapmadan iş yapma" diyor. İş yapacak kadar güvendiğiniz birini bulduğunuzda, sözleşmeyi birbirinizin ihtiyaçlarına göre yazın.

Sunulan tüm cevaplar, benimki dahil, fiziksel erişimi ele almıyor. Her kimde ise, kontrol sahibi. Eğer siz değilseniz, o zaman birisinin giriş yapmasını engellemenin bir yolunu bulması durumunda makineye fiziksel olarak erişebilecek kişiyi almanızın veya sizden sonra bile giriş yapmanın bir yolunu bulmanızın bir yolu vardır. bunun olmasını önlemeye çalıştım. Tabii ki, eğer daha fazla fiziksel erişime sahipseniz, bunlardan hiçbirine ihtiyaç duymayabilirsiniz, ancak bir çiftin uygulanmasının yine de dikkate alınması gerekir, eğer rahatsızlık duymuyorsanız.

-John Crout

Bunun bir yolu bunun /etcyazılabilir olmadığından emin olmak olacaktır . Hiç kimse tarafından, sudoeretrafta olabileceği sürece .

Bu, ağa monte edilerek yapılabilir ve diğer taraftan cihazın yazılamamasını sağlayın.

Bu, yazma erişimini önleyen yerel bir cihaz kullanılarak yapılabilir. ( write blockerDonanımı arayın)

Önemli olan, kısıtlamanın o makinenin kök kavramı dışında uygulanması gerektiğidir. Yaratıcı bir bilgisayar korsanı, kontrol edebileceği ortamın içine koyduğun tüm engellerin yolunu bulacaktır. Kök parolasını değiştirebilseydi, o zaman a sudoer.

Kullanıcının ayrıca, salt okunur bir şekilde monte etmiş olmanız gereken giriş yeteneklerinizi bozamayacağından emin olmak için /binve /sbin.

Ve düzenli aralıklarla ağ bağlantısını geri yükleyen bir komut dosyasına sahip olmanız gerekir.

(Bir yazı tipi olarak: Eğer sudoer'in çok sınırlı bir komutlar dizisine izin verirseniz ve her biri için onlardan kopamayacağına / değiştiremeyeceğine emin olursanız, /etcyazılabilirken önleyebilirsiniz .)