kzen.dev
  • Întrebări
  • Tag-uri
  • Utilizatori
Notificări
Recompense
Înregistrare
După înregistrare, veți primi notificări despre răspunsurile și comentariile la întrebările DVS.
Logare
Dacă aveţi deja un cont, autentificaţi-vă pentru a verifica notificările noi.
Aici vor fi recompensele pentru întrebările, răspunsurile și comentariile adăugate sau modificate.
Mai mult
Sursă
Editează
Michael Mrozek
Michael Mrozek
Question

Permite suid pe shell script-uri

Anii `setuid permisiunea bit spune Linux pentru a rula un program cu efective id-ul de utilizator al proprietarului, în loc de executorul:

> cat setuid-test.c

#include <stdio.h>
#include <unistd.h>

int main(int argc, char** argv) {
    printf("%d", geteuid());
    return 0;
}

> gcc -o setuid-test setuid-test.c
> ./setuid-test

1000

> sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
> ./setuid-test

65534

Cu toate acestea, aceasta se aplică numai pentru executabile; shell script-uri ignora setuid pic:

> cat setuid-test2

#!/bin/bash
id -u

> ./setuid-test2

1000

> sudo chown nobody ./setuid-test2; sudo chmod +s ./setuid-test2
> ./setuid-test2

1000

Wikipedia spune:

Datorita risc crescut de defecte de securitate, mai multe sisteme de operare ignora setuid atribut atunci când este aplicat la executabil script-uri shell.

Presupunând că am'm dispuși să accepte aceste riscuri, nu există nici o modalitate de a spune Linux pentru a trata setuid cam la fel pe shell script-uri ca pe executabile?

Dacă nu, există o comună soluție pentru această problemă? Soluția mea actuală este de a adăuga o sudoers intrare pentru a permite "TOATE" pentru a rula un script ca utilizatorul eu vreau ca, cu NOPASSWD pentru a evita prompt parolă. Principalele dezavantaje este nevoie de o sudoers de intrare de fiecare dată când vreau să fac acest lucru, și aveți nevoie pentru a apelantului la sudo unele-script în loc de unele-script

188 2010-08-12T02:20:07+00:00 8
 codehead
codehead
Întrebarea editată 12 august 2010 в 3:08
Unix & Linux
scripting
shell
security
setuid
Gilles  &#39;SO- stop being evil
Gilles 'SO- stop being evil
8 octombrie 2010 в 8:18
2010-10-08T20:18:31+00:00
Mai mult
Sursă
Editează
#13851027

Linux ignoră setuid¹ cam pe toate interpretate executabile (de exemplu executabile care încep cu #! line). De comp.unix.întrebări FAQ explică problemele de securitate cu setuid script-uri shell. Aceste probleme sunt de două tipuri: tacâmul legate și shell-legate; intru în mai multe detalii mai jos. Dacă tu nu't pasă de securitate și doriți să permiteți setuid scripturi, sub Linux, ai'll nevoie pentru a patch-uri de kernel. Ca de 3.x kernel, cred că aveți nevoie să adăugați un apel la install_exec_creds în load_script funcția, înainte de apelul la open_exec, dar nu am't testat.

Setuid tacâmul

Există o cursă condiție inerentă pentru modul tacâmul (#!) este de obicei pus în aplicare:

  1. Kernel-ul deschide fișiere executabile, și constată că acesta începe cu #!.
  2. Kernel-ul se închide executabil și deschide interpret în loc.
  3. Kernel-ul introduce calea către script-ul la lista de argumente (ca argv[1]), și execută interpret. Dacă setuid script-uri sunt permise cu această punere în aplicare, un atacator poate invoca un arbitrar script prin a crea o legătură simbolică la un existent setuid script, executarea, și aranjarea de a schimba link-ul de după kernel-a efectuat pasul 1 și înainte de interpret devine în jurul valorii de la deschiderea primului argument. Pentru acest motiv, cel mai unices ignora setuid pic atunci când detectează o afacere. O modalitate de a asigura această aplicare ar fi pentru kernel-ul pentru a bloca fișierul script până interpretul a deschis-o (rețineți că acest lucru trebuie să împiedice nu numai deconectarea sau suprascrierea fișierului, dar, de asemenea, redenumirea orice director în cale). Dar sistemele unix tind să timid departe de obligatorie încuietori, și link-uri simbolice ar face o corecta caracteristica de blocare deosebit de dificil și invazive. Eu nu't cred că nimeni nu-l în acest fel. Câteva sisteme unix (în principal, OpenBSD, NetBSD și Mac OS X, toate care necesită un nucleu setare să fie activat) să pună în aplicare secure setuid tacâmul folosind o caracteristică suplimentară: calea /dev/fd/N se referă la fișierul deja deschis pe fișierul descriptor N (deci de deschidere /dev/fd/N este aproximativ echivalent cu dup(N)). Multe sisteme unix (inclusiv Linux) au /dev/fd dar nu setuid script-uri.
  4. Kernel-ul deschide fișiere executabile, și constată că acesta începe cu #!. Las's spun descriptorul de fișier pentru executabil este de 3.
  5. Kernel-ul deschide interpret.
  6. Kernel-ul insertii /dev/fd/3 lista de argumente (ca argv[1]), și execută interpret. Sven Mascheck's tacâmul pagina are o mulțime de informații pe tacâmul peste unices, inclusiv setuid suport.

    Setuid interpreți

    Las's presupunem tine'am reusit sa fac programul rula ca root, fie pentru că sistemul de OPERARE suportă setuid treaba sau pentru ca'am folosit un binar nativ înveliș (cum ar fi "sudo"). Ai deschis o gaură de securitate? Poate. Problema aici este nu despre interpretat vs elaborate programe. Problema este dacă runtime system se comportă în condiții de siguranță dacă este executată cu privilegii.

  • Orice legate dinamic nativ binar executabil este într-un fel a fost interpretat de dynamic loader (de exemplu /lib/ld.deci), care încarcă biblioteci dinamice cerute de program. Pe multe unices, puteți configura calea de căutare pentru biblioteci dinamice prin mediu (LD_LIBRARY_PATHeste un nume comun pentru variabila de mediu), și chiar încărca biblioteci suplimentare în toate executat binare (LD_PRELOAD). La invoker din programul poate executa cod arbitrar, în care programul de&#39;s context, prin plasarea unui special conceputlibc.atât de " în " $LD_LIBRARY_PATH(printre alte tactici). Toate sănătoasă sisteme ignoraLD*` variabile în setuid executabile.
  • În scoici cum ar fi sh, csh și instrumente financiare derivate, variabile de mediu devin automat shell parametri. Prin parametri, cum ar fi "CALE", "DACĂ", și multe altele, invoker de script-ul are multe oportunități de a executa cod arbitrar în scripturi shell's de context. Unele scoici stabilit aceste variabile de la normal, implicite în cazul în care detectează că scenariul a fost invocat cu privilegii, dar nu't știu că nu există nici o implementare particulară în care am încredere.
  • Cele mai multe medii runtime (dacă nativ, bytecode sau interpretate) au caracteristici similare. Puțini să ia măsuri speciale de precauție în setuid executabile, deși cei care rula nativ codul de multe ori nu't face orice crescator decât legarea dinamică (care nu ia măsuri de precauție).
  • Perl este o excepție notabilă. L susține explicit setuid script-uri într-un mod securizat. În fapt, scriptul poate rula setuid, chiar dacă sistemul de OPERARE a ignorat setuid pic pe scripturi. Acest lucru este pentru că perl nave cu un setuid root helper care efectuează verificările necesare și reinvokes interpretul dorită de script-uri cu dorit privilegii. Acest lucru este explicat în perlsec manual. Este folosit pentru a fi că setuid perl script-uri necesare #!/usr/bin/suidperl -wT "în loc de"#! /usr/bin/perl-wT, dar pe cele mai multe sisteme moderne, #!/usr/bin/perl-wT este suficient. Rețineți că, folosind un binar nativ wrapper nu face nimic în sine, pentru a preveni aceste probleme. În fapt, se poate face situația rău, pentru că s-ar putea preveni runtime environment de la detectarea că este invocat cu privilegii și ocolind sale de execuție configurabilitate. Un binar nativ wrapper poate face un script de shell în siguranță dacă ambalajul igienizează mediu. Script-ul trebuie să aibă grijă să nu facă prea multe ipoteze (de exemplu, despre directorul curent), dar merge. Puteți folosi sudo pentru acest lucru, cu condiția ca acesta's înființat pentru igienizarea mediului. Pe lista neagră variabile este predispusă la erori, astfel încât întotdeauna albă. Cu sudo, asigurați-vă că env_reset opțiune este activată, că setenv este oprit, și că env_file " și " env_keep conține numai inofensive variabile.

    TL,DR:

  • Setuid tacâmul este nesigur, dar, de obicei, ignorate.
  • Dacă executați un program cu privilegii (fie prin sudo sau suid), scrie cod nativ sau perl, sau de a începe programul cu un înveliș care igienizează mediu (cum ar fi sudo cu env_reset opțiune). ¹ Această discuție se aplică în mod egal dacă ai înlocui "setgid" pentru "setuid"; ambele sunt ignorate de către kernel-ul Linux pe scripturi
