Vulnerability Development mailing list archives
Re: Controlling a program's resource usage on Unix
From: matej () POBOX SK (Matej Kovac)
Date: Mon, 17 Apr 2000 09:27:55 +0200
On Sun, Apr 16, 2000 at 11:37:12AM -0400, Bernie Cosell wrote:
What I'd like to do is be able to run an _arbitrary_ program and limit what it can do.
...<SNIP>... Do you know project Medusa? It's a kernel patch and security daemon, providing (hopefuly) everythig you need for limiting programs' resource usage during its run. The concept is extreemly simple - kernel always asks the security daemon what to do, on any event. The events are ranging from inode access (creation, (sym|hard|un)linking, mkdir, rename, permissions...) to watching system calls of a certain process... What everything you can do with file/inode control? If somebody executes 'passwd', medusa redirects this access into /usr/games/foobar, but only if the UID is X or Y. Or you can reduce root's (or cracker's:() privileges as well, simply by setting a rule that says: any attempt to remove the /etc/shadow fails (wow, medusa can ignore unlink request and inform the 'rm' that everything is done and there is no more any /etc/shadow...) - or you can redirect access to shadow and passwd files to their clones if the user is logged from the net - having different passwords on console and differend from the net. And what you can do by tracing syscalls for certain programs? Trace just certain syscals (such as setuid), of certain programs, and only if the user is logged in from the 'unsafe' IP address... and you precisely know who the user is (the original user logged in, not the current UID, but the original one). To return to the original subject - raised by 'history files' thread I believe... here is a rule for security daemon that makes the .bash_history files unreadable, undeletable and append only for any user except the root: for unlink "/home/USERNAME/.bash_history" { if( luid == 0 ) return MED_YES; // permit operation log "user " uid " wishes to hide from you by deletting the .bash_history"; return MED_OK; // say that all is done, but don't unlink! } for truncate "/home/USERNAME/.bash_history" { // copy everything from unlink... } Do the same for rename, for link (link = hardlink here.). To disable any posibility to change permissions, do the for permission as well. The 'luid' is original user id - 0 even if it is root - right now after the 'su' command, or is still 99 after executing an xterm utilizing the (very old) wwwcount hole and compromising root via any setuid overflow... And now just a short question... who is not thinking of restricting access to all the /var/log/* now...? ahh... http://medusa.fornax.sk/ Matej Kovac matej () pobox sk
Current thread:
- Re: History Files, (continued)
- Re: History Files audit (Apr 15)
- Re: History Files Blue Boar (Apr 15)
- Re: History Files Carson Gaspar (Apr 15)
- limited functionality accounts (was: Re: History Files) Marc Slemko (Apr 16)
- Re: limited functionality accounts (was: Re: History Files) Seth R Arnold (Apr 16)
- Re: limited functionality accounts (was: Re: History Files) Einar Indridason (Apr 26)
- Controlling a program's resource usage on Unix Bernie Cosell (Apr 16)
- Re: Controlling a program's resource usage on Unix Seth R Arnold (Apr 16)
- Re: Controlling a program's resource usage on Unix Isaac (Apr 21)
- Re: Controlling a program's resource usage on Unix Crispin Cowan (Apr 16)
- Re: Controlling a program's resource usage on Unix Matej Kovac (Apr 17)
- Re: Controlling a program's resource usage on Unix Pavel Kankovsky (Apr 18)
- Re: History Files David Taylor (Apr 16)
- Re: History Files Boris Sagadin (Apr 17)
- Fwd: RAZOR Analysis of dvwssr.dll Blue Boar (Apr 17)
- Re: History Files iconoclast (Apr 18)
- Re: History Files Bluefish (Apr 19)
- Re: History Files Crispin Cowan (Apr 15)