Kodun imzalandığından emin olmak için kontrol eden bir kabuk var mı?

Bu hafta PowerShell ile uğraşıyordum ve çalıştırılabilmeleri için komut dosyalarınızı imzalamanız gerektiğini keşfettim. Linux'ta bash betiklerinin çalıştırılmasını önlemeye ilişkin benzer bir güvenli işlev var mı?

Buna benzer tek işlevsellik, farkında olduğum SSH'nin belirli bir anahtar gerektirmesidir.

Kullanıcıların komut dosyalarını çalıştırma yeteneğini kilitliyorsanız işlevselliği sudokullanabilirsiniz digest.
Yürütülmeden önce sudoersdoğrulanacak bir komut dosyasının / yürütülebilir dosyanın karmasını belirleyebilirsiniz sudo. Bu nedenle, imzalama ile aynı olmasa da, komut dosyasının sudoers da değiştirilmeden en azından değiştirilmediğine dair temel bir garanti verir.

Komut adının önüne Digest_Spec eklenirse, komut yalnızca belirtilen SHA-2 özeti kullanılarak doğrulanabilirse başarıyla eşleşir. Bu, sudo'yu çağıran kullanıcının komuta veya üst dizinine yazma erişimine sahip olduğu durumlarda yararlı olabilir. Aşağıdaki özet biçimleri desteklenir: sha224, sha256, sha384 ve sha512. Dize, onaltılık veya base64 biçiminde belirtilebilir (base64 daha küçüktür). Openssl, shasum, sha224sum, sha256sum, sha384sum, sha512sum gibi onaltılık formatta SHA-2 sindirimleri üretebilen birkaç yardımcı program vardır.

http://www.sudo.ws/man/1.8.13/sudoers.man.html

Evet ve hayır.

Linux yazılım dağıtımı, Windows yazılım dağıtımından biraz farklı çalışır. (Yerleşik olmayan) Linux dünyasında, yazılımı dağıtmanın birincil yöntemi bir dağıtımdır (Ubuntu, Debian, RHEL, Fedora, Arch, vb.). Tüm büyük dağıtımlar yaklaşık on yıldır paketlerini sistematik olarak imzalamaktadır.

Yazılım bağımsız olarak dağıtıldığında, yazılımlarını nasıl göndereceklerine karar vermek satıcıya bağlıdır. İyi satıcılar, büyük dağıtımlarla uyumlu tüm paket kaynaklarını sağlar (tüm Linux için birleşik bir dağıtım mekanizması yoktur: yazılım dağıtımı, dağıtımlar arasındaki ana ayrım noktalarından biridir) ve satıcının anahtarıyla imzalanır. Linux dağıtımları nadiren üçüncü taraf satıcılar için imza yetkisi olarak hareket eder (Canonical bunu Ubuntu ortaklarıyla yapar, ancak çok az sayıda satıcıyı kapsar) ve bence tüm büyük dağıtımlar TLS ortak anahtar altyapısı yerine PGP güven ağını kullanıyor. bir anahtara güvenmek isteyip istemediklerini anlamak kullanıcıya bağlıdır.

Yerel bir yürütülebilir dosya, bir veri dosyası veya birden çok dosyadan oluşan yazılım paketlerinden tek bir komut dosyasından oluşan yazılım paketlerini belirleyen özel bir mekanizma yoktur. Bir yazılım paketini doğrulamak, bir komut dosyasını çalıştırmaktan tamamen dik bir endişe kaynağı olduğundan, yaygın bir komut dosyası yorumlayıcısında herhangi bir imza doğrulaması yerleşik değildir.

Bence Windows, kökeni olan dosyalara açıklama ekler ve kaynağı "yerel" yerine "indirilen" bir dosyayı çalıştırmak için kullanıcı onayı gerektirir. Linux gerçekten benzer bir mekanizmaya sahip değil. En yakın şey yürütme iznidir: indirilen bir dosyanın yürütme izni yoktur, kullanıcının dosyayı açıkça etkinleştirmesi gerekir ( chmod +xkomut satırında veya bir dosya yöneticisinde eşdeğer eylem).

Linux, dijital imzalara dayalı bash komut dosyalarının yürütülmesini sınırlama yeteneği sağlamaz.

İkili çalıştırılabilir dosyaları doğrulamak için bazı çalışmalar vardır. Bilgi için https://lwn.net/Articles/488906/ adresine bakın .

Tek kelimeyle, "hayır".

Linux, yürütülebilir dosyalar ve komut dosyaları arasında gerçekten bir ayrım yapmaz; #!başında girdi değerlendirmek çalıştırmak için ne programı çekirdek anlamanın bir yolu ama bir senaryo çalıştırılabilir tek yol değil.

Yani, örneğin, bir senaryom varsa

$ cat x
#!/bin/sh 
echo hello

Sonra bunu komutla çalıştırabilirim

$ ./x

Bu, çekirdeğin denemesine ve yürütmesine, yerini bulmasına #!ve /bin/sh xbunun yerine etkili bir şekilde çalışmasına neden olur .

Ancak ben de bu değişkenlerden herhangi birini çalıştırabilirsiniz:

$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x

ya da

. ./x

Çekirdek execkatmandaki imzalamayı zorunlu kılmaya çalışsa bile, bunu sadece yorumlayıcıyı komut dosyasıyla parametre olarak çalıştırarak atlayabiliriz.

Bu, imzalama kodunun yorumlayıcının içinde olması gerektiği anlamına gelir. Ve bir kullanıcının imzalama zorlama kodu olmadan kendi kabuk kopyasını derlemesini ne engeller ?

Bunun standart çözümü imzalama kullanmak değil, Zorunlu Erişim Kontrolleri (MAC) kullanmaktır SELinux. MAC sistemleri ile her kullanıcının tam olarak neyi çalıştırmasına ve katmanları geçişine izin verileceğini belirleyebilirsiniz. Örneğin, "normal kullanıcılar herhangi bir şeyi çalıştırabilir, ancak web sunucusu ve CGI işlemleri yalnızca /var/httpddizindeki öğelere erişebilir ; diğer her şey reddedilir" diyebilirsiniz .

Linux dağıtımlarında genellikle gnupg bulunur . Bana tüm istediğiniz gibi bağımsız bir komut dosyası karşı müstakil bir gpg imzasını kontrol basit bir bash sarıcı ve sadece kontrol başarılı olursa komut dosyasını çalıştırmak için ilerliyor gibi geliyor:

#!/bin/sh
gpgv2 $1.asc && bash "$@"

Hemen akla gelen karşıt soru, "Kullanıcıların yazdıkları programları çalıştırmasını neden engellemek istesiniz? "

1. İlk başta kodu kimin yazdığını tespit etmek tam anlamıyla imkansızdır . Komut dosyasının sahibi, nereden geldiğine bakılmaksızın, dosyanın içeriğini gerçekte kim kaydetmişse odur. İmzayı zorunlu kılmak , bir onay iletişim kutusunun karmaşık bir yedeğidir: "Bunu yapmak istediğinizden emin misiniz?" Linux'ta bu sorunun bir kısmı imzalı paketlerle şeffaf bir şekilde çözülür ve kullanıcıların varsayılan olarak sınırlı erişime sahip olmasıyla azaltılır. Kullanıcının ayrıca başkalarının kodunu çalıştırmanın tehlikeli olabileceğini bilmesi beklenir *.
2. Aynı şekilde, bir komut dosyasını imzalamak bir dosyayı kaydetmekten çok daha karmaşık bir işlemdir. En iyi durumda bu, kullanıcıdan bir belgeyi imzalamaya benzer bir işlem gerçekleştirdiğini fark etmesini ister ve devam etmeden önce söylediklerini incelemelidir. Büyük olasılıkla çok az bir seviyede kullanıcının betiği çalıştırmasına izin verilecek teknik yeterlilik sağlar . En kötü durumda, istediklerini çalıştırmak için uzun bir dizi çemberin içinden atlamaya istekli olduğunu gösterir . Linux * üzerinde teknik yeterlilik varsayılmıştır.
3. İnsanların komut satırlarına bir dizi komut yazarken / yapıştırırken bariz bir şekilde kötü amaçlı kod algılamaları . Kopyalanacak ve yapıştırılacak düz metin parçacıkları genellikle düzgün bir şekilde haksız bir şey yapmak için gerekli komut dizilerinden daha küçüktür. Kullanıcı ayrıca her satırı dikkatlice kopyalayıp yapıştırabilir, ne olduğunu anlar. Bir komut dosyasıyla, kullanıcı koda hiç bakmamış olabilir. Bu, imzalı komut dosyalarının 12'nci kez yapıldıktan sonra çok yaygın bir telafi maliyetiyle faydalı bir uygulaması olabilir.

