Czy Ansible uniemożliwi wykonanie komendy „rm -rf /” w skrypcie powłoki

23

Jest to oparte na tym mistyfikacyjnym pytaniu tutaj. Opisany problem polega na posiadaniu skryptu bash, który zawiera coś takiego:

rm -rf {pattern1}/{pattern2}

... który, jeśli oba wzorce zawierają jeden lub więcej pustych elementów, rozwinie się do co najmniej jednej instancji rm -rf /, przy założeniu, że oryginalne polecenie zostało poprawnie przepisane, a OP wykonał interpretację nawiasów zamiast ekspansji parametrów .

W wyjaśnieniu OP dotyczącym mistyfikacji stwierdza:

Polecenie [...] jest nieszkodliwe, ale wydaje się, że prawie nikt tego nie zauważył.

Narzędzie Ansible zapobiega tym błędom, [...] ale [...] wydaje się, że nikt tego nie wie, w przeciwnym razie wiedziałby, że to, co opisałem, nie mogłoby się zdarzyć.

Zakładając, że masz skrypt powłoki, który wydaje rm -rf /polecenie poprzez rozwinięcie nawiasów lub rozszerzenie parametrów, czy to prawda, że ​​użycie Ansible uniemożliwi wykonanie tego polecenia, a jeśli tak, to w jaki sposób?

Czy wykonywanie rm -rf /z uprawnieniami administratora jest naprawdę „nieszkodliwe”, o ile używasz do tego Ansible?

linux bash ansible rm aroth
źródło
4
Zastanawiałem się, co zrobić z tym pytaniem, ale ostatecznie zdecydowałem się głosować i odpowiedzieć na nie, aby w końcu wprowadzić cały ten żałosny, absurdalny bałagan w przeszłość, do którego należy.
Michael Hampton
Myślę, że odpowiedź naprawdę leży w rmźródle, które przeanalizowałem poniżej.
Aaron Hall

Odpowiedzi:

54

Mam maszyny wirtualne, wysadźmy ich kilka! Dla nauki.

[root@diaf ~]# ansible --version
ansible 2.0.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Pierwsze podejscie:

[root@diaf ~]# cat killme.yml 
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      command: "rm -rf {x}/{y}"
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
ESTABLISH LOCAL CONNECTION FOR USER: root
localhost EXEC /bin/sh -c '( umask 22 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1461128819.56-86533871334374 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1461128819.56-86533871334374 `" )'
localhost PUT /tmp/tmprogfhZ TO /root/.ansible/tmp/ansible-tmp-1461128819.56-86533871334374/command
localhost EXEC /bin/sh -c 'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1461128819.56-86533871334374/command; rm -rf "/root/.ansible/tmp/ansible-tmp-1461128819.56-86533871334374/" > /dev/null 2>&1'
changed: [localhost] => {"changed": true, "cmd": ["rm", "-rf", "{x}/{y}"], "delta": "0:00:00.001844", "end": "2016-04-20 05:06:59.601868", "invocation": {"module_args": {"_raw_params": "rm -rf {x}/{y}", "_uses_shell": false, "chdir": null, "creates": null, "executable": null, "removes": null, "warn": true}, "module_name": "command"}, "rc": 0, "start": "2016-04-20 05:06:59.600024", "stderr": "", "stdout": "", "stdout_lines": [], "warnings": ["Consider using file module with state=absent rather than running rm"]}
 [WARNING]: Consider using file module with state=absent rather than running rm


PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=1    unreachable=0    failed=0

Ok, więc command po prostu przekazuje literały i nic się nie dzieje.

A może nasza ulubiona obwodnica bezpieczeństwa raw?

[root@diaf ~]# cat killme.yml
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      raw: "rm -rf {x}/{y}"
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
ESTABLISH LOCAL CONNECTION FOR USER: root
localhost EXEC rm -rf {x}/{y}
ok: [localhost] => {"changed": false, "invocation": {"module_args": {"_raw_params": "rm -rf {x}/{y}"}, "module_name": "raw"}, "rc": 0, "stderr": "", "stdout": "", "stdout_lines": []}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0

