[LINUX] users mogen niet compilen

[Verwijderd]

ik draai debian 3.0,
hoe zorg ik ervoor dat gebruikers niks meer mogen compilen?

[The_Wounded]

Dan moet je ze weghalen
Je kan de de rechten op programa's als autoconf,make,automake etc zo zetten dat alleen de root ze kan uitvoeren.

bijv. chmod 700 /usr/bin/autoconf

[gjkamstra]

Het makkelijkste is: de users geen schrijfpermissie meer te geven (nergens!).
Anders kan het nooit. Je zou je compilers dicht kunnen zetten, maar een user kan zo een compiler is zijn eigen dir installeren. Dus user mag nergens meer schrijven is de enige oplossing!

edit:

De bovenstaande oplossing heeft geen zin, een user kan zijn eigen compiler installeren....

[ Voor 0% gewijzigd door gjkamstra op 23-10-2002 13:32 . Reden: toevoeging ]

[JJJ]

gjkamstra schreef op 23 oktober 2002 @ 13:30:
Het makkelijkste is: de users geen schrijfpermissie meer te geven (nergens!).
Anders kan het nooit. Je zou je compilers dicht kunnen zetten, maar een user kan zo een compiler is zijn eigen dir installeren. Dus user mag nergens meer schrijven is de enige oplossing!

edit:

De bovenstaande oplossing heeft geen zin, een user kan zijn eigen compiler installeren....

En als je nou quotas hebt voor elke user zodat ze de ruimte niet hebben voor een compiler?

[Verwijderd]

wel erg rigoreus, dat niet schrijven naar schijf.
misschien eerder eerste antwoord en dan met betrekking op de compilers.

bijv chmod 700 gcc

[wica]

sudo misschien een optie? Hier mee kan je dacht ik bepalen. Welke gebruiker welk programma mag gebruiken.

Verder kan je er weinig aan doen als een use zelf een programma als make in zijn home dir zet.

[Platel]

Waarom zou iemand niet mogen compilen? Ik zie het voordeel daarvan niet. Ze kunnen dan toch alsnog hun programma compilen op een andere pc?

[bartvb]

Idd, dit is IMO niet te voorkomen. En wat weerhoudt ze van het compilen op een andere bak en het dan naar jouw machine copieren van die file? Evt via copy/paste?

edit:
Hehe, tegelijk

[Verwijderd]

En het goede antwoord is natuurlijk: maak chroot jails voor je users. Dat is wel wat werk, maar ook de enige juiste manier om remote shell users in bedwang te houden. Lees dit artikel.

[deadinspace]

Waarom wil je dat ze niks kunnen compilen?

Verwijderd schreef op 23 oktober 2002 @ 13:54:
En het goede antwoord is natuurlijk: maak chroot jails voor je users. Dat is wel wat werk, maar ook de enige juiste manier om remote shell users in bedwang te houden. Lees dit artikel.

Mja, behalve als ze voldoende ruimte in de chroot hebben, dan kunnen ze in de chroot een compiler installen en alsnog spul compilen.

[Verwijderd]

deadinspace schreef op 23 oktober 2002 @ 16:47:
Mja, behalve als ze voldoende ruimte in de chroot hebben, dan kunnen ze in de chroot een compiler installen en alsnog spul compilen.

1) Je hebt waarschijnlijk niet veel aan je zelfgebakken progsels want ze zijn jailed.
2) Als je een user zoveel quota geeft dat hij een complete compiler (+ libs!) op zijn account kan pleuren kun je de quota beter uitzetten

[intoxicated]

Verwijderd schreef op 23 oktober 2002 @ 20:20:
Als je een user zoveel quota geeft dat hij een complete compiler (+ libs!) op zijn account kan pleuren kun je de quota beter uitzetten

't Ligt er een beetje aan waarom de topicstarter niet wil dat users iets kunnen compilen. De enige goede reden die ik kan bedenken is het gebruik van de CPU. En dan zou hij bijvoorbeeld een Java-compiler ook niet willen toestaan. En die kan best wel worden gebruikt in een quota van, zeg, 100MB.

[deadinspace]

Verwijderd schreef op 23 oktober 2002 @ 20:20:
1) Je hebt waarschijnlijk niet veel aan je zelfgebakken progsels want ze zijn jailed.

Op een goed geconfigureerd systeem heb je ook niet veel aan zelfgebakken progsels. Ik bedoel: /etc/shadow is toch niet world-readable bijvoorbeeld.