* Daha fazla insan Linux kullanmaya başladıkça, bu muhtemelen giderek daha az gerçek oluyor

Sistemlerin farklı şekilde gelişmesinin nedeni, Linux'un 'exec' dosya özniteliğine sahip olması ve Windows'un yürütülebilirliği belirlemek için dosya uzantılarını kullanmasıdır.

Windows'da kullanıcıyı varsayılan olarak gizlenecek olan ".exe", ".bat", ".scr" uzantılı bir dosya indirmesi için kandırmak kolaydır . Bu dosyaya çift tıklamak size arbitary code (yürütme kodu) yürütülmesini sağlar. Bu nedenle, bu riski azaltmak için geniş bir menşe izleme ve yürütülebilir / kod imzalama mekanizması oluşturulmuştur.

Linux'ta, kullanıcıya bir dosya alabilirsiniz, ancak 'exec' bitinin kolayca ayarlanmasını zorlayamazsınız. Ayrıca, tüm dosya sistemlerini 'noexec' yapmak mümkündür.

Her durumda yorumlayıcıyı çağırarak bir komut dosyasını açıkça çalıştırabilirsiniz. Hatta çalışma zamanında kabuk komut dosyaları oluşturabilir ve bunları "sh" olarak işaretleyebilir veya "sh -c" çalıştırabilirsiniz.

Özel olarak, birçok arşivleme programı içerilen dosyalarda yürütme bitini korumaz. Bu, keyfi yürütülebilir dosyaları çalıştırmayı imkansız hale getirir. Neredeyse.

Mesele şu ki, başka bir cevapta, yürütme biti eksikliğinin böyle bir komut dosyasını doğrudan geçmenizi engellemediğidir bash. Bu tür komut dosyalarının çoğununbash komut , shebang herhangi bir programı tercüman olarak belirtebilir. Bu, yürütülebilir semantiği görmezden gelmeye karar verirlerse uygun tercümanı çalıştırmak kullanıcıya bağlıdır.

Bu çok fazla olmasa da, bu sadece çekirdek ve kabuk ile * nix'lerde güvenilmeyen yürütülebilir dosyalar çalıştırmanın önlenmesini kapsar .

Yorumlardan birinde bahsettiğim gibi SeLinux, bir dizi kurala göre dosyaların kökenini izleyen başka bir koruma katmanı var . Bir kurulum SeLinux, örneğin, dosyayı kopyalayıp hareket ettirseniz bile, kökün internetten indirilen yürütülebilir bit kümesiyle yürütülebilir bir dosya çalıştırmasına izin vermez. Bu tür dosyalar, sorunuzda bahsettiğinizin aksine, yalnızca imzayı kontrol edecek başka bir ikili dosyadan çalıştırılabilecek bir kural eklenebilir.

Sonuçta, bu genellikle önceden kurulmuş araçların konfigürasyonu ile ilgilidir ve cevap evettir .