Continue from bug#118435. Roy Marples <uberlord@gentoo.org> >> Please reopen this bug so we and other users can keep track of it. > Please open a new bug as the initial bug has been fixed - 2.1 is in portage. Done. Although I don't understand why you need a new bug. The initial checkin does not say the version bump is correct. >> I see you have not not removed the smartcard use yet. >It's been removed now. The --enable-pcks11 configure flag is used when the >minimal USE flag is not used. No... You got it backwords... You need --disable-pkcs11 on minimal. PKCS#11 is enabled by default. >> And when tested the baselayout integration I found that it does not work >> properly... It overwrites the /etc/resolv.conf and not just adds a new entries >> as expected. And when tunnel disconnects it does not return old definitions. > Well, either provide a patch or emerge resolvconf-gentoo which will manage > resolv.conf for you. I expected a response, thank you for finding this.... I will see how to solve it, or I will add resolvconf-gentoo dependency to the ebuild. If the new baselayout integration creates problems, revert it or solve it. Don't expect others to fix your initial work. Looking at it... You just need to >> /etc/resolv.conf the DNS instead of overwrite it... And on down replace the /etc/resolv.conf with active interface DNS. >> Also dropping privileges is important! >> Please support it by modifying the up/down script - checking if uid/gid is not >> 0 then sudo self. > Not going to happen for a few reasons OpenVPN is a SECURITY PRODUCT every security feature is important, it is there for a reason. Don't underest the effort of putting this together for users. > 1) We would have to depend on sudo (which I don't like) You don't HAVE TO... If user want dropping privileges he will emerge sudo and add the required command to sudoers. If user doesn't want to use this feature it will work without sudo as root. Add the something similar to the following to your scripts header: if [ `id -n` != 0 ]; then exec sudo $0 $* exit 1 fi > 2) openvpn cannot change ip or route setup once privs are dropped This is solved using: persist-tun persist-local-ip You already force them. Now... Since you use command-line arguments you override the openvpn configuration settings... people cannot use their own scripts in order to sudo and override yours. So please add the sudo stuff to allow users not to patch your scripts. Forsing persist-tun will be bad for some people since it does not release the routing entries on tunnel disconnect... So if you come to your office you cannot reach your network. Please rethink of forcing persist-tun persist-local-ip to all users.
This is a bug. Not a feature request.
Dear Jakub, You may write a reason for your doings. The fact that the DNS is overwritten is a BUG. Do you want me to open another bug for the sudo? If you do, I will. But let's follow what happened so far... A gentoo developer added a new ebuild to portage... This ebuild was not written in a great quality... Now every change in it should be filed as a separate bug... And to make things harder.... Marked as enhancement. What next? Adding the following to portage? openvpn-2.1_beta15: # This empty ebuild was added so people will tell me what to do # please suggest what should I do here....
Stop producing needless noise on this bug, please.
(In reply to comment #0) > >It's been removed now. The --enable-pcks11 configure flag is used when the > >minimal USE flag is not used. > No... You got it backwords... > You need --disable-pkcs11 on minimal. > PKCS#11 is enabled by default. Fixed. > I expected a response, thank you for finding this.... I will see how to solve > it, or I will add resolvconf-gentoo dependency to the ebuild. > If the new baselayout integration creates problems, revert it or solve it. > Don't expect others to fix your initial work. There is no integration problem I am currently aware of. > Looking at it... You just need to >> /etc/resolv.conf the DNS instead of > overwrite it... And on down replace the /etc/resolv.conf with active interface > DNS. No. We provide resolvconf - it's the only acceptable solution. Say that you have 2 nics in a laptop, one wired and one wireless both using dhcp. Now use openvpn on top of that. They all compete for /etc/resolv.conf - resolvconf is the answer. It's also an optional runtime dependency - it's used if available. Just like pkcs#11. I'll address your other comments later.
(In reply to comment #2) > But let's follow what happened so far... A gentoo developer added a new ebuild > to portage... > This ebuild was not written in a great quality... I take offense to that. I'd also like to know what you find wrong with it - from a pure code quality perspective it passes all our most stringent QA tests. Maybe you can tell me what is wrong with it? Just to be clear, focus all comments on the ebuild with the header openvpn-2.1_beta14.ebuild,v 1.3 2006/05/10 20:23:41 > Now every > change in it should be filed as a separate bug... No, we only ask that seperate issues are seperate bugs. There are 3 "bugs" in this bug report, one which is already fixed. > And to make things harder.... What's hard is trying to keep track of bugs, new and old in bugs. Small concise bug reports are much easier to work with. Instead this big bad bug report will stay open until all are fixed. So you've made closing this bug harder by making its scope big. Thanks! Now that we've gotten this off our chests lets try and agree some things. 1) the resolv.conf issue is probably not going to change - currently openvpn manages /etc/resolv.conf like every other dhcp client in portage and they all support resolvconf. 2) You have some issues with the init script. Maybe it would be best if we dropped the persist options by default and let the user put them into their config files? 3) The user has the choice of dropping privs, I see no reason to make this default. IP address, subnet, resolv.conf - all could change and that all needs route. re-entering the up/down.sh scripts with a sudo call is a good idea though - I shall look into testing this.
(In reply to comment #4) >> PKCS#11 is enabled by default. > Fixed. Thanks! > There is no integration problem I am currently aware of. Just that after connection people will not have a DNS server to work with. So no connection to internet sites... > We provide resolvconf - it's the only acceptable solution. Say that you have 2 > nics in a laptop, one wired and one wireless both using dhcp. Now use openvpn > on top of that. They all compete for /etc/resolv.conf - resolvconf is the > answer. It's also an optional runtime dependency - it's used if available. Just > like pkcs#11. It cannot be optional if it damanged the user! It is not the same of two dhcp cards, since dhcp will likely to provide DNS server address, where VPN server will not. (In reply to comment #5) > > But let's follow what happened so far... A gentoo developer added a new ebuild > > to portage... > > This ebuild was not written in a great quality... > > I take offense to that. I'd also like to know what you find wrong with it - > from a pure code quality perspective it passes all our most stringent QA tests. > Maybe you can tell me what is wrong with it? Yes. 1. It overwrites people resolv.conf when it is only optional configuration element in VPN server. Most people will find themselves without any DNS server after VPN connect. 2. It had wrong dependency. 3. It dropped an imporant security feature (dropping privileges) from a security oriented product. 4. It uses persist stuff that will require people to have root privileges when arriving home office. I don't call this a good QA. > Just to be clear, focus all comments on the ebuild with the header > openvpn-2.1_beta14.ebuild,v 1.3 2006/05/10 20:23:41 No. I focus on the original check-in when I filed my initial comments, since you closed the bug of adding the 2.1_beta14 into portage. This where I think you got it wrong... bug#118435 should not have been closed until all issues are fixed. > > Now every > > change in it should be filed as a separate bug... > > No, we only ask that seperate issues are seperate bugs. There are 3 "bugs" in > this bug report, one which is already fixed. No... There is a huge difference between incremental fixing of a software component, in which I agree - every issue is a separate bug. And initial write of a component, as you did in this openvpn version. When this happens, you should discuss issues until the component is stable for 80% of the users, and 100% of developers. When you achieve this you can switch into the incremental approach. > What's hard is trying to keep track of bugs, new and old in bugs. Small concise > bug reports are much easier to work with. Instead this big bad bug report will > stay open until all are fixed. So you've made closing this bug harder by making > its scope big. Thanks! I think I answered it. It is an initial implementation, you should fix all issues, before you go incremental. > Now that we've gotten this off our chests lets try and agree some things. > > 1) the resolv.conf issue is probably not going to change - currently openvpn > manages /etc/resolv.conf like every other dhcp client in portage and they all > support resolvconf. But VPN is a different issue! Maybe just don't mess with /etc/resolv.conf if the gentoo component is not installed. Following the same behavior of openvpn-2.0 ebuild which works. > 2) You have some issues with the init script. Maybe it would be best if we > dropped the persist options by default and let the user put them into their > config files? True. Don't force them. > 3) The user has the choice of dropping privs, I see no reason to make this > default. IP address, subnet, resolv.conf - all could change and that all needs > route. re-entering the up/down.sh scripts with a sudo call is a good idea > though - I shall look into testing this. Thanks. It should be simple enough.
(In reply to comment #6) > It cannot be optional if it damanged the user! > It is not the same of two dhcp cards, since dhcp will likely to provide DNS > server address, where VPN server will not. Hmmmm, kinda pointless VPN providing domain without server addresses. Maybe we should not update unless we have that info as domain by itself is pointless. > > (In reply to comment #5) > > > But let's follow what happened so far... A gentoo developer added a new ebuild > > > to portage... > > > This ebuild was not written in a great quality... > > > > I take offense to that. I'd also like to know what you find wrong with it - > > from a pure code quality perspective it passes all our most stringent QA tests. > > Maybe you can tell me what is wrong with it? > > Yes. > 1. It overwrites people resolv.conf when it is only optional configuration > element in VPN server. Most people will find themselves without any DNS server > after VPN connect. > 2. It had wrong dependency. > 3. It dropped an imporant security feature (dropping privileges) from a > security oriented product. > 4. It uses persist stuff that will require people to have root privileges when > arriving home office. > > I don't call this a good QA. Wow. All that in an ebuild which I specified. Actually no. None of the above is technically in the ebuild. The ebuild installs the files which do any of the things you mentioned above apart from 2) which had already been fixed when I asked you to comment. I would say that the quality of your statement is very poor. > > > Just to be clear, focus all comments on the ebuild with the header > > openvpn-2.1_beta14.ebuild,v 1.3 2006/05/10 20:23:41 > > No. > I focus on the original check-in when I filed my initial comments, since you > closed the bug of adding the 2.1_beta14 into portage. This where I think you > got it wrong... bug#118435 should not have been closed until all issues are > fixed. I tell you what - why don't you start re-writing Gentoo bug handling policy - after all ours hasn't been working for years according. Bug #118435 was - and I quote from the summary "net-misc/openvpn-2.1 might be cool to have in portage" And I put it in portage, so bug fixed. You have any more issues, then open a new bug like we asked you to. Bug #1 - Gentoo Linux is born, add openvpn-2.1. With your arguments bug #1 would just get bigger and bigger and never get closed. Which is silly. I'll address your other comments later
(In reply to comment #7) > Hmmmm, kinda pointless VPN providing domain without server addresses. > Maybe we should not update unless we have that info as domain by itself > is pointless. The provided DNS may not resolve internet addresses... So you must keep the interface DNS and optionally add VPN DNS. > Wow. All that in an ebuild which I specified. Actually no. None of the above is > technically in the ebuild. The ebuild installs the files which do any of the > things you mentioned above apart from 2) which had already been fixed when I > asked you to comment. ebuild = ebuild+${FILESDIR} (support files) You cannot separate them they are one solution for the user. > I tell you what - why don't you start re-writing Gentoo bug handling policy - > after all ours hasn't been working for years according. No... I don't... This is how bug handling is performed in other ebuilds too... > Bug #118435 was - and I quote from the summary > "net-misc/openvpn-2.1 might be cool to have in portage" True... This should have been: cp openvpn-2.0.6.ebuild openvpn-2.1_beta14.ebuild ebuild openvpn-2.1_beta14.ebuild digest If you had done this, nobody had problems, and you got version 2.1 into portage. This what you should have reverted to when I reported the problem. But you have committed two different chunks: 1. Version bump. 2. New baselayout integration. Because you committed both at once, there is no choice other than discussing them both. > And I put it in portage, so bug fixed. You have any more issues, then open a > new bug like we asked you to. No... It haven't been fixed yet... since the bad baselayout integration still exists. > Bug #1 - Gentoo Linux is born, add openvpn-2.1. > > With your arguments bug #1 would just get bigger and bigger and never get > closed. Which is silly. No... I hope you now understand that you should have: cp openvpn-2.0.6.ebuild openvpn-2.1_beta14.ebuild ebuild openvpn-2.1_beta14.ebuild digest cp openvpn-2.1_beta14.ebuild openvpn-2.1_beta14-r1.ebuild add new stuff of baselayout to openvpn-2.1_beta14-r1.ebuild ebuild openvpn-2.1_beta14-r1.ebuild digest This will allow users to version bump and discuss your new baselayout integration.
(In reply to comment #6) > > 1) the resolv.conf issue is probably not going to change - currently openvpn > > manages /etc/resolv.conf like every other dhcp client in portage and they all > > support resolvconf. > > But VPN is a different issue! > Maybe just don't mess with /etc/resolv.conf if the gentoo component is not > installed. Following the same behavior of openvpn-2.0 ebuild which works. VPN does one thing - manages a secure connection. OpenVPN optionally handles DHCP information - this makes it a dhcp client. Currently it behaves exactly like a dhcp client in regards to /etc/resolv.conf Maybe you want an option for the script NOT to mess with /etc/resolv.conf? > > > 3) The user has the choice of dropping privs, I see no reason to make this > > default. IP address, subnet, resolv.conf - all could change and that all needs > > route. re-entering the up/down.sh scripts with a sudo call is a good idea > > though - I shall look into testing this. > > Thanks. > It should be simple enough. > This is not going to happen as user could setup sudo to require a password, which would be fatal to these scripts. Sorry, but if you want to run openvpn without root privs AND you want to be able to change /etc/resolv.conf, ip, etc etc then run it in a selinux or grsec+rsbac environment as a user who can do this.
(In reply to comment #9) > VPN does one thing - manages a secure connection. > OpenVPN optionally handles DHCP information - this makes it a dhcp client. > Currently it behaves exactly like a dhcp client in regards to /etc/resolv.conf > Maybe you want an option for the script NOT to mess with /etc/resolv.conf? Yes... As I've written before. The script should not overwrite /etc/resolv.conf it can, however, APPEND new DNS servers. The analog to dhcp is incorrect... Since YOU AREADY connected to the network and work with stuff that are VPN unrelated. > > > 3) The user has the choice of dropping privs, I see no reason to make this > > > default. IP address, subnet, resolv.conf - all could change and that all needs > > > route. re-entering the up/down.sh scripts with a sudo call is a good idea > > > though - I shall look into testing this. > > This is not going to happen as user could setup sudo to require a password, > which would be fatal to these scripts. True. Exactly as if the user does not wish to put anything in sudoers, or of the user chooses to drop privs so your scripts will not work. However, you can "sudo -p "" -S ls < /dev/null" so it will not wait for password. If this is the problem you refer to. > Sorry, but if you want to run openvpn without root privs AND you want to be > able to change /etc/resolv.conf, ip, etc etc then run it in a selinux or > grsec+rsbac environment as a user who can do this. I still don't understand why it is so difficult to solve without patching the kernel!!! But if it is too complex for you, please add /etc/conf.d/openvpn.* with: PLEASE_DONT_MESS_WITH_GENTOO_SPECIFIC_STUFF=1 Which will cause /etc/init.d/openvpn to NOT adding up/down scripts or any other new option you added since 2.0.
I thought I'd chime in on this. In my opinion, Alon's point would be valid if the 2.1 branch was not hard masked. But it is. That carries all the implications of any hard masked package: not stable, not recommended. Having said that, I think that the pace at which this bug conversation is going, the two of you are going to increasingly frustrate each other. Alon: I'm having a bit of trouble understanding your issue. I admit to using OpenVPN, and indeed deploying it here. The recent change in 2.1 has been an absolute miracle for us here. Now, linux clients who connect to work, can browse the share drives, and other servers with no trouble! It's great, it really is! However, you obviously have a different use case, and thus a different set of needs. Can you describe your use case in a little more detail (esp. why you wouldn't want dhcp/dns given out by the vpn server). It looks like you want dhcp, but not dns or something like that -- I'm unclear. Now as for your recommendation about sudo: I was going to talk with Roy about that my own self -- I like priv dropping, but I also like the resolvconfd stuff changing so that I can continuously work from home, without having to manually reacquire routing info. That's all I have so far. I would urge both of you to please step away for a minute, catch your breaths and return to this conversation with the aim of working to the common goal of having a great package, and not to out-insult each other (which is where this is heading). Thanks, Seemant
(In reply to comment #11) > I thought I'd chime in on this. In my opinion, Alon's point would be valid if > the 2.1 branch was not hard masked. But it is. That carries all the > implications of any hard masked package: not stable, not recommended. I partially agree. Many people already had copied openvpn-2.0.6 to openvpn-2.1_beta14, as was expected. Masking it made people to downgrade... (I got many questions what to do next...) So people were affected. > Alon: I'm having a bit of trouble understanding your issue. I admit to using > OpenVPN, and indeed deploying it here. The recent change in 2.1 has been an > absolute miracle for us here. Now, linux clients who connect to work, can > browse the share drives, and other servers with no trouble! It's great, it > really is! I know! I wrote the smartcard interface, cert validation and some more. I love openvpn and I wish it to be used correctly. > However, you obviously have a different use case, and thus a different set of > needs. Can you describe your use case in a little more detail (esp. why you > wouldn't want dhcp/dns given out by the vpn server). It looks like you want > dhcp, but not dns or something like that -- I'm unclear. I never said that I don't want to! All I said that not all people having DNS at their VPN sites... Most using the internet DNS and /etc/hosts for their home addresses. Current ebuild implementation overwrite system resolv.conf when resolvconf-gentoo is not installed (And it is not a dependency). So you browse the internet... Decide to connect to your office via openvpn... And woops!!! you cannot access any URL... Since you don't have a valid DNS anymore. I call it a bug, many people will be affected. It can be solved: 1. Force resolvconf-gentoo dependency. 2. Don't touch /etc/resolv.conf if resolvconf-gentoo not installed. 3. Only append DNS to /etc/resolv.conf if resolvconf-gentoo not installed. VPN is not a regular interface since it uses the interface to access to destination... Removing the interface networking definitions is not wise... Just like you would not remove its ip address after tunnel is established. > Now as for your recommendation about sudo: I was going to talk with Roy about > that my own self -- I like priv dropping, but I also like the resolvconfd stuff > changing so that I can continuously work from home, without having to manually > reacquire routing info. It should be simple enough... I don't understand what is the problem in sudo self if uid!=0, it is a simple usable solution for people who like to keep their system secured. Alternatively, adding /etc/conf.d/openvpn.* to disable the forced arguments so people may specify their own.
Hmmm... openssl-0.9.6.cnf is installed as executable. I guess I should write Makefile (install) for easy-rsa. I will do that. If anyone have other requests please send me.
(In reply to comment #12) > I never said that I don't want to! > All I said that not all people having DNS at their VPN sites... > Most using the internet DNS and /etc/hosts for their home addresses. I am not sure what version of the up.sh script you're using. if the server does not advertise 'dhcp-option DNS' or 'dhcp-option DOMAIN', your resolv.conf should not be touched. (since rev1.2). so can you consider this matter closed? > So you browse the internet... Decide to connect to your office via openvpn... > And woops!!! you cannot access any URL... Since you don't have a valid DNS > anymore. please verify for yourself if the latest up.sh script fixes this behavior. http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-misc/openvpn/files/up.sh?rev=1.3&view=log > VPN is not a regular interface since it uses the interface to access to > destination... Removing the interface networking definitions is not wise... can you rephrase that? (In reply to comment #13) > I guess I should write Makefile (install) for easy-rsa. I will do that. I am not sure I understand what you try to do here. easy-rsa IS installed by the ebuild. also some users will use certificates created by real PKI infrastructures and not rely on the easy-rsa scripts. in my case for instance, I customized openca to generate openvpn server/client certificates.
(In reply to comment #14) > I am not sure what version of the up.sh script you're using. if the server does > not advertise 'dhcp-option DNS' or 'dhcp-option DOMAIN', your resolv.conf > should not be touched. (since rev1.2). I can sync only once a day (bug#130039). So if you preform changes, please leave a comment so I will be able to know to check it out. > > So you browse the internet... Decide to connect to your office via openvpn... > > And woops!!! you cannot access any URL... Since you don't have a valid DNS > > anymore. > > please verify for yourself if the latest up.sh script fixes this behavior. But what happens when VPN disconnects? You are left with the VPN provided DNS address... So you cannot use your networking... Until /etc/init.d/net.ethX restart. So I think the down.sh should also be modified... I don't know if you can return the address of the DHCP/interface DNS addresses, or the simplest solution is to add the resolvconf-gentoo dependency. Also there are DNS servers at remote offices that do not resolve internet addresses... They just resolves local site addresses. So leaving just these interfaces may cause problems accessing internet. I would suggest to append the new DNS at the head of the /etc/resolv.conf, leaving the DHCP DNS address. The will support local DNS servers at remote and enable the down script to remove the VPN DNS from this list. > > VPN is not a regular interface since it uses the interface to access to > > destination... Removing the interface networking definitions is not wise... > > can you rephrase that? Oh... I referred to the up.sh/down.sh script modification written above (leaving dhcp DNS address).... > I am not sure I understand what you try to do here. easy-rsa IS installed by > the ebuild. > also some users will use certificates created by real PKI infrastructures and > not rely on the easy-rsa scripts. in my case for instance, I customized openca > to generate openvpn server/client certificates. I just added Makefile to easy-rsa, so you will be able to (next beta): if ! use minimal; then cd easy-rsa/2.0 emake install "DESTDIR={D}/usr/share/${PN}/easy-rsa" ... Will allow you drop the per-file installation so if new files will be added you won't need to modify the ebuild.
(In reply to comment #15) > I can sync only once a day (bug#130039). > So if you preform changes, please leave a comment so I will be able to know to > check it out. Eh? http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openvpn/files/
(In reply to comment #16) > > So if you preform changes, please leave a comment so I will be able to know to > > check it out. > > Eh? > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/openvpn/files/ Dear Jacub, I've looked at the CVS before I wrote my last comment... All I've asked was to leave a note here, if a change is done in CVS that result of this discussion.
(In reply to comment #15) > But what happens when VPN disconnects? > You are left with the VPN provided DNS address... > So you cannot use your networking... Until /etc/init.d/net.ethX restart. > > So I think the down.sh should also be modified... I don't know if you can > return the address of the DHCP/interface DNS addresses, or the simplest > solution is to add the resolvconf-gentoo dependency. > > Also there are DNS servers at remote offices that do not resolve internet > addresses... They just resolves local site addresses. So leaving just these > interfaces may cause problems accessing internet. > > I would suggest to append the new DNS at the head of the /etc/resolv.conf, > leaving the DHCP DNS address. The will support local DNS servers at remote and > enable the down script to remove the VPN DNS from this list. New up and down scripts now save and restore resolv.conf information if you don't have resolvconf installed. It is still a direct resolv.conf replacement due to the way libc handles dns resolution - once it picks a server that works it keeps on using that server, so you cannot have one server for vpn and another for internet. libc just doesn't support that, so a direct replacement is the only sensible option if openvpn supplies dns. So whats's the solution? Well, run a local dns resolver like dnsmasq or bind. I have resolvconf hook scripts scripts that setup the resolver to forward requests for the openvpn domain to the given nameservers and everything else to the internet/lan name servers. These scripts will be in portage soon. So as far as I can see the only outstanding thing here is about getting sudo put in the up/down scripts. I've chatted with Gentoo Security guys and the sudo maintainer, and they think this is a bad idea, so this bug is now being closed as FIXED. If you want to open a new bug for the sudo request then go ahead and do that, but only request the feature and your reasons why without referencing other bugs to keep the noise down to a minimum. Or you can re-open this one if you disagree.
(In reply to comment #18) > New up and down scripts now save and restore resolv.conf information if you > don't have resolvconf installed. I've looked at the CVS down script... Did not see how it restore the resolv.conf... I've also tried to use it... But it did not restore... Strange... Maybe I don't understand... But I trust you it doing so... (Have anyone running a system without resolvconf-gentoo, and found this works?) > So whats's the solution? Well, run a local dns resolver like dnsmasq or bind. I > have resolvconf hook scripts scripts that setup the resolver to forward > requests for the openvpn domain to the given nameservers and everything else to > the internet/lan name servers. These scripts will be in portage soon. Well... I just think about the simple user who needs to make this stuff work...
if anyone is interested in my ramblings, well, I see no logic into allowing the openvpn process to sudo. please think twice before pushing that upstream. or make it optional, non-default and non-recommended. you drop the privileges of openvpn for one purpose only: if an attacker would gain control over the process you make sure that it will not be able to do things otherwise not allowed for that low priv account. granting it _any_ extra privileges would not help security by any means. if you really want security, stop using down.sh scripts and add their logic into the stop() function of the openvpn init script. that one will always be run by root ensuring proper cleanup and openvpn will always run as a low priv process. etc-update(1) will be very friendly with you from that moment on.
(In reply to comment #20) > if anyone is interested in my ramblings, Sure! > well, I see no logic into allowing the > openvpn process to sudo. please think twice before pushing that upstream. or > make it optional, non-default and non-recommended. It will be optional... If you prefer running openvpn as root you will openvpn will be able to configure the tun interface and routing entries without any need for priv up-lift. > you drop the privileges of openvpn for one purpose only: if an attacker would > gain control over the process you make sure that it will not be able to do > things otherwise not allowed for that low priv account. granting it _any_ extra > privileges would not help security by any means. True, you got the first part right. But the second part is incorrect, since OpenVPN *MUST* be able (at the minimum) to configure the tun interface and add/remove route entries. So one solution for this is the current solution, run OpenVPN as root. Other solution is to run OpenVPN as none-root and use suid wrapper to do this, there are problems in suid wrapper, that they cannot be customized. For example they cannot garntee to control only one tun interface, or add route entry for specific address. The customized solution would be using sudo for each required priv, then the user may receive the command argument, and decide how to implement the system command. > if you really want security, stop using down.sh scripts and add their logic > into the stop() function of the openvpn init script. that one will always be > run by root ensuring proper cleanup and openvpn will always run as a low priv > process. I don't follow you... How does it help? I already know how to patch the up/down scripts to use sudo. The problem is that the up/down scripts calls init.d/openvpn and they are not allowed to do that after priv drop. But thank you! You are one of the few (only) that discuss of the issue it-self.
(In reply to comment #21) > > well, I see no logic into allowing the > > openvpn process to sudo. please think twice before pushing that upstream. or > > make it optional, non-default and non-recommended. > > It will be optional... If you prefer running openvpn as root you will openvpn > will be able to configure the tun interface and routing entries without any > need for priv up-lift. no, I mean optional even if I drop privileges. (I also drop privs when I start openvpn) > > you drop the privileges of openvpn for one purpose only: if an attacker would > > gain control over the process you make sure that it will not be able to do > > things otherwise not allowed for that low priv account. granting it _any_ extra > > privileges would not help security by any means. > > True, you got the first part right. > But the second part is incorrect, since OpenVPN *MUST* be able (at the minimum) > to configure the tun interface and add/remove route entries. this is how I see it: openvpn starts as root. it sets up the tun/tap interface, starts up.sh, drops privileges. everything is perfect until now. now when you stop it you have 2 scenarios: - sudo and run down.sh to restore resolv.conf for instance OR - do not run sudo and let a more privileged process do the cleanup from a security perspective the second scenario is much cleaner since you don't have to elevate openvpn's privileges. the init script is run by root, so for me that is just the thing I need. for me it's as easy as sticking this one-liner into the stop() function of the init script itself: for i in $(resolvconf -i); do ifconfig $i &>/dev/null || resolvconf -d $i; done openvpn will start and stop exactly as expected, resolv.conf will be cleaned up and most important openvpn it will NOT NEED to run sudo or to be allowed to suid by any means. once you drop privs, that process should stay that way or die. Roy told me that the command will not work for all, so everyone will have to dig a little bit to find a solution that fits their bill. > So one solution for this is the current solution, run OpenVPN as root. > Other solution is to run OpenVPN as none-root and use suid wrapper to do this, > there are problems in suid wrapper, that they cannot be customized. For example > they cannot garntee to control only one tun interface, or add route entry for > specific address. > The customized solution would be using sudo for each required priv, then the > user may receive the command argument, and decide how to implement the system > command. well, you see, I prefer sticking the logic into the init script. everyone has their favorite method and gentoo makes it easy for the user to customize anything in /etc. > > if you really want security, stop using down.sh scripts and add their logic > > into the stop() function of the openvpn init script. that one will always be > > run by root ensuring proper cleanup and openvpn will always run as a low priv > > process. > > I don't follow you... How does it help? it helps by not needing to provide more privileges to openvpn than what is actually needed.
(In reply to comment #22) > openvpn starts as root. it sets up the tun/tap interface, starts up.sh, drops > privileges. everything is perfect until now. No. OpenVPN starts but not nessary connect to target... 1. You are offline... So you cannot reach target, OpenVPN will continue trying to reach target. 2. You are online, but a firewall/gateway block communication to target. 3. You are online, but choose to connect on demand... As long as you are not connected OpenVPN cannot know what configuration the remote has to offer. So it cannot setup tun and routing = it cannot drop privs without using a helper up-lift. This is the current OpenVPN implementation. It stays root until the first connection establishment. I think that this can be solved next version by sudo as I described earlier. > now when you stop it you have 2 scenarios: > - sudo and run down.sh to restore resolv.conf for instance OR > - do not run sudo and let a more privileged process do the cleanup OK... But the daemon is running all the time... It connects and disconnects automatically... The cleanup should be done while the process is up. I don't understand how you recommend of doing that. > from a security perspective the second scenario is much cleaner since you don't > have to elevate openvpn's privileges. the init script is run by root, so for me > that is just the thing I need. I agree... If it could have been done... The up/down scripts may be run many times during the OpenVPN is up, everytime the tunnel is established and disconnected. I just don't follow you... Do you want the daemon to be stopped every time it cannot reach remote? Do you want the user to have root priv to start the tunnel when he wishes? Currently OpenVPN have a management interface that allow none-root user to connect/disconnect the tunnel, be notified of disconnect etc... This was implemented in order to allow secured environments in which users do not have root privs... And still want to use VPN. So do you wish to drop the usage of this interface and make GUI like kovpn unusable? So "from a security perspective" dropping privs and allowing OpenVPN user to execute the minimum required in controlled up-lift environment (sudo) is the most secured and workable solution. > for me it's as easy as sticking this one-liner into the stop() function of the > init script itself: > > for i in $(resolvconf -i); do ifconfig $i &>/dev/null || resolvconf -d $i; done The problem is that the tunnel may be disconnected during the daemon is still up, and we need to support this. > openvpn will start and stop exactly as expected, resolv.conf will be cleaned up > and most important openvpn it will NOT NEED to run sudo or to be allowed to > suid by any means. once you drop privs, that process should stay that way or > die. Well... I hope you understand now the different between start/stop and up/down. > well, you see, I prefer sticking the logic into the init script. everyone has > their favorite method and gentoo makes it easy for the user to customize > anything in /etc. But it will not work... I've recommended long ago to add a /etc/conf.d/openvpn.* with: DONT_HOOK_OPENVPN=1 So that people may specify their own up/down scripts, without the /etc/init.d/openvpn.* overriding this. This will solve this issue without patching current implementation, and using env-update to merge stuff each time a new version is out. This should be the simplest solution if gentoo developers don't like to add sudo.
(In reply to comment #19) > (In reply to comment #18) > > New up and down scripts now save and restore resolv.conf information if you > > don't have resolvconf installed. > > I've looked at the CVS down script... Did not see how it restore the > resolv.conf... I've also tried to use it... But it did not restore... > Strange... Maybe I don't understand... But I trust you it doing so... (Have > anyone running a system without resolvconf-gentoo, and found this works?) hmmmm... Roy, you should have told/depend >=net-misc/dhcpcd-2.0.4... Because of using the stable dhcpcd the resolvconf was not aware of the ethX configuration.... So I always turned out with an empty /etc/resolv.conf