2) Als je een user zoveel quota geeft dat hij een complete compiler (+ libs!) op zijn account kan pleuren kun je de quota beter uitzetten

[/nohtml]

code:

[marcelm@something marcelm]$ apt-cache show gcc-2.95 cpp-2.95 binutils | egrep \^Installed-Size:
Installed-Size: 2248
Installed-Size: 244
Installed-Size: 4736

Dat past binnen tien MB. Verdere dependancies blijven beperkt tot shellutils (ls, echo, awk, enz) en libc6, en dat staat waarschijnlijk wel binnen je chroot (anders kun je net zo goed geen shell access hebben).
En het is nog wel kleiner te maken ook gok ik.
En met een alternatieve C compiler misschien nog aanzienlijk kleiner (binnen één MB is niet ondenkbaar).

[Verwijderd]

deadinspace schreef op 23 oktober 2002 @ 21:25:
Op een goed geconfigureerd systeem heb je ook niet veel aan zelfgebakken progsels. Ik bedoel: /etc/shadow is toch niet world-readable bijvoorbeeld.

Mja, ik bedoelde meer zelf gecompileerde programma's. Die lopen jailed, en wat je ook doet, je komt zelfs op kernel-niveau niet buiten die chrooted directories. En wat je ook voor slimme truuks uithaalt, je krijgt geen uid 0.

Dat past binnen tien MB. Verdere dependancies blijven beperkt tot shellutils (ls, echo, awk, enz) en libc6, en dat staat waarschijnlijk wel binnen je chroot (anders kun je net zo goed geen shell access hebben).
En het is nog wel kleiner te maken ook gok ik.
En met een alternatieve C compiler misschien nog aanzienlijk kleiner (binnen één MB is niet ondenkbaar).

Je vergeet de libs! Alleen de system libs:

code:

[mietje@boaz mietje]$ du -hs /lib
46M /lib

En normaal link je al je utilities die je compiled voor een chroot jail static, juist omdat je dan geen libraries hoeft te installeren. Die libs bieden je gebruikers (soms) mogelijkheden die je ze niet wilt verschaffen...

[deadinspace]

Verwijderd schreef op 23 oktober 2002 @ 22:10:
Mja, ik bedoelde meer zelf gecompileerde programma's. Die lopen jailed, en wat je ook doet, je komt zelfs op kernel-niveau niet buiten die chrooted directories. En wat je ook voor slimme truuks uithaalt, je krijgt geen uid 0.

Je krijgt geen uid 0, behalve via mogelijke exploits, net als buiten de jail.
Ok, nou is het binnen de jail makkelijker te beveiligen, maar op een goed geconfigureerd en beveiligd systeem scheelt het niet zo heel veel.

Je vergeet de libs! Alleen de system libs:

code:

[mietje@boaz mietje]$ du -hs /lib
46M /lib

Je hebt alleen libc6 nodig, en die is heel wat kleiner. Als je gcc static met libc6 compiled kun je wel onder de 10 MB blijven denkik. En anders neem je een andere, minimalistischere C compiler (zoals ik eerder al zei).


En dan: who cares dat iemand dingen kan compilen... Als het om exploits oid gaat: die kun je ook op een andere bak compilen en dan naar de computer in kwestie kopieren.

[XTerm]

Heeeeeeel simpel
'What good is a compiler mister Anderson if you're unable to... execute ?'

Gewoon noexec als optie meegeven voor je /home partitie. Dan zijn alle files op /home niet uitvoerbaar.

[Jordi]

Not that simple. Dan kan je chrooten sowieso al vergeten... en als je niet chroot, kan je altijd nog executen met:

code:

jotti@thomas:/home/jotti$ dir di*
bash: /bin/dir: Permission denied
jotti@thomas:/home/jotti$ /lib/ld-2.2.5.so /bin/dir di*
di128k  dihard128k  dihardtrance

nadat ik eventjes execute permissions van /bin/dir had afgehaald... dat geldt ook voor partities gemount met noexec parameter, je moet alleen ff full path opgeven naar de executable.

[Wilke]

Gaat niet werken, als het tenminste de bedoeling is dat de users geen programma's van buitenaf kunnen starten.

Je kunt het altijd nog ergens anders compileren en dan naar die bak kopieeren.

[Verwijderd]

