Komutları kullanarak 42FileChecker adlı belirli bir bash betiği kurmak istiyorum:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

Fakat 42FileChecker.sh'ın bilgisayarımda tuhaf şeyler yapıp yapmayacağını bilmiyorum çünkü acemi olduğumu ve o senaryoda neler olduğunu bilmiyorum. Sürücüleri biçimlendirmek gibi çılgınca bir şeyden kaçınmak için kukla bir terminalde veya kukla bir kök klasöründe veya bunun gibi bir şeyi çalıştırmanın bir yolu var mı? 42FileChecker.sh güvenli olsa bile gelecekteki kabuk komut dosyalarının kabukları test etmenin herhangi bir yolunu bilmek istiyorum.

Bu konuda uzman değilim ama straceve kullanmanızı tavsiye ederim docker.

Bu yüzden ilk önce bu cevabın talimatındaki gibi bir Docker kabı oluşturun . Ancak bu strace olarak eklenmesi, hangi sistem çağrıları yapıldığını size söyleyecektir. Veya alıntı yapmak için:

strace, Linux için bir tanılama, hata ayıklama ve eğitici kullanıcı alanı aracıdır. Sistem çağrıları, sinyal teslimatları ve işlem durumundaki değişiklikleri içeren işlemler ve Linux çekirdeği arasındaki etkileşimleri izlemek ve kurcalamak için kullanılır.

Bu komutları birleştirmek için kullanabilirsiniz.

docker exec -it ubuntu_container strace bash ./42FileChecker.sh

Bir betiğin ne yaptığından emin değilseniz, ne yaptığından emin olana kadar çalıştırmamanız daha iyi olur. Kötü bir komut dosyasının zarar yarıçapını azaltmanın yolları, yeni bir kullanıcı kullanarak çalıştırmayı, bir kapta çalıştırmayı veya sanal bir makinede çalıştırmayı içerir. Ancak bu ilk ifade hala geçerli: Bir şeyin ne yaptığından emin değilseniz, bunu yapana kadar çalıştırmamayı düşünün.

@Ctt'in dediği gibi, önce bir tür kum havuzunda çalıştırmak muhtemelen iyi bir fikirdir. Bir VM kullanmak muhtemelen en kolay çözümdür. Multipass oldukça basittir.

Çoklu pusulayı yükle (henüz yapmadığınızı varsayarak):

sudo snap install multipass --beta --classic

Yeni bir VM'yi döndür:

multipass launch --name myvm

Yeni sanal makinenize giriş yapın:

multipass shell myvm

