[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [off-topic?] Chrooting ssh/telnet users?



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.



Reply to: