From owner-freebsd-questions@FreeBSD.ORG Wed Jun 3 10:27:24 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60DBF106567B for ; Wed, 3 Jun 2009 10:27:24 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 411498FC08 for ; Wed, 3 Jun 2009 10:27:23 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 985EE3540D; Wed, 3 Jun 2009 12:27:21 +0200 (CEST) Date: Wed, 3 Jun 2009 12:27:20 +0200 From: cpghost To: Wojciech Puchar Message-ID: <20090603102720.GB1349@phenom.cordula.ws> References: <4d3f56c90906020812t40c5fcbv178bcd7f702356f@mail.gmail.com> <4ad871310906020843n3e7dc96ap28d5d622e844abf1@mail.gmail.com> <20090603004914.73f40a60@gluon.draftnet> <20090603091800.GA1177@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-questions@freebsd.org Subject: Re: Open_Source X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:27:24 -0000 On Wed, Jun 03, 2009 at 11:24:02AM +0200, Wojciech Puchar wrote: > > secondarily and only when absolutely necessary with the usual > > firefox+noscript+abp... both browsers running in a virtual box (qemu, > > virtualbox) dedicated to this purpose and this purpose only. > > Exaggeration IMHO. just make sure your normal user has 700 permissions, > create another and run browser from it. What about permissions in X? Even if you started the browser as another user, you'd still have to xhost + that user. And from there, it's easy to hijack the X session (including keylogging etc.). So you'll start another Xorg process as the other user, but are you sure both processes are totally isolated and can't communicate via unix-domain sockets etc? Checked all perms of all devices, all FIFOs etc? The point is: if you start *any* untrusted program on your host OS, there's a remote possibility that you've overlooked something (your example with 0700 permissions for home dirs is a good example, but there's a lot more), and that the process starts seeing stuff it isn't meant to see. And even chroot(2) isn't perfect. Remember: http://unixwiz.net/techtips/chroot-practices.html http://wiki.netbsd.se/How_to_break_out_of_a_chroot_environment That's just the tip of the iceberg. You never know what's still lurking out there on the host OS, and when you need strong security, a virtualized environment for untrusted processes as a minimum is a *must-have*. And even then, that is risky, if the emulator or paravirtualizer contains bugs and flaws. You can get a little bit more confidence with virtualizers if emulated CPU arch != host CPU arch (e.g. when emulating PPC, 68000 or even more exotic processors on x86), but that's dog slow for modern day browsing even on fast machines. So it's not always practical to do so (though when security is paramount, browsing slowing may well be the price to pay). And obviously, the emulator sill needs to resist especially crafted bytecode that may crash it in a very specific way (read: an exploit of an emulator's bug)! > > Of course, I'm taking more precautions, as running in a box may still > > not be 100% secure, if someone creative enough found a way to break > > out of the guest OS into the host OS; but everything else is just > > Nobody would write specially prepared webpage exactly for You to break ;) That's right, and that's why non-Windows users are less exposed to the usual risks. But still, one has to be careful. > It's a matter of protecting yourself from "big brothers" that watch > others. Or from "little brothers" that explicitly target your infrastructure (think: industrial espionage etc.). Those attackers are much more worrying that your usual suspects, script kiddies et al., as contrary to the broad attackes of the latter, the former usually have more resources, including time, to conduct targeted penetration attempts into your secure environment. You see, security is more than just protecting the normal desktop user from vanilla attacks. ;-) -cpghost. -- Cordula's Web. http://www.cordula.ws/