On Wed, Jul 05, 2006 at 01:54:28AM +0000, Daniel W. Crompton wrote:
> On 7/4/06, Baltasar Cevc <email@example.com> wrote:
> >On 04.07.2006, at 10:29, Daniel W. Crompton wrote:
> >> You can, I just did it yesterday. You need to set the following in the
> >> file "bcapabilities":
> >> CAP_NET_ADMIN
> >> CAP_NET_RAW
> >I haven't tested it myself as I run OpenVPN in the host system only,
> >but I'd say that these caps are not nice to give to a guest, as far as
> >I know, you could more or less do any network operation (for any
> >interface) in the guest then.
> Obviously, you are giving the guest full access. Then again setting a
> routing on the guest is rather hard without CAP_NET_ADMIN, and as I
well, the real danger here is, inside the guest
(with CAP_NET_ADMIN), root can easily take your
host interface down and render all your guests
unuseable ... so use with caution :)
> wanted to be able to set the route from with in the guest I needed
> this on anyway.
> Also my vservers need to be portable over many systems so having too
> much host based configuration would make the transfer of a vserver
> from one host to another more difficult than sending vserver stop and
> start commands to the different hosts.
this could be easily solved with the various startup
and shutdown scripts (pre-pre, pre, post, post-post)
> On the security I can access the vpn from another unprivileged vserver
> on the same host:
> vhost-novpn ~# ping -I tap0 10.0.2.1
> vhost-vpn ~ # tcpdump -vv -i tap0
> tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 96
> 01:34:05.027723 arp who-has vpn-router tell vhost-novpn
> 01:34:06.027733 arp who-has vpn-router tell vhost-novpn
> 01:34:07.027757 arp who-has vpn-router tell vhost-novpn
> 3 packets captured
> 6 packets received by filter
> 0 packets dropped by kernel
> This makes any other vserver I run with or without CAP_NET_ADMIN a
> vserver with elevated rights, which mean just adding the tun/tap
> device is dangerous. And as tap is meant for the creation of raw
> ethernet frames this means, in principal, I would be able to send raw
> ethernet data to the remote host, that also means routing data.
you can as well create the tun/tap device as
persistant one on the host (when the guest is
started up) and 'just' use it inside the guest
(in which case you can remove all the caps)
> How secure is that?
no very secure :)
> >However, maybe, you will have to do this to get it working. I can't
> >remember any option that could make OpenVPN use an already existing
> >interface (I don't know how tun/tap work, thus whether that would be
> >feasible at all). It should be worth searching the OpenVPN and/or
> >kernel docs about that, though.
> That's what I did and I got exactly this answer. Unless anybody can
> tell me how to do it another way.
see above, and IIRC derjohn already tested that
in several configurations, so maybe you find some
info on his pages ...
> >Just quickly searching around, my understanding is that you have to
> >create the tun device on the host (which is what you want from a
> >security perspective). Afterwards you can assign it to a guest and
> >OpenVPN should be happy to use that one. However that seems to work
> >with tap, I assume it won't work using tun as a device.
> It should, both tun and tap come from the same module, where tap is
> slightly more powerful than tun.
one is layer 3 the other layer 2, except for that
there is no real difference in the 'powerfullness'
> >>Add if you want to load the module inside the vserver on access:
> >That would be quite crazy, I'd say. You could load anything, thus
> >provide the guest with any priviledge ever wanted...
> I'd have to agree there, I don't have it enabled.
and it is not required either, module loading
either happens 'on demand' and on the host, or
you simply preload the module
> >> Add if you want to mknod the device inside the vserver:
> >> CAP_MKNOD
> >Quite dangerous, too, as it enables you to access the whole HD for
> Again I don't have it enabled, but again I've left the option for the
giving CAP_MKNOD basically disables all the
isolation and allows guest root to mess with
the entire system, be careful here ...
> Anybody installing a vpn on their vserver then giving somebody they
> can't trust high level access to the vserver has just opened 2
> networks for attack. What disturbs me more is the fact that I can
> access the vpn from another vserver.
that is the least thing I'd worry about :)
> blaze your trail
> Vserver mailing list
Vserver mailing list
Received on Fri Jul 7 16:34:34 2006