Nie idź ponownie! Jak trudne może być usunięcie wszystkich plików?

Och, ale co, jeśli byłyby to niezdefiniowane zmienne czy coś?

[root@diaf ~]# cat killme.yml
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      command: "rm -rf {{x}}/{{y}}"
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
fatal: [localhost]: FAILED! => {"failed": true, "msg": "'x' is undefined"}

NO MORE HOSTS LEFT *************************************************************
        to retry, use: --limit @killme.retry

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1

Cóż, to nie zadziałało.

Ale co, jeśli zmienne są zdefiniowane, ale puste?

[root@diaf ~]# cat killme.yml 
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      command: "rm -rf {{x}}/{{y}}"
  vars:
    x: ""
    y: ""
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
ESTABLISH LOCAL CONNECTION FOR USER: root
localhost EXEC /bin/sh -c '( umask 22 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1461129132.63-211170666238105 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1461129132.63-211170666238105 `" )'
localhost PUT /tmp/tmp78m3WM TO /root/.ansible/tmp/ansible-tmp-1461129132.63-211170666238105/command
localhost EXEC /bin/sh -c 'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1461129132.63-211170666238105/command; rm -rf "/root/.ansible/tmp/ansible-tmp-1461129132.63-211170666238105/" > /dev/null 2>&1'
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["rm", "-rf", "/"], "delta": "0:00:00.001740", "end": "2016-04-20 05:12:12.668616", "failed": true, "invocation": {"module_args": {"_raw_params": "rm -rf /", "_uses_shell": false, "chdir": null, "creates": null, "executable": null, "removes": null, "warn": true}, "module_name": "command"}, "rc": 1, "start": "2016-04-20 05:12:12.666876", "stderr": "rm: it is dangerous to operate recursively on ‘/’\nrm: use --no-preserve-root to override this failsafe", "stdout": "", "stdout_lines": [], "warnings": ["Consider using file module with state=absent rather than running rm"]}

NO MORE HOSTS LEFT *************************************************************
        to retry, use: --limit @killme.retry

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1

Wreszcie trochę postępu! Ale nadal narzeka, że ​​nie użyłem --no-preserve-root.

Oczywiście, również ostrzega mnie, że powinienem spróbować korzystania z filemodułu i state=absent. Zobaczmy, czy to zadziała.

[root@diaf ~]# cat killme.yml 
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      file: path="{{x}}/{{y}}" state=absent
  vars:
    x: ""
    y: ""
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml    
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
ESTABLISH LOCAL CONNECTION FOR USER: root
localhost EXEC /bin/sh -c '( umask 22 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1461129394.62-191828952911388 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1461129394.62-191828952911388 `" )'
localhost PUT /tmp/tmpUqLzyd TO /root/.ansible/tmp/ansible-tmp-1461129394.62-191828952911388/file
localhost EXEC /bin/sh -c 'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1461129394.62-191828952911388/file; rm -rf "/root/.ansible/tmp/ansible-tmp-1461129394.62-191828952911388/" > /dev/null 2>&1'
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "invocation": {"module_args": {"backup": null, "content": null, "delimiter": null, "diff_peek": null, "directory_mode": null, "follow": false, "force": false, "group": null, "mode": null, "original_basename": null, "owner": null, "path": "/", "recurse": false, "regexp": null, "remote_src": null, "selevel": null, "serole": null, "setype": null, "seuser": null, "src": null, "state": "absent", "validate": null}, "module_name": "file"}, "msg": "rmtree failed: [Errno 16] Device or resource busy: '/boot'"}

NO MORE HOSTS LEFT *************************************************************
        to retry, use: --limit @killme.retry

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1

Dobre wieści wszyscy! Zaczęło próbuje usunąć wszystkie moje pliki! Ale niestety wpadł w błąd. Zostawię naprawienie tego i nakłonienie playbooka do zniszczenia wszystkiego za pomocą filemodułu jako ćwiczenia dla czytelnika.

NIE uruchamiaj żadnych poradników, które zobaczysz poza tym punktem! Za chwilę zobaczysz dlaczego.

Wreszcie dla zamachu stanu ...