Stephen Kitt
Stephen Kitt
Răspuns editat 30 noiembrie 2018 в 3:55
205
0
 Hemant
Hemant
12 august 2010 в 5:20
2010-08-12T05:20:21+00:00
Mai mult
Sursă
Editează
#13851023

O modalitate de a rezolva această problemă este de a apela shell script-ul de la un program care poate folosi setuid pic. ceva cum ar fi sudo. De exemplu, aici este modul în care ar realiza acest lucru într-un program C:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
    setuid( 0 );   // you can set it at run time also
    system( "/home/pubuntu/setuid-test2.sh" );
    return 0;
 }

Salvați-l ca suid-test2.c. compila Acum face suid pe acest program binar:

su - nobody   
[enter password]  
chown nobody:nobody a.out  
chmod 4755 a.out  

Acum, ar trebui să fie capabil să-l rulați, și te'll vedea script-ul a fost executat cu nimeni permisiuni. Dar aici, de asemenea, fie aveți nevoie pentru a hardcode script drumul sau trece-l ca linie de comandă arg de mai sus exe.

 muru
muru
Răspuns editat 22 mai 2015 в 10:13
56
0
 rcrowley
rcrowley
18 august 2010 в 1:53
2010-08-18T01:53:51+00:00
Mai mult
Sursă
Editează
#13851026

Am prefix câteva script-uri care sunt în această barcă astfel:

#!/bin/sh
[ "root" != "$USER" ] && exec sudo $0 "$@"

Rețineți că acest lucru nu folosesc setuid` ci pur și simplu execută fișierul curent cu "sudo".

 Luc
Luc
Răspuns editat 13 decembrie 2018 в 8:25
23
0
Maciej Piechotka
Maciej Piechotka
17 august 2010 в 11:04
2010-08-17T11:04:20+00:00
Mai mult
Sursă
Editează
#13851025

Dacă doriți, pentru a evita apelarea sudo some_script puteți face:

  #!/ust/bin/env sh

  sudo /usr/local/scripts/your_script

SETUID programe trebuie să fie proiectat cu o deosebită grijă ca ei rula cu privilegii de root, iar utilizatorii au control mare asupra lor. Ei au nevoie de bun-simț verifica totul. Nu se poate face cu script-uri, deoarece:

  • Scoici sunt bucăți mari de software care interacționează puternic cu utilizatorul. Este aproape imposibil de bun-simț verifica totul — mai ales că cele mai multe din cod nu este destinat pentru a rula în astfel de modul.
  • Script-uri sunt cea mai rapid'n'murdar soluție și, de obicei, nu sunt pregătite cu atâta grijă pe care le-ar permite setuid. Ei au multe caracteristici potențial periculoase.
  • Ei depind în mare măsură de alte programe. Nu este suficient ca shell a fost verificat. sed, awk, etc. ar trebui să fie verificate, precum și

Vă rugăm să rețineți că "sudo" oferă un bun-simț-verificare dar e't suficient — verifica fiecare linie în propriul cod.

Ca o ultimă notă: luați în considerare utilizarea capacităților. Acestea vă permit să dea un proces care rulează ca un utilizator privilegii speciale care în mod normal ar avea nevoie de privilegii de root. Cu toate acestea, de exemplu, în timp ce "ping" trebuie să manipuleze rețea, aceasta nu trebuie să aibă acces la fișiere. Am'm nu sunt sigur cu toate acestea, dacă acestea sunt moștenite.

12
0
 wzzrd
wzzrd
12 august 2010 в 6:38
2010-08-12T06:38:19+00:00
Mai mult
Sursă
Editează
#13851024

Puteți crea un alias pentru sudo + numele de script-ul. Desigur, că este chiar mai mult de lucru pentru a configura, deoarece atunci aveți pentru a configura un alias, de asemenea, dar vă salvează de la a fi nevoie să introduceți sudo.

Dar dacă nu't mintea oribil riscuri de securitate, utilizați un setuid shell ca interpret pentru shell script. Don't știu dacă asta'll de lucru pentru tine, dar cred că s-ar putea.

Permiteți-mi să declar că am sfătui împotriva fapt, a face acest lucru, deși. Am'm a menționat doar pentru scopuri educaționale ;-)

4
0
Nizam Mohamed
Nizam Mohamed
27 ianuarie 2015 в 6:01
2015-01-27T06:01:37+00:00
Mai mult
Sursă
Editează
#13851028

super [ -r reqpath] comanda [ argumente ]

Super vă permite specificate de utilizatori pentru a executa script-uri (sau alte comenzi), ca daca au rădăcină; sau se poate seta uid, gid, și/sau suplimentare grupuri pe baza de comanda înainte de a executa comanda. Acesta este destinat a fi o alternativă sigură, pentru a face script-uri setuid root. Super, de asemenea, permite utilizatorilor obișnuiți să furnizeze comenzi pentru executarea de către alții; aceste executa cu uid, gid, și grupuri de utilizator, oferind comanda.

Super consultă un `super.tab'' de fișier pentru a vedea dacă utilizatorul este permis să execute comanda solicitată. Dacă permisiunea este acordată, super va exec pgm [ args ], unde pgm este un program care este asociat cu această comandă. (Root este permisă executarea în mod implicit, dar poate fi refuzat în cazul în care o regulă exclude rădăcină. Utilizatorii obișnuiți sunt nepermis de execuție în mod implicit.)

