[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Tor + SELinux sandbox = leak proof without VM overhead?
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Tor + SELinux sandbox = leak proof without VM overhead?
- From: coderman <coderman@xxxxxxxxx>
- Date: Sun, 29 Aug 2010 15:14:26 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Sun, 29 Aug 2010 18:15:16 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=dogf6pWBmJpOLgedA1HFDllbay2YbVPpzrizUFX1tXY=; b=RRXMIguVxbB42K5+8cDDRZ9waaI81AH3zQ8wv2GxuHVNZTkbLsBLtKQQ71I7b8HSW8 jt6u+i/rQK9nSc6yJPms8O75W01xUGod/6wdJ9RM2EBDIn0y9cSJU+Ag2ev2wp2ELEHm XV1mWkkD7IWMfOw9Xgeffvu74EV2b8WOHoxbk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sUF0iTfeYNnQsrz6unWbOgnz6Ya5wS7dRVcUG6wL7eD1FYEaQGwmZxpaWQwqWHVGTS hk66yi1XgcQt/KvqPFbuMbXypkLPbFWAGC50tDSqt+JzUaZqnqfI/zVtLZPzEuo1Iexy xCXxD/ZK0ytz+8dKljLshiJq9yZJT39LK/1Lk=
- In-reply-to: <8539tye5na.fsf@xxxxxxxx>
- References: <AANLkTika511+Ps71qdpZBOSxcv77bW3c1giVQkHu5Dx-@xxxxxxxxxxxxxx> <8539tye5na.fsf@xxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri <intrigeri@xxxxxxxx> wrote:
> ...
> Another "cost" mentioned by coderman was "elevated privs for
> accelerated virtualization / para-virtualization". AFAIK VirtualBox
> does not need any special privileges (once the kernel part of the
> software is installed, and the modules/services loaded).
the loading / configuring of kernel module part is one elevated task.
route table changes / altering iptables rules and chains*, many other
such things require elevated privileges.
there are often host facilities to permit specific use of valid
settings, and rsbac constraints, lots of other mitigation
techniques...
if you give up acceleration and do full softmmu / user only and
constrained device emulation you can still have a guest / least
privilege virtual machine, but the overhead is significant.
fortunately fast virtio devices are become common across both
userspace only and accelerated virtual machine implementations.
i also like livecd as you mention, and qubes on live fedora is a nice
setup, perhaps coupled with HTTPS-Fuse on-demand pre-caching file
system overlays... many many different combinations and techniques to
complement and fit a particular need. the limiting factor is time to
explore them all and their relative
strengths/weaknesses/trade-off's...
http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html
http://qubes-os.org/Architecture.html
* i call this out specifically because you need extend beyond the
basic VirtualBox / Qemu / VMWare settings associated with the common
bridge, nat, host-only network devices and implement host level
routing protections; otherwise you're exposed to a number of potential
side channel and other attacks listed in the FAQ and elsewhere.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/