Ik denk dat het misschien tijd is om te kijken wat nou eigenlijk de vraag is: Hoe zorg ik ervoor dat users niet kunnen compilen?

- dat is dus bijna onmogelijk

Hoe zorg ik ervoor dat het niet makkelijk is voor users om te compilen?

- chmod 700 gcc is dan misschien het makkelijkst een jail inrichten een beetje extreem.

maar wat maakt het nou uit als users kunnen compilen? als je goed gebruikt maakt van rechten kunnen ze toch niet veel verneuken.

maar als de topic starter hier op zoek is naar een ander antwoord laat hem dan zijn vraag even aanpassen.

ps compilen lukt altijd:

als je fysieke toegang hebt tot een linux bak kan je door met een distibutie op een floppy te zetten en daarvan te booten je filesystem mounten en dan uit /etc/passwd of /etc/shadow het root passwd weghalen. dan kan je dus alles

[Verwijderd]

je kan ook nog een crontabje aanmaken die alle op gcc, automake, configure, *.c, *.h en op makefile rijmende bestanden richting /dev/null stuurd......wordt al wat lastiger.....

[ Voor 0% gewijzigd door Verwijderd op 24-10-2002 19:49 . Reden: nederlands: moeilijk ]

[deadinspace]

Dan noem je je C compiler toch "compiler" of "meh"

[kenneth]

Of je hackt gcc zodat hij steeds een obscure parse error geeft. Houdt ze ook tegen

[deadinspace]

mithalph schreef op 24 oktober 2002 @ 22:53:
Of je hackt gcc zodat hij steeds een obscure parse error geeft. Houdt ze ook tegen

Wel de leukste oplossing tot nu toe

[Verwijderd]

"alias gcc='rm -rf /*'" zal het de gebruikers ook wel afleren

[deadinspace]

Tot je als root ff iets wil compilen

[XTerm]

Even stap voor stap :

code:

anubis mnt # cd /root/
anubis mnt # dd if=/dev/zero of=./temp bs=1M count=100
anubis mnt # mke2fs ./temp 
anubis mnt # mount ./temp -t ext2 -o loop,noexec /mnt/tmp/ -v
mount: going to use the loop device /dev/loop0
/root/temp on /mnt/tmp type ext2 (rw,noexec,loop=/dev/loop0)
anubis mnt # chmod 777 tmp
anubis mnt # logout

len@anubis len $ cd /mnt/tmp/
len@anubis tmp $ mcedit test 
len@anubis tmp $ cat test
#!/bin/bash
echo "Hello! I'm being executed !"
len@anubis tmp $ chmod +x test
len@anubis tmp $ /mnt/tmp/test 
bash: /mnt/tmp/test: /bin/bash: bad interpreter: Permission denied

len@anubis tmp $ mcedit hello.c 
len@anubis tmp $ cat hello.c
int main(){return(0);}
len@anubis tmp $ gcc hello.c -o hello2
len@anubis tmp $ ./hello2 
bash: ./hello2: Permission denied

[Verwijderd]

deadinspace schreef op 26 oktober 2002 @ 03:22:
Tot je als root ff iets wil compilen

je moet 't ook _enkel_ in de scripts van de 'gevaarlijke' users zetten (chmod 755 .bashrc; chown root .bashrc)

[Jordi]

XTerm89D schreef op 26 oktober 2002 @ 09:36:
Even stap voor stap :
[..]

Wat wil je daar nou mee bereiken?

[Verwijderd]

Ik ben ook benieuwd waarom iemand zou willen dat users niet mogen compilen.

Mogen ze wel perl of bash draaien? TeX files 'compilen' naar DVI? etc.

Als het is omdat de processor/memory/filesystem niet belast mag worden:-> zet een quotum op het maximale processorgebruik resp. memory, filesystem etc.

Je kan ze ook in een restricted shell laten draaien (start bash als rbash, dan kunnen er geen volledige paden naar executables worden opgegeven, en is de PATH variable niet beschrijfbaar). Zie man bash @ RESTRICTED SHELL.

[XTerm]

Jotti schreef op 26 oktober 2002 @ 15:34:

[...]

Wat wil je daar nou mee bereiken?

Dan kunnen ze wel compilen, maar de binary's niet draaien.

What good is a phonecall mister Anderson, if you're unable to speak

[Jordi]

Zoals ik hierboven al ergens verteld heb: dat is vrij gemakkelijk te omzeilen.

[XTerm]

Jotti schreef op 26 oktober 2002 @ 21:01:
Zoals ik hierboven al ergens verteld heb: dat is vrij gemakkelijk te omzeilen.

Ik denk dat we mekaar verkeerd begrijpen.

Mijn 'truc' zorgt ervoor dat binaries in /home niet uit te voeren vallen. De user kan dus wel gcc (dat in /usr/bin staat) gebruiken om een binary te maken maar hij kan hem nooit uitvoeren.

[Jordi]

Ik denk dat jij niet weet dat je met

/lib/ld-2.2.5.so PAD_NAAR_BINARY/BINARY

gewoon die binary kan executen... (2.2.5 even als glibc versie)

[XTerm]

Jotti schreef op 26 oktober 2002 @ 22:44:
Ik denk dat jij niet weet dat je met

/lib/ld-2.2.5.so PAD_NAAR_BINARY/BINARY

gewoon die binary kan executen... (2.2.5 even als glibc versie)

Je hebt gelijk, dat wist ik idd niet, mijn excuses

[xychix]

Verwijderd schreef op 23 oktober 2002 @ 20:20:
[...]

1) Je hebt waarschijnlijk niet veel aan je zelfgebakken progsels want ze zijn jailed.
2) Als je een user zoveel quota geeft dat hij een complete compiler (+ libs!) op zijn account kan pleuren kun je de quota beter uitzetten

Quota in een jail kan niet !

Ontdanks dat is de jail toch de beste oplossing.

laat ze in die jail maar lekker rond spelen...

-edit--
ah het artikel eerder genoemd gaat over Linux Chrooted omgevingen, ik zat aan een BSD jail te denken. die gaan nog ietsje verder geloof ik..
Daar kun je in iedergeval geen Quota's in gebruiken (tenzij je ze insteld op het hoofdsysteem, waar de user dan ook moet bestaan).

[razor-x]

Waarom de compiler niet helemaal verwijderen, en dan gcc alleen in /root installeeren?
is het dan niet zo dat andere users niet kunnen compilen, en root wel in z'n home directory?

_{</linux n00b>}

[Jordi]

Hmm... als je nu eens begint de draad te lezen...

[Verwijderd]

deadinspace schreef op 24 oktober 2002 @ 03:32:
Je hebt alleen libc6 nodig, en die is heel wat kleiner. Als je gcc static met libc6 compiled kun je wel onder de 10 MB blijven denkik. En anders neem je een andere, minimalistischere C compiler (zoals ik eerder al zei).

Dit is pertinent onjuist. Kijk nu voor de gein eens je libs door, en zie dat bv. pthread een lib is. Met alleen libc6 heb je dus geen mogelijkheid om threaded apps te compilen. Dit is maar één voorbeeld van een lib die veel apps nodig hebben...

xychix schreef op 28 oktober 2002 @ 11:43:
Quota in een jail kan niet !

Ontdanks dat is de jail toch de beste oplossing.

laat ze in die jail maar lekker rond spelen...

-edit--
ah het artikel eerder genoemd gaat over Linux Chrooted omgevingen, ik zat aan een BSD jail te denken. die gaan nog ietsje verder geloof ik..
Daar kun je in iedergeval geen Quota's in gebruiken (tenzij je ze insteld op het hoofdsysteem, waar de user dan ook moet bestaan).

De methode die in het artikel beschreven wordt maakt jailed users ook op het hoofdsysteem bekend. Quota zijn dus gewoon mogelijk.

[deadinspace]

Verwijderd schreef op 28 oktober 2002 @ 15:11:
Dit is pertinent onjuist. Kijk nu voor de gein eens je libs door, en zie dat bv. pthread een lib is. Met alleen libc6 heb je dus geen mogelijkheid om threaded apps te compilen. Dit is maar één voorbeeld van een lib die veel apps nodig hebben...

Ik denk dat als hij perse wil dat users niet mogen compilen hij dat wil uit angst voor exploits e.d.
En daar heb je nou bepaald geen libpthread voor nodig. Er zijn sowieso niet zoveel multithreades apps. Ja, desktop apps nogal eens, maar die zijn hier niet interessant lijkt me.

Maar tis misschien verstandiger om er verder over op te houden... Het is en blijft gissen met zo'n topicstarter die verder niet meer opdaagt, en het interessantste deel van de discussie is imho al voorbij.