Ik zie vaak op remote Linux-hosts dat een 'ps aux' alleen mijn eigen processen laat zien. Ik wil dit nu ook op een schoolserver realiseren, maar ik kon niet vinden hóe ik dat moest doen. Is het een kwestie van een conf aanpassen of moet ik de kernel opnieuw compileren met andere opties? (of evt een mod als vanilla?)
Ik dacht dat dit een van de mogelijkheden is van de grsecurity patches.
edit:
Kan het alleen zo snel niet vinden in de lijst met features op de site.
Kan het alleen zo snel niet vinden in de lijst met features op de site.
[ Voor 47% gewijzigd door _Squatt_ op 22-01-2004 20:55 ]
"He took a duck in the face at two hundred and fifty knots."
Het is dus alleen mogelijk als ik de kernel source patch en vervolgens compileer tot een nieuwe kernel? Geen config?
voorzover ik weet is dat inderdaad geen standaard functionaliteit, maar moet je dat met een patch realiseren.
Als je het met grsecurity wil doen wel ja, volgensmij zijn er verder geen (goede) mogelijkheden.
Trouwens, GrSecurity is volgensmij alleen voor 2.4.x kernels, weet iemand hoe dat met 2.6.x zit?
Trouwens, GrSecurity is volgensmij alleen voor 2.4.x kernels, weet iemand hoe dat met 2.6.x zit?
Verwijderd
Je kunt dit toch ook doen door een scriptje vooraan in de $PATH variabele te plaatsen (in /usr/local/bin bijvoorbeeld, dat komt bij mij eerder voorbij dan /bin ), dat bij aanroep als ps aux gaat uitvoeren:
/bin/ps aux | grep $USER
en bij elke andere aanroep uitvoert:
/bin/ps $1
Of denk ik nu te simpel?
/bin/ps aux | grep $USER
en bij elke andere aanroep uitvoert:
/bin/ps $1
Of denk ik nu te simpel?
JaVerwijderd schreef op 22 januari 2004 @ 21:33:
Je kunt dit toch ook doen door een scriptje vooraan in de $PATH variabele te plaatsen (in /usr/local/bin bijvoorbeeld, dat komt bij mij eerder voorbij dan /bin ), dat bij aanroep als ps aux gaat uitvoeren:
/bin/ps aux | grep $USER
en bij elke andere aanroep uitvoert:
/bin/ps $1
Of denk ik nu te simpel?
code:
1
| $ /bin/ps aux |
Dit soort dingen beveilig je op kernel niveau, vandaar dat er ook een kernel patch voor is... Best kans dat er iemand is die wel een redelekijke oplossing heeft zonder dat het nodig is de kernel te patchen, maar of het resultaat echt zo veilig is....
Verwijderd
Het is de bedoeling dat je onder geen beding kunt zien welke processen een ander heeft lopen?
Aha.
(ik heb niets gezegd)
Aha.
(ik heb niets gezegd)
[ Voor 12% gewijzigd door Verwijderd op 22-01-2004 22:08 ]
Tsja, wat je ook kunt doen is de sourcecode van ps aan passen en opnieuw compileren, maar in principe kan iedere ander user hetzelfde doen met niet aangepaste sources van ps en zo een weer goed werkende versie te krijgen.
Het enigste wat echt werkt is je kernel patchen met bijvoorbeeld grsecurity.
Het enigste wat echt werkt is je kernel patchen met bijvoorbeeld grsecurity.
Hoi,
Om complete afscherming te krijgen kun je volgens
mij beter user mode linux (UML) gaan draaien.
Je draait dan voor elke login een user mode linux kernel,
moet z'n eigen processen.
Om complete afscherming te krijgen kun je volgens
mij beter user mode linux (UML) gaan draaien.
Je draait dan voor elke login een user mode linux kernel,
moet z'n eigen processen.
Ware het niet dat UML een compleet andere distro is (tochRoccoD schreef op 22 januari 2004 @ 23:08:
Hoi,
Om complete afscherming te krijgen kun je volgens
mij beter user mode linux (UML) gaan draaien.
Je draait dan voor elke login een user mode linux kernel,
moet z'n eigen processen.
Grsecurity is duidelijk een betere optie omdat hierin nog veel meer security options zitten zoals het afschermen van /proc en het beter beveiligen van chroot-omgevingen
GrSecurity is zeer wel aan te raden, heb het zelf ook draaien hier en het werkt perfectow, en veilig uiteraard
If everything is working perfect, break something before someone else fucks up.
Nee, UML is geen distributie. Hier een stukje van de site (http://user-mode-linux.sourceforge.net):Ryceck schreef op 22 januari 2004 @ 23:31:
[...]
Ware het niet dat UML een compleet andere distro is (toch) waardoor de TS weer compleet moet overschakelen.
Grsecurity is duidelijk een betere optie omdat hierin nog veel meer security options zitten zoals het afschermen van /proc en het beter beveiligen van chroot-omgevingen
GrSecurity is zeer wel aan te raden, heb het zelf ook draaien hier en het werkt perfectow, en veilig uiteraard
Maar dan is GrSecurity denk ik wel weer makkelijk om te beheren e.d. (nog steeds niemand die weet hoe dat met 2.6.x zitUser-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.
Wij gebruiken grsecurity ook gewoon op shellservers en webservers (alles wat code kan executen wat niet van onszelf is krijgt grsecurity, zo simpel is dat), werkt perfect. Waar het op neer komt is dat er een ACL op /proc wordt toegekend, een normale user kan alleen de dingen in /proc zien die van hem zelf. In /proc worden onder meer dus ook alle processnummers opgeslagen.
Ik gebruik ook grsec op shellservers en merk juist op dat met wat creativiteit en perl je juist wel om de beveiliging heen kunt dmv /proc. Ik zie in 'w' en ps aux niks, maar in /proc volgens mij wel alle process-id's en informatie._JGC_ schreef op 22 januari 2004 @ 23:38:
Wij gebruiken grsecurity ook gewoon op shellservers en webservers (alles wat code kan executen wat niet van onszelf is krijgt grsecurity, zo simpel is dat), werkt perfect. Waar het op neer komt is dat er een ACL op /proc wordt toegekend, een normale user kan alleen de dingen in /proc zien die van hem zelf. In /proc worden onder meer dus ook alle processnummers opgeslagen.
offtopic:
Jij shellservers?
Waar werk je dan

Jij shellservers?
[ Voor 3% gewijzigd door jep op 23-01-2004 01:10 ]
Op grsecurity.net staat onder news dat ze er mee bezig zijn. Tevens is er op het forum aldaar een draadje te vinden over 2.6. Mijn ervaring is echter dat er pas officiele grsecurity patches komen voor een kernel als de mensen achter grsecurity die kernel rijp achten voor productie. Ik kan me herrineren dat er bij de 2.4 serie, al is dat natuurlijk niet het beste voorbeeld van een stable branch welke snel stable was, er pas grsecurity patches uitkwamen rond 2.4.3, echter werd 2.2.x toen nog aangeraden. Pas rond 2.4.16 raden ze aan om de 2.4 kernel te gebruiken.PowerSp00n schreef op 22 januari 2004 @ 23:35:
[...]
Maar dan is GrSecurity denk ik wel weer makkelijk om te beheren e.d. (nog steeds
niemand die weet hoe dat met 2.6.x zit)...
Jail je users, jailbox.sourceforge.net oid.
Als je ze jailed en je werkt met ACL kun je werkelijk alles fixen.
Indien je gebruikers veeleisend zijn is jailen niet de goeie oplossing, anders wel.
Als je ze jailed en je werkt met ACL kun je werkelijk alles fixen.
Indien je gebruikers veeleisend zijn is jailen niet de goeie oplossing, anders wel.
http://www.NUiPhone.nl/
Idd is /proc en ps output iets anders, maar wij hebben dus zowel die processboel aanstaan, als een ACL op /proc. Alleen root kan bij ons alles bekijken, users krijgen alleen te zien wat ze nodig hebben, zelfs /proc/cpuinfo is onzichtbaarjep schreef op 23 januari 2004 @ 01:10:
[...]
Ik gebruik ook grsec op shellservers en merk juist op dat met wat creativiteit en perl je juist wel om de beveiliging heen kunt dmv /proc. Ik zie in 'w' en ps aux niks, maar in /proc volgens mij wel alle process-id's en informatie.
offtopic:
Jij shellservers?Waar werk je dan
![]()
code:
1
2
3
4
5
6
7
8
9
10
11
| admin@cookie:/proc$ ls -la total 4 dr-xr-xr-x 44 root root 0 Jan 5 18:48 . drwxr-xr-x 20 root root 4096 Jan 9 09:05 .. dr-x------ 3 admin root 0 Jan 23 08:03 15654 dr-x------ 3 admin root 0 Jan 23 08:03 16723 dr-x------ 3 admin root 0 Jan 23 08:03 8044 dr-x------ 3 root root 0 Jan 23 08:03 bus -r-------- 1 root root 0 Jan 23 08:03 cmdline -r-------- 1 root root 0 Jan 23 08:03 cpuinfo ... |
Ik werk samen met Active2 een paar uren per week op de school waar we zitten, hebben hier 40 macs, een mac server, 3 terminal servers, de bijbehorende fileserver en een handvol webservers in beheer. Gaat best kan ik zo zeggen
Pagina: 1