Dacă comanda este o legătură simbolică (sau hard-link-ul, de asemenea) la super program, apoi tastați % comanda args este echivalent cu tastarea % super comanda args (comanda nu trebuie să fie super sau super nu va recunoaște că l's fi invocată prin intermediul unui link.)

http://www.ucolick.org/~va/RUE/super/README

http://manpages.ubuntu.com/manpages/utopic/en/man1/super.1.html

Nizam Mohamed
Nizam Mohamed
Răspuns editat 31 ianuarie 2015 в 7:25
4
0
 Chris
Chris
30 ianuarie 2019 в 11:46
2019-01-30T11:46:59+00:00
Mai mult
Sursă
Editează
#13851030

Dacă pentru un motiv oarecare "sudo" nu este disponibil, puteți scrie un înveliș subțire script-ul in C:

#include <unistd.h>
int main() {
    setuid(0);
    execle("/bin/bash","bash","/full/path/to/script",(char*) NULL,(char*) NULL);
}

Și odată ce-l compilați-l setați ca setuid " cu " chmod 4511 wrapper_script.

Acest lucru este similar cu un alt răspuns postat, dar ruleaza script-ul cu un mediu curat și folosește explicit /bin/bash în loc de coajă numit de sistem()`, și astfel se închide un potențial de gauri de securitate.

Rețineți că această capturilor aruncate înapoi în mare mediu în întregime. Dacă doriți să utilizați unele variabile de mediu, fără a deschide vulnerabilități, chiar ai nevoie doar de a folosi "sudo".

Evident, vrei să asigurați-vă că script-ul în sine este numai scris de rădăcină.

Dave Billington
Dave Billington
Răspuns editat 10 aprilie 2019 в 4:52
2
0
Theodore  R. Smith
Theodore R. Smith
8 iunie 2016 в 6:58
2016-06-08T18:58:34+00:00
Mai mult
Sursă
Editează
#13851029

Am găsit pentru prima dată această întrebare, convins de toate răspunsurile, aici este una mult mai buna, care, de asemenea, vă permite să complet obfuscate ta script bash, dacă sunteți atât de înclinat!

Ar trebui să fie auto-explicative.

#include <string>
#include <unistd.h>

template <typename T, typename U>
T &replace (
          T &str, 
    const U &from, 
    const U &to)
{
    size_t pos;
    size_t offset = 0;
    const size_t increment = to.size();

    while ((pos = str.find(from, offset)) != T::npos)
    {
        str.replace(pos, from.size(), to);
        offset = pos + increment;
    }

    return str;
}

int main(int argc, char* argv[])
{
    // Set UUID to root
    setuid(0);

    std::string script = 
R"(#!/bin/bash
whoami
echo $1
)";

    // Escape single quotes.
    replace(script, std::string("'"), std::string("'\"'\"'"));

    std::string command;
    command = command + "bash -c '" + script + "'"; 

    // Append the command line arguments.
    for (int a = 0; a < argc; ++a)
    {
        command = command + " " + argv[a];
    }

    return system(command.c_str());
}

Apoi fugi

g++ embedded.cpp -o embedded
sudo chown root embedded
sudo chmod u+s embedded
 HalosGhost
HalosGhost
Răspuns editat 19 august 2016 в 4:08
-3
0
Comunități asemănătoare 1
DevOps - comunitatea Română
DevOps - comunitatea Română
15 utilizatori
Vorbim despre Kubernetes, CI/CD, Linux, docker, monitorizare, Cloud services, Prometheus, network și orice alte teme legate de administrarea serverelor.
Deschide telegram
Adăugati o întrebare
Categorii
Toate
Tehnologii
Cultură
Viață / Artă
Stiință
Profesii
Afaceri
Utilizatori
Toate
Nou
Populare
1
Daniel Gogov
Înregistrat 2 zile în urmă
2
工藤 芳則
Înregistrat 1 săptămână în urmă
3
Ирина Беляева
Înregistrat 1 săptămână în urmă
4
Darya Arsenyeva
Înregistrat 2 săptămâni în urmă
5
anyta nuam-nuam (LapuSiK)
Înregistrat 2 săptămâni în urmă
ES
ID
JA
KO
RO
RU
© kzen.dev 2023
Sursă
unix.stackexchange.com
în cadrul licenței cc by-sa 3.0 cu atribuire