> >A chroot or even just a separate user would seem to fix that problem, > >assuming they couldn't easily break out of it (probably not a safe > >assumption), but that still leaves many other issues, for example it > >would still be able to send network traffic originating from my machine, > >which would be extremely valuable to an attacker.
I run acrobat reader, firefox, and mail from remote machines on my LAN. I have the keys to all the boxes on my LAN on my "desktop" but none of those machines have keys to any other machine. Everything uses RSA pubkey auth only, no passwords. I'm not running these apps remotely for security reasons but I think it solves all the problems you mentioned. I use Solaris zones to isolate a lot of stuff and I can host shell accounts and occasional open source projects safely as far as I know. I would like to be able to offer OpenBSD shell accounts but I don't know how to do that safely without dedicating a machine to it so I haven't done it. I think there would be a lot of value in zones/jails on OpenBSD. Mostly zones are a superior solution to virtualbox/vmware etc. because they're very light and provide good isolation and resource control and make good overall use of the hardware. > >So what do you guys recommend? Should I just chroot a vm who's network > >traffic all goes through a local filter, and hope for the best? I'm > >really at a loss for what to do here. What is your threat model? If you can list the exact threats you want to defend against you will be in a better position to think about how to solve them. If you are struggling against generic FUD it's going to be harder. I don't think it's paranoia but you have to be specific about what you are worried about and understand how likely each attack is, how hard it is, and how hard to defend against. Everything in security (and life usually) is a tradeoff. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary / \ http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
