On Wed, Jul 05, 2006 at 01:54:28AM +0000, Daniel W. Crompton wrote: > On 7/4/06, Baltasar Cevc <[EMAIL PROTECTED]> 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 > bytes > 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: > >>CAP_SYS_MODULE > >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 > >example. > Again I don't have it enabled, but again I've left the option for the > user. 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 :) HTC, Herbert > D. > > > blaze your trail > > -- > redhat > _______________________________________________ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver