From bug#132932 (Roy Marples <uberlord@gentoo.org>) > 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. Can you reveal me what they said? Why is it bad idea? Is running root daemon is a better idea? Can you at least consider adding /etc/conf.d/openvpn.* that have: DONT_HOOK_OPENVPN=1 So people may use their own scripts to to a do a bad idea, and support privileges dropping, without patching your scripts? This will allow both side be happy... Although I think mainline should support privileges dropping...
(In reply to comment #0) > Can you reveal me what they said? Well, he just agreed with me that using sudo in this instance is bad I've cc'ed him on this bug Basically the up,down.sh scripts may start or stop other services depending on openvpn which could include things like netmount, ntpd, etc. Also, note that openvpn runs as the root user until a successfull connection is made for most configurations.
(In reply to comment #1) > Well, he just agreed with me that using sudo in this instance is bad You are not serious... I am taking this subject very seriously... Need some better response. > Basically the up,down.sh scripts may start or stop other services depending on > openvpn which could include things like netmount, ntpd, etc. But this is required!!! I want this behavior be supported... But why forcing the openvpn daemon run as root?!?!? You can support his behavior AND run openvpn as non root... From security perspective it is better... And I don't see what is the down side of it... I will appreciate any explanation. > Also, note that openvpn runs as the root user until a successfull connection is > made for most configurations. Yes... I will try to work on this issue with John in 2.5... So openvpn will run the networking commands via scripts... So it will be able to be run as none root user from start, and user may configure sudouers to allow it to perform the needed commands and filter them if needed.
Created attachment 86649 [details] sudo prefix to scripts Just to be clear, you are proposing that we just prefix the up/down scripts with something like the attached file. taviso, could you comment on any problems/pitfalls with this? Actually, thinking about it, would it not be better to build sudo support into openvpn for every command it makes? Reasoning - root is required for those commands anyway (create/destroy tun/tap device, ifconfig and root setup). All openvpn does is system commands, so a patch for sudo support shouldn't be that hard. Doing it that make makes this bug moot then :)
(In reply to comment #3) > Created an attachment (id=86649) [edit] > sudo prefix to scripts > > Just to be clear, you are proposing that we just prefix the up/down scripts > with something like the attached file. TRUE!!! Simple enough... Works for all... :) > Actually, thinking about it, would it not be better to build sudo support into > openvpn for every command it makes? Reasoning - root is required for those > commands anyway (create/destroy tun/tap device, ifconfig and root setup). All > openvpn does is system commands, so a patch for sudo support shouldn't be that > hard. Doing it that make makes this bug moot then :) It is!!! This what I want to do in 2.5... (comment#2) But not prefix each command or execute it directly... There should be a configurable shell scripts to do each family of commands... So the user will be able to allow a specific instance of openvpn to control tun10 and not tun9, or never add route for 2.3.4.5, etc...
In general, sudo shouldnt be used non-interactively, users expect unix permissions to act as a partition, letting applications elevate their privileges behind the scenes is a very bad idea. I think this issue should be resolved by upstream if it's something they want to support, a suid wrapper specially designed for this purpose or similar would be best.
(In reply to comment #5) > In general, sudo shouldnt be used non-interactively, users expect unix > permissions to act as a partition, letting applications elevate their > privileges behind the scenes is a very bad idea. But the need for being root at this stage is a requirement of the integration with the baselayout... OpenVPN allows you to be notified of some events so you can do whatever you like in order to handle them. > I think this issue should be resolved by upstream if it's something they want > to support, a suid wrapper specially designed for this purpose or similar would > be best. suid wrapper is also "letting applications elevate their privileges behind the scenes". If you ask me what more secure - use suid or sudo... I am a huge fun of sudo... Since the user can control what happening. For example, I can write suid wrapper to manage tun devices... It will be executed by openvpn and do the trick... But how can the user make it manage only the right tun interface...? Now I have to also write a configuration file for this suid wrapper... And what if I have a bug? You are already in root context can do whatever you like. Using sudo is much safer and flexible... OpenVPN or any process sudo a shell script/user program. This shell script controlable by the administrator, can impose whatever restrictions it wants, and hand over the required action to the appropriate program. The result is a much secured operation. Another approach could be that the baselayout will have suid support to allow none root daemons belonging to XXXX group to perform some basics.
(In reply to comment #4) > It is!!! This what I want to do in 2.5... (comment#2) > But not prefix each command or execute it directly... > There should be a configurable shell scripts to do each family of commands... Excellent (In reply to comment #5) > In general, sudo shouldnt be used non-interactively, users expect unix > permissions to act as a partition, letting applications elevate their > privileges behind the scenes is a very bad idea. > > I think this issue should be resolved by upstream if it's something they want > to support, a suid wrapper specially designed for this purpose or similar would > be best. Based on the above statement from our sudo maintainer and security guy AND your statement that openvpn is working to provide a better solution for this AND the fact that the default openvpn option is to run as root I'll mark this as WONTFIX. As all files in question are in /etc anyway each user is in control of them, so this shouldn't be that much of an issue.
No... First, I did not receive your commend regarding adding /etc/conf.d/openvpn.* with: DONT_HOOK_OPENVPN=1 So you don't enforce your setting... This should be simple... A simple if will do at /etc/init.d/openvpn. And people will be able to specify their own event script in openvpn.conf, and maybe call yours. I am waiting for a response specific for this suggestion raised a long time ago. Second, It was more polite to wait for a response for the questions I've raised to the security guy... His position is quite strange... Since I as a security guy (paid for my work...) Move people away from the old suid wrappers, into the new controllable sudo interface. Calling new for sudo is very strange... but patching the kernel is still something that many users prefer not to do. The suid wrappers posses a higher risk than sudo commands.
Security team - now your bug.
(In reply to comment #9) > Security team - now your bug. Roy Marples, Why do you refuse to comment my suggestion? (comment #8) > First, I did not receive your commend regarding adding /etc/conf.d/openvpn.* > with: > DONT_HOOK_OPENVPN=1 > So you don't enforce your setting... This should be simple... A simple if will > do at /etc/init.d/openvpn. > And people will be able to specify their own event script in openvpn.conf, and > maybe call yours.
(In reply to comment #10) > Roy Marples, Why do you refuse to comment my suggestion? Because it implies that sudo support is in the scripts - I have already turned this down. The matter is now for Gentoo Security to decide. They will either recommend or reject sudo support. They may recommend an alternative solution in either case.
(In reply to comment #11) > > Roy Marples, Why do you refuse to comment my suggestion? > > Because it implies that sudo support is in the scripts - I have already turned > this down. The matter is now for Gentoo Security to decide. I did not think of it this way. It only implies a simpler approach of openvpn integration... Not forcing the user to use gentoo-related openvpn options for openvpn setup. Allowing this without patching the ebuild each time a new version is out. Now I am required to supply a new ebuild for the users I support every time to patch yours... People now use privileges dropping and will continue to use this feature... The only problem is that although it was supported by the 2.0 series ebuilds, it is now forced to be not supported and patched. All I asked is to give users a way out. The variable I suggested is doing exactly that, back to the 2.0 series environment if requested. But as you wish... I will wait for the final say regarding this issue...
Misplaced bug
Roy: Saw your fix on bug#181000. I can use CLIENT_DETECT="no" and close this bug. But before I do, I think you should rename CLIENT_DETECT to CONFIG_AUTODETECT so that you will not parse configuration if CONFIG_AUTODETECT is no. We could have closed this issue long ago and avoid more bugs opened against the configuration.
Well... Cannot close this bug, as the "client" variable in the init.d script cannot be modified from outside... Still cannot drop root privileges and act as a client.
(In reply to comment #15) > Well... Cannot close this bug, as the "client" variable in the init.d script > cannot be modified from outside... > Still cannot drop root privileges and act as a client. Sure it can. CLIENT_DETECT=no in /etc/conf.d/openvpn and we don't do anything except run as user/group openvpn/openvpn unless specified in the config.
No. Look at the "client" variable if it "false" all client functionality is disabled (the pending behavior).
Ah you really do mean the client variable so we still mark the service inactive and rely on user defined scripts to re-enter?
(In reply to comment #18) > Ah you really do mean the client variable so we still mark the service inactive > and rely on user defined scripts to re-enter? Yes. This should be an option. Please remember what we are trying to accomplish... The EXACT behavior, only that the daemon run as none root. The user script will do sudo to the package provided script. You can add something like FORCE_CLIENT or something.
Added RE_ENTER config variable, which now fixes this.