Sonra betiğinizi çalıştırın (vm'inizin içinde):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

Katıldığınız okul senaryoları yayınladığında, endişelerinizi dile getirmenin en iyi yeri eğitmenlerinizle olur.

Bu, kodu satır satır bazında deşifre etmenize yardımcı olabileceğimizi söyledi. Buradaki herkes için tüm kodu analiz etmesi muhtemelen pratik değildir .

Toplamda 5,360 satırlık 40 bash betiğiniz var. Onları bir araya getirdim ve kötüye kullanılabilecek bash / shell komutlarını aradım. Hepsinin normal şekilde kullanıldığı görülüyor :

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$ 

• rm -rf /Tüm sabit disk bölümünü silmek için herhangi bir komut yoktur .
• sudoKomut dosyasını çalıştırmak için hiçbir gereksinim yoktur .
• Komut dosyası C, denetlenen dosyalarda yalnızca yetkili işlevlerin kullanıldığından emin olur .
• Bash / shell koduna hızlıca göz atmanın profesyonelce yazılmış ve takip etmesi kolay olduğunu gösteriyor.
• Birleştirilmiş kabukcheck kullanarak dosyalar sadece üç sözdizimi hatası ortaya koymaktadır.
• Yazar isimleri tanımlanmış ve ana yazarın resmi bile githubsayfasında.
• Hayatta hiçbir garanti olmamasına rağmen, 42FileCheckerkullanımı güvenli görünüyor.

Endişelenmen gereken insanca okunabilen bash scriptleri değil. Endişe kaynağı olan, okuyamayacağınız ikili nesneler derlenmiştir. Örneğin, "parlak zıplama küresi" olarak adlandırılan bir program ekranınızda böyle bir şeyi boyayabilir ancak arka planda tüm dosyalarınızı siliyor olabilir.

Orijinal cevap

Senaryo yazarına ne yaptığını sormak en iyisidir. Aslında, sorunuzu neredeyse yukarıda göründüğü gibi verbatim olarak gönderebilirsiniz.

Ayrıca yazara da sorun:

• Hangi dosyalar güncellendi?
• Elektrik kesintisi veya program hatası nedeniyle çökme meydana gelirse ne olur?
• Önce bir mini yedekleme yapılabilir mi?

Ve aklınıza gelebilecek diğer tüm güzel sorular.

Düzenleme 1 - Kötü niyetli bir yazar hakkında endişeler.

Yazılımı yalnızca çok sayıda iyi genel değerlendirme ile kullanmalısınız. Alternatif olarak burada güvendiğiniz yazarlar, Serge, Jacob, Colin King, vb. Gibi Ask Ubuntu'da. Ask Ubuntu ve saygın üyeleri gibi saygın diğer siteler de “zararlı olmayan” olarak kabul edilmelidir.

Buradaki “saygın yazarların” Ask Ubuntu’daki avantajı, “itibar puanları” ndaki kendi değerlerine güveniyor olmalarıdır. Eğer kasıtlı olarak "çalınan" veya "zarar görmüş" verilerin kodunu yazarlarsa, saygınlıklarını çabucak kaybederlerdi. Gerçekten de, yazarlar "modların gazabı" ndan acı çekebilir ve askıya alınabilir ve / veya 10.000 itibar puanına sahip olabilirler.

Düzen 2 - Tüm talimatları takip etme

Bash betiğinizin talimatlarını daha derinden inceledim:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

"Safe" yöntemi yalnızca ilk satırı çalıştırmaktır:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

Bu komut dosyalarını indirir ancak çalıştırmaz. Bir sonraki kullanımda nautilus(dosya yöneticisi) kurulu dizinleri ve dosyaları incelemek için. Çok çabuk keşfedersiniz, Fransa'da bir grup öğrenci tarafından yazılmış bir bash betiği koleksiyonu vardır.

Komut dosyalarının amacı, yanlış işlevler ve bellek sızıntıları için C programlarını derlemek ve test etmektir.

Docker'ı kullanabilirsiniz. Docker kapları, ana bilgisayar işletim sisteminden izole edilir; bu nedenle, herhangi bir kötü amaçlı etkinlik, özellikle bağlantı noktaları ileterek veya dosya sistemlerini bağlayarak çıkarmanıza izin vermediğiniz sürece, bir kap içinde kalır.

Liman işçisi yüklemek için:

sudo apt-get install docker.io

Yeni bir Ubuntu Biyonik kabı indirmek için:

docker pull ubuntu:bionic

Bundan sonra, kabın içine oturum açın

docker run -it ubuntu:bionic

ve içindeki tehlikeli işlemi gerçekleştirin:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

Komut dosyasını şu şekilde çalıştırarak hata ayıklama modunu kullanmayı düşünün:

$ bash -x scriptname

Daha fazla yararlı Bash bilgisi

Hata ayıklama modu, komut dosyasının kötü bir şey yapmasını engellemez, ancak komut satırından satır satır ilerlemenizi ve efektleri incelemenizi sağlar. Ayrıca senaryoyu bazı yaygın potansiyel hatalar ve / veya istismarlar için de kontrol edebilirsiniz, örneğin senaryoları herhangi bir şekilde araştırın rmve bu komutları yakından inceleyin. Bu araçların birçoğu onları denemek için yerleşik yardıma sahip, örneğin rm ihtiyacı, varsayılan olarak bir dizin silmez -r, -Rya --recursivebunu yapmak için bir seçenek.

Bu kalıplar için bir bash betiğini arayacak virüsten korumaya benzer bazı araçlar da olabilir, ancak hiçbir adı bilmiyorum. Örnek komut dosyalarınız, başka araçları indirecek şekilde fazladan iffy. Bu nedenle bunların her biri de incelenmeli. Hangi sunuculara temas ettiklerini kontrol etmek de faydalı olabilir.

Bir cevap vermek için gereken bilgiler şans eseri sadece sizin yorumunuzda bulunur:

Ecole 42 kursunda C öğreniyorum. Yaptığım fonksiyonların bu norme kontrolünden geçmesi gerekiyor. Bu norme kontrolü yapmak için 42FileChecker'ı Ubuntu'ya yüklemem gerekiyor.

Dolayısıyla durum pratikte dersi geçme seçeneğinizin olması veya kaynaklarınız üzerinde normatif kontroller yapmak için senaryoyu çalıştırmanız olabilir. Eğitmeninizle konuşmak, birincisi olmadığı için zor bir seçenektir (başka türlü bir seçenek olmazdı, hiçbir öğrenci prosedürlerini değiştiremez çünkü bir öğrenci ondan memnun değildir).
Bu yüzden bu senaryodaki olası hasarı sınırlamak için ne yapılması gerektiği sorusu ortaya çıkmaz. Büyük göğüsleri olan azgın bir kızın size e-postayla gönderildiği ve onun resmini görmek için kaçmanız gereken rastgele bir senaryo değil .
Bir programlama dersi yapıyorsun. Bubu senaryonun devreye girdiği yer. Soru, kursu başarıyla tamamlamak için çerçeve koşullarına uymak isteyip istemediğinizdir.

Ancak, gerçekten endişeleniyorsanız, senaryoyu bir kapta ya da sanal bir makinede çalıştırma ve kaynaklarınızı paylaşılan bir klasöre ya da kap / sanal makine tarafından maruz kalan bir ağ paylaşımına koyma olasılığı hala var. Bu tam paranoya yoluna gidiyor, ama sanallaştırma bugünlerde bu kadar karmaşık değil, bu yüzden çok pahalıya mal olmuyor.

O senaryoda yer alması pek olası olmayan bir istismar olasılığını engellemek, köklü olmayan herhangi bir kullanıcı olarak oturum açmak (Ubuntu'da başka türlü bir seçim yapmak zorunda kalmazsınız) ve sudoaçık bir neden olmadan yazmaktan kaçınmak Zaten olabilecek olan tüm kötü şeyler. Endişelendiğiniz sabit diski biçimlendirme gibi. Normal bir kullanıcı bunu yapamaz. En kötü şey, komut dosyası kullanıcının giriş dizinini silmesidir. Yani ne, sorun yok, gerçekten.