At 1:02 Uhr +0200 27.10.2001, Javier Fern�ndez-Sanguino Pe�a wrote: > Umm... couldn't you have a restricted environment but with >commands hard-linked in it to the proper ones and restricting thoroughly >the hard links? (only rX, no w bits) The problem is how to do this >automatically (and not checking dynamic dependencies one by one...)
I've actually begun to write such a thing. Tough it seems I don't have enough time to finish it in the near future. What I've begun writing is a set of perl scripts that - allow to "sync" one file tree into another by creating hard links where possible (same filesystem, binary is not suid) or copy the file (and remove suid bits) if not. - script to parse strace output. -> you can run whatever you need in the chroot under strace, then let the script extract all files that have been opened. This way you get exactly which files are needed in the chroot. I've written this with a slightly different use of chroot in mind: the setup of "sandbox environments", where you (each user) can run things like ICQ clients that he doesn't trust to be secure enough (thus potential hacks being limited to the chroot), but under his userid (so he can save his files etc.) Alternatively you could define a set of binaries and write a script iterating over them with ldd to extract all libraries needed, of course. Well regarding sandbox I've also a script (wrapper aroung the executable you want to run in the sandbox) in mind that copies/links the Xauthentification cookie over to the chroot, but unlinks it again as soon as the executable is up and has opened the X connection -> if s.o. breaks in, he'll not be able to access the X session for key trapping etc. And there should be a script that checks whether there's a process running in the chroot before copying the X cookie over and if yes send it a SIGSTOP, to prevent a potential hacker daemon to open the X connection in the time frame where the cookie is there, and a SIGCONT after the cookie has been removed. If I only had enough time... BTW: I'm assuming that hard linked executables and libraries are loaded into RAM only once thus it doesn't create any overhead. Now I've heard that the linker is even able to detect when some library (?) has the (partially?) same content as another lib (or anything?) already loaded? Is this true? (If yes even copied libs wouldn't waste RAM, but I doubt it) Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