[root@diaf ~]# cat killme.yml
---
- hosts: localhost
  gather_facts: False
  tasks:
    - name: Die in a fire
      raw: "rm -rf {{x}}/{{y}}"
  vars:
    x: ""
    y: "*"
[root@diaf ~]# ansible-playbook -l localhost -vvv killme.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in killme.yml

PLAY ***************************************************************************

TASK [Die in a fire] ***********************************************************
task path: /root/killme.yml:5
ESTABLISH LOCAL CONNECTION FOR USER: root
localhost EXEC rm -rf /*
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ansible/executor/process/result.py", line 102, in run
  File "/usr/lib/python2.7/site-packages/ansible/executor/process/result.py", line 76, in _read_worker_result
  File "/usr/lib64/python2.7/multiprocessing/queues.py", line 117, in get
ImportError: No module named task_result

Ta VM jest byłą papugą !

Co ciekawe, powyższe nie pomogło nic zrobić commandzamiast raw. Po prostu wydrukował to samo ostrzeżenie o korzystaniu filez state=absent.

Powiem, że wygląda na to, że jeśli nie używasz rawtego, istnieje pewna ochrona przed rmodejściem amoka. Jednak nie powinieneś na tym polegać. Szybko przejrzałem kod Ansible i chociaż znalazłem ostrzeżenie, nie znalazłem niczego, co faktycznie powstrzymałoby uruchomienie rmpolecenia.

Michael Hampton
źródło
10
+1 do nauki. Dałbym +1 za nazwę hosta, ale byłoby to oszustwo; p /
Journeyman Geek
Wygląda na to, że możesz mieć zamontowany system plików /boot.
84104
1
@ 84104 Zabawne, że. Przez przypadek bootjest to pierwszy wpis w katalogu /. Więc żadne pliki nie zostały utracone.
Michael Hampton
5
@aroth Dokładnie! Ale, dla nauki, spróbuj rm -rf {{x}}/{{y}}kiedy yjest ustawiony na "*". --no-preserve-rootWyboru jest przydatna do tego, co to jest, ale to nie będzie cię z każdej możliwej sytuacji; łatwo to ominąć. Dlatego pytanie to nie zostało natychmiast uznane za mistyfikację: biorąc pod uwagę zły angielski i widoczne błędy składniowe, jest prawdopodobne .
Michael Hampton
1
Poza tym rawzły cronmoże być innym sposobem na zniszczenie systemu.
84104
3

Czy Ansible uniemożliwi wykonanie rm -rf /skryptu powłoki?

Sprawdziłem źródło rm coreutils , które ma następujące cechy :

  if (x.recursive && preserve_root)
    {
      static struct dev_ino dev_ino_buf;
      x.root_dev_ino = get_root_dev_ino (&dev_ino_buf);
      if (x.root_dev_ino == NULL)
        error (EXIT_FAILURE, errno, _("failed to get attributes of %s"),
               quoteaf ("/"));
    }

Jedynym sposobem na wyczyszczenie z katalogu głównego jest ominięcie tego bloku kodu. Z tego źródła :

struct dev_ino *
get_root_dev_ino (struct dev_ino *root_d_i)
{
  struct stat statbuf;
  if (lstat ("/", &statbuf))
    return NULL;
  root_d_i->st_ino = statbuf.st_ino;
  root_d_i->st_dev = statbuf.st_dev;
  return root_d_i;
}

Interpretuję to w ten sposób, że funkcja get_root_dev_inozwraca null /, a zatem rm kończy się niepowodzeniem.

Jedynym sposobem na ominięcie pierwszego bloku kodu (z rekurencją) jest posiadanie --no-preserve-rootgo i nie używa on zmiennej środowiskowej do zastąpienia, więc musiałby zostać jawnie przekazany do rm.

Wierzę, że to dowodzi, że chyba ansibl wyraźnie przechodzi --no-preserve-rootdo rm, to nie będzie to zrobić.

Wniosek

Nie wierzę, że Ansible wyraźnie zapobiega, rm -rf /ponieważ rmsam temu zapobiega.

Aaron Hall
źródło