Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Hi! As this discussion has not much to do with the rc19 release, would you please change the subject ? Like "OpenVPN and SELinux" or "Securing the OpenVPN process" ... Thanks, David > -Original Message- > From: Karl O. Pinc [mailto:k...@meme.com] > Sent: Wednesday, July 29, 2009 6:17 PM > To: Alon Bar-Lev > Cc: openvpn-devel@lists.sourceforge.net > Subject: Re: [Openvpn-devel] OpenVPN 2.1_rc19 released > > On 07/28/2009 11:47:57 PM, Alon Bar-Lev wrote: > > Well, > > I do not understand you guys. > > > > If you think SELinux is so great, why do you need chroot? > > It is like you put some money in safe, and then put the safe into > > another safe, it never ends... Why only two safe, let's put another > > safe... > > I know that this is the approach many of security advisors > use, but I > > never could have found the logic. > > If you want to keep your money safe use a single safe and select the > > strongest one. > > The idea is more like selecting the strongest safe, then putting > it behind a moat inside a ring of fire. That way the thief not > only has to be a good safe cracker, he must also be > a fire walker and a swimmer, with experience wrestling > alligators a decided advantage. Multiple layers of _different_ > security raises the bar considerably. > > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > > > -- > > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 07/28/2009 11:47:57 PM, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one. The idea is more like selecting the strongest safe, then putting it behind a moat inside a ring of fire. That way the thief not only has to be a good safe cracker, he must also be a fire walker and a swimmer, with experience wrestling alligators a decided advantage. Multiple layers of _different_ security raises the bar considerably. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On Wed, 2009-07-29 at 07:47 +0300, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one. Security professionals refer to is as "defense in depth". Look it up. The opposite of which is "all your eggs in one basket". Not good. With defense in depth, if an attacker finds a hole in one defensive layer, he should get caught in another. That way, he has to be perfect and get through all your defenses without getting caught while you only have to stop him at one. The other way (single defense), your defense must always be perfect and reliable while he only needs a single hole through that single layer. Your choice. > And final note regarding the iproute wrapper. > It is a *WRAPPER*, if I needed top secured implementation I would have > created a daemon listening to network change requests using unix > domain sockets, wrap this up in SELinux profile, and implementing a > logic that allows only changes to tap/tun interface with specific > attributes, and allowing routing table update with specific details. > Then add a wrapper that uses the unix domain socket in order to access > the daemon. OpenVPN will use the wrapper so it needs no special > privilege. The daemon validates what SELinux or any other security > product cannot validate: Network configuration changes. All done > within a valid and separate context. > > As I wrote earlier, most of OpenVPN configurations need to execute > iproute also during session. For example, if you like to connect two > sites, your super SELinux secured solution will work only at one site. > > No need to discuss this further. I get your point. > > Alon. > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 29/07/09 03:49, Karl O. Pinc wrote: > On 07/28/2009 04:22:09 PM, Sebastien Raveau wrote: > > >> If I understand you correctly, that is, if you are suggesting that >> OpenVPN should automatically apply a SELinux context if setcon() is >> available... I'll have to disagree with you. Not that I reject the >> idea of enforcing security measures by default, but because when you >> google for "selinux howto", half of the first-page results are on how >> to *disable* SELinux. Apparently not everybody likes it, and they >> have >> a right to, so I believe we should not force it upon them :-) > > SELinux is a great idea, in theory. In practice I find the > cost/benefit such that I wind up turning it off. I'd love > to have it available and working in "stock" situations, > and have the (easy to do) option of turning it off if > desired. If nothing else it gets in the way of development/ > deployment. After something's working then it's possible to go back > and figure out which permissions need enabling. I've been running Fedora with SELinux enabled for over a year, without having any issues at all. I've even been testing a lot of different software setups on Fedora and Red Hat Enterprise Linux, without having issues. > Because of the complication it would also be highly > desirable, except for a possible "off/monitor mode/on" > switch, if it would integrate with the rest of SELinux > so there's not yet more configuration. I assume that > this is the natural approach to take, but figured I'd > mention it anyway. In Fedora/RHEL you have the getenforce and setenforce programs, which changes between "Permissive" and "Enforced" modes. This is a system-wide configuration change, and is effective immediately without reboot. With a properly designed SELinux profile for OpenVPN, usually from a distribution, but it would be good if it also followed the OpenVPN source code, it would not be more configuration. It would be to register this profile on your system. Normally, these profiles can be quite static, no matter which system it is setup on. On a brand new installation, it might be needed to label some files on the file system, but again, this could be done via a little script. New configuration files for OpenVPN and certificates would need to be labelled too, but that's usually just to either copy them into the desired directory and to run restorecon or chcon. http://danwalsh.livejournal.com/4208.html In fact, Fedora and RHEL do ship OpenVPN 2.1_rc15 with SELinux profiles, labelling files and directories for OpenVPN. But there is no security context shift inside the binary, AFAIK, which would be even more beneficial, as not everything is covered by just file labelling. kind regards, David Sommerseth
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On Wed, Jul 29, 2009 at 6:47 AM, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one. SELinux+chroot is indeed redundant, but as they do not conflict, why not use them both? To re-use your safe example: in your bank your belongings could be protected by a smart safe, security guards and/or policemen... However redundant that might be, I feel more comfortable knowing that more means are used to protect my belongings :-) > The daemon validates what SELinux or any other security > product cannot validate: Network configuration changes. All done > within a valid and separate context. Indeed, indeed :-) > As I wrote earlier, most of OpenVPN configurations need to execute > iproute also during session. For example, if you like to connect two > sites, your super SELinux secured solution will work only at one site. Maybe so... I did not pretend SELinux was the ultimate solution to every problem, and I straightforwardly recognize not knowing all OpenVPN use cases. My will is only to offer more possibilities so that everybody can find a combination that suits their needs: not everybody uses the "user" or "chroot" option, probably even less people will use the "setcon" option and who knows, maybe somebody will submit support for doing the same with alternatives to SELinux (such as GRSecurity and RSBAC). > No need to discuss this further. I get your point. Ok :-) -- Sebastien Raveau
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 29/07/09 06:47, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one. I understand partly your logic. But unfortunately, this is what most security crackers hope for. They look for every possibility to get an opening into a network or server, to gain root access and enable the box they got access to for further usage. To defend yourself from a possibility of a break in, you need to take all possibilities available in use. If not, you are weaker than other solutions, and your setup will be more attractive to those trying to crack into your server. This is nothing new, this is how the daily life is. Sooner or later, OpenVPN will be more attractive in general for being cracked, when other solutions gets more and more secured. Sooner or later, OpenVPN will get the storm. If we are ahead of that storm by promoting and recommending all possible security features available, implementing them, the damage after such a storm might not be as big as it can be without taking advantage of all security measures available. And another thing you do not take into consideration, is that in your argument you take it for granted that OpenVPN do not have any security related bugs, e.g. a buffer overflow which can be misused by carefully hand crafted network packages, which is unexpected. It can even be a flaw inside OpenSSL (which is also not that uncommon). With SELinux you limit much more than what chroot() + setuid() can do alone. But as I said earlier, non of these calls exclude any other. > And final note regarding the iproute wrapper. > It is a *WRAPPER*, if I needed top secured implementation I would have > created a daemon listening to network change requests using unix > domain sockets, wrap this up in SELinux profile, and implementing a > logic that allows only changes to tap/tun interface with specific > attributes, and allowing routing table update with specific details. > Then add a wrapper that uses the unix domain socket in order to access > the daemon. OpenVPN will use the wrapper so it needs no special > privilege. The daemon validates what SELinux or any other security > product cannot validate: Network configuration changes. All done > within a valid and separate context. This is actually even a much better idea than a wrapper, seriously! Wrappers, and especially wrappers with sudo access (or even worse, the setsuid bit set on the file) are prune to be cracked and misused. As the matter of fact, I've gotten a flaw demonstrated which managed, through a overflow bug, to write a nicely crafted crontab entry which then caused the crond to core dump on execution of that entry. But when that happened, you had a setsuid binary in /tmp ... which actually was a copy of a shell. But it required SELinux to be either to be disabled or be in Permissive mode (logging only). > As I wrote earlier, most of OpenVPN configurations need to execute > iproute also during session. For example, if you like to connect two > sites, your super SELinux secured solution will work only at one site. Yes! And WITH SELinux, it will still be able to run iproute or whatever else the configuration requires - in a safer and more controlled regime. But it will not only work on one site. It will work wherever SELinux is properly configured and implemented. In fact, it will not even break the OpenVPN functionality if you run a SELinux enabled OpenVPN on a kernel without SELinux enabled, you will just miss that extra layer of security. Security is not about picking the best solution of several options. Security is about combining the best of all solutions together. kind regards, David Sommerseth
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Well, I do not understand you guys. If you think SELinux is so great, why do you need chroot? It is like you put some money in safe, and then put the safe into another safe, it never ends... Why only two safe, let's put another safe... I know that this is the approach many of security advisors use, but I never could have found the logic. If you want to keep your money safe use a single safe and select the strongest one. And final note regarding the iproute wrapper. It is a *WRAPPER*, if I needed top secured implementation I would have created a daemon listening to network change requests using unix domain sockets, wrap this up in SELinux profile, and implementing a logic that allows only changes to tap/tun interface with specific attributes, and allowing routing table update with specific details. Then add a wrapper that uses the unix domain socket in order to access the daemon. OpenVPN will use the wrapper so it needs no special privilege. The daemon validates what SELinux or any other security product cannot validate: Network configuration changes. All done within a valid and separate context. As I wrote earlier, most of OpenVPN configurations need to execute iproute also during session. For example, if you like to connect two sites, your super SELinux secured solution will work only at one site. No need to discuss this further. I get your point. Alon.
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 07/28/2009 04:22:09 PM, Sebastien Raveau wrote: > If I understand you correctly, that is, if you are suggesting that > OpenVPN should automatically apply a SELinux context if setcon() is > available... I'll have to disagree with you. Not that I reject the > idea of enforcing security measures by default, but because when you > google for "selinux howto", half of the first-page results are on how > to *disable* SELinux. Apparently not everybody likes it, and they > have > a right to, so I believe we should not force it upon them :-) SELinux is a great idea, in theory. In practice I find the cost/benefit such that I wind up turning it off. I'd love to have it available and working in "stock" situations, and have the (easy to do) option of turning it off if desired. If nothing else it gets in the way of development/ deployment. After something's working then it's possible to go back and figure out which permissions need enabling. Because of the complication it would also be highly desirable, except for a possible "off/monitor mode/on" switch, if it would integrate with the rest of SELinux so there's not yet more configuration. I assume that this is the natural approach to take, but figured I'd mention it anyway. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Thanks for your support :-) On Tue, Jul 28, 2009 at 10:45 PM, David Sommerseth wrote: > If I understood Alon correctly, he also executes OpenVPN as a less > privileged user, meaning that it is impossible to escape out of that > user, as the saved UID/GID will be a unprivileged user. But! Chroot > will in this setting be impossible, because only root can do chroot(). Indeed, thought of mentioning that in my mail but then forgot... On a side note, once you have chroot'ed you have to give up root privileges as soon as possible since there are tricks to get out of a chroot jail (like opening "." as a file, chrooting again in a subdirectory and from there calling fchdir with the file descriptor you had on the parent directory: as chroots are/were not stackable, you could get out of it like that). Maybe these tricks don't work anymore, but who knows... I doubt anybody would have an OpenVPN config with the "chroot" option but without the "user" one, but it's still worth mentioning I guess :-) > Sebastien, back to your patch. There is one thing I've been thinking > about today, regarding the --setcon parameter you introduce to the > openvpn binary. Why does this need to be a runtime parameter? I cannot > imagine you want to run openvpn with different security context on the > same box, or even the same Linux distro. In my eyes, this would be a > static value. The SELinux context could be a compile time argument, > IMHO, which just defines a constant/macro which is when calling > setcon(). Or is it something else I'm missing here? Well... On the one hand supporting an argument has no cost code-wise, on the other hand not offering this liberty might annoy some users. I guess this is the same as with the "user" option, perhaps 99.9% of the people will make OpenVPN run under a "openvpn" user, but some people might find a use in being able to specify another UID... I myself have used features in programs for which the manpage would state "we have no idea why anybody would use this feature" but I needed it and was very greatful that they had implemented it anyway. > If SELinux is found during configure, it could use a hard coded context. If I understand you correctly, that is, if you are suggesting that OpenVPN should automatically apply a SELinux context if setcon() is available... I'll have to disagree with you. Not that I reject the idea of enforcing security measures by default, but because when you google for "selinux howto", half of the first-page results are on how to *disable* SELinux. Apparently not everybody likes it, and they have a right to, so I believe we should not force it upon them :-) Kind regards, -- Sebastien Raveau
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 28/07/09 20:29, Sebastien Raveau wrote: > (Hi again) > > Alon: with all due respect to you and your work - which I am sure is > the best way to go in some situations - I believe that you are wrong > on the topic of maximum security... +1 > First of all, what you're proposing is running OpenVPN as a > not-exactly-unprivileged user (let's call it "least privileged user"), > meaning that your user doesn't have 0 right but "only the right to > modify the routing table". The problem is: in your configuration, this > least privileged user has this write *permanently*, as opposed to > starting OpenVPN as root, letting it use privileges during > initialization and as soon as possible drop to a really-unprivileged > user thanks to setgid/setgroups/setuid (which is what OpenVPN does > when you specify the "user" option). If I understood Alon correctly, he also executes OpenVPN as a less privileged user, meaning that it is impossible to escape out of that user, as the saved UID/GID will be a unprivileged user. But! Chroot will in this setting be impossible, because only root can do chroot(). > As a matter of fact, I'm afraid I would even strongly recommend > _against_ your suggestion, because if some company were to use OpenVPN > on an Internet gateway with your configuration, a hacker would be able > to alter the routing table for the whole company, and hence > transparently redirect employees to phishing websites, just because > your "unprivileged OpenVPN" is allowed to run /sbin/ip with any > parameters at any time (which is a HUGE privilege). +1 ... It is of course possible to tighten this even more, but it will require even more complex efforts to do this right, and it will still not cover all those gaps which SELinux can fill. The user account which openvpn will run as, will still need to run the wrapped ip/iproute commands. Thus you still will have an attack vector. If in addition you have cleverly composed arguments to this wrapper, you might even manage to escape the ip/iproute command and start another program as root, say /bin/sh f.ex. ... or even change the root password to a known password by editing /etc/shadow with a little /usr/bin/sed command. And if openvpn is not started as root, you cannot chroot this process (at least not without having another startup wrapper around openvpn). And this attack vector, only SELinux can cover best, as the security context would be different from what the openvpn process runs with and the permissions needed to run /bin/sh, /usr/bin/sed, or another non-openvpn approved binary. > Now, to transpose that back to SELinux, if the setcon code could be > added inside OpenVPN (next to the setuid and chroot code which have > already been accepted as clearly benefiting) it would be possible to > reduce the SELinux policy for OpenVPN from ~100 lines ( > http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/src/selinux-policy-clip/policy/modules/services/openvpn.te?rev=13 > ) to ~10 !! (basically just the lines allowing network I/O) I still would say that these ~100 lines you link to her, Sebastien, would still be needed. Still not sure how plug-ins would like it with this config. But having a setcon() call inside OpenVPN, is just as beneficial as having setuid(), setgid() and chroot() inside openvpn. And none of these calls makes the other calls less needed. Having that said, most of the policy Sebastian linked to here, covers many of my concerns earlier. Even though how code in plug-ins would be executed (in which context) is more uncertain for me right now. > I totally agree with you however on the "Keep It Simple, Stupid > (KISS)" principle applied to security. I hope that this /10 cut in the > oh-so-complex writing of a SELinux policy proves to you the benefit of > my patch :-) Even though SELinux itself is complex, it doesn't mean that using it is too difficult. Using it properly is more challenging though, compared to not using it. But we don't stop using firewalls because we find it difficult, do we? And nowadays, not many people find firewalling as difficult as 10 years ago. And Alon, to your 3 bullet points ... > As far as I learned, when security is concerned: > 1. Make your solution as simple as possible. > 2. Make the simple solution secure enough. > 3. Enhance the security using security products. I completely agree to you on these points. The thing is that I (and probably also Sebastien) already consider the two first points to be covered pretty well, they are done. Now we just want number 3 closed as well, as this is not implemented at all. Sebastien, back to your patch. There is one thing I've been thinking about today, regarding the --setcon parameter you introduce to the openvpn binary. Why does this need to be a runtime parameter? I cannot imagine you want to run openvpn with different security context on the same box, or even the same Linux distro. In my eyes, this would be a static value. The SELinux context could
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
(Hi again) David: you did not "interrupt badly", on the contrary I am glad that the discussion continued while I was away :-) Alon: with all due respect to you and your work - which I am sure is the best way to go in some situations - I believe that you are wrong on the topic of maximum security... First of all, what you're proposing is running OpenVPN as a not-exactly-unprivileged user (let's call it "least privileged user"), meaning that your user doesn't have 0 right but "only the right to modify the routing table". The problem is: in your configuration, this least privileged user has this write *permanently*, as opposed to starting OpenVPN as root, letting it use privileges during initialization and as soon as possible drop to a really-unprivileged user thanks to setgid/setgroups/setuid (which is what OpenVPN does when you specify the "user" option). I hope you understand that, paradoxically perhaps, the latter is really more secure than the former. As a matter of fact, I'm afraid I would even strongly recommend _against_ your suggestion, because if some company were to use OpenVPN on an Internet gateway with your configuration, a hacker would be able to alter the routing table for the whole company, and hence transparently redirect employees to phishing websites, just because your "unprivileged OpenVPN" is allowed to run /sbin/ip with any parameters at any time (which is a HUGE privilege). Also, speaking of complexity and ease of use, let's pretend we're debating over pre-initialization chroot vs post-initialization, instead of setcon (the SELinux context switch). It is really the same with setuid, but the difference is easier to understand in the case of chroot. Pre-initialization chroot (from the outside of OpenVPN if you will) would require reproducing the filesystem environment OpenVPN will need, which means copying /usr/sbin/openvpn /usr/lib/libpkcs11-helper.so.1 /lib/tls/i686/cmov/libpthread.so.0 /lib/tls/i686/cmov/libc.so.6 /lib/ld-linux.so.2 /lib/tls/i686/cmov/libdl.so.2 /lib/i686/cmov/libcrypto.so.0.9.8 /lib/libz.so.1 /lib/i686/cmov/libssl.so.0.9.8 /usr/lib/liblzo2.so.2 just to get the executable to launch. Then you will most likely need access to at least one of the /dev, /proc and /sys pseudo-filesystems which means you will have to `mount --bind` them in the target directory for your chroot, etc... Post-initialization chroot, for which the code has been added inside OpenVPN (see init.c:392 and misc.c:48) requires none of that and actually does better, as you can have your OpenVPN chroot'ed in a completely empty directory. Now, to transpose that back to SELinux, if the setcon code could be added inside OpenVPN (next to the setuid and chroot code which have already been accepted as clearly benefiting) it would be possible to reduce the SELinux policy for OpenVPN from ~100 lines ( http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/src/selinux-policy-clip/policy/modules/services/openvpn.te?rev=13 ) to ~10 !! (basically just the lines allowing network I/O) I totally agree with you however on the "Keep It Simple, Stupid (KISS)" principle applied to security. I hope that this /10 cut in the oh-so-complex writing of a SELinux policy proves to you the benefit of my patch :-) On Tue, Jul 28, 2009 at 4:20 PM, Alon Bar-Lev wrote: > I don't understand you guys. > > I never said do not use SELinux, or that SELinux does not have advantages. > I know perfectly what the advantages are. > > BUT it is much easier to create profile to unprivileged user that runs > OpenVPN than a profile of a daemon that needs special rights. > > As far as I learned, when security is concerned: > 1. Make your solution as simple as possible. > 2. Make the simple solution secure enough. > 3. Enhance the security using security products. > > When you try to do (3) before (1) you get unmanageable solution, which > in time also results in unsecured solution. > > Just my two cents. > > Alon. > > On Tue, Jul 28, 2009 at 5:05 PM, David > Sommerseth wrote: >> >> >> Alon Bar-Lev wrote: >>> >>> I do not understand, but it looks that two of you are searching for a >>> solution inside the box, while the solution is out side the box. >>> >>> I added the ability for OpenVPN to run using unprivileged user, yes, >>> please read it as-is, unprivileged user!!! >>> This means that you don't need any special permission to run OpenVPN. >>> >>> How did I manage to do this? >>> >>> Simply, >>> 1. Linux's tun device access may be enabled to a specific user or group. >>> 2. Wrap iproute2 calls. >> >> This is not what SELinux primarily solves, even though it also solves this >> too. But it can restrict access to resources OpenVPN initially should only >> have. >> >> OpenVPN depends on devices in kernel space, even if you restrict that on the >> "normal" file system level (chmod 600 /dev/net/tun*), a bug/exploit in the >> device being used can still be used for privilege escalation. This is one >> of the attack vectors SELinux tr
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
I don't understand you guys. I never said do not use SELinux, or that SELinux does not have advantages. I know perfectly what the advantages are. BUT it is much easier to create profile to unprivileged user that runs OpenVPN than a profile of a daemon that needs special rights. As far as I learned, when security is concerned: 1. Make your solution as simple as possible. 2. Make the simple solution secure enough. 3. Enhance the security using security products. When you try to do (3) before (1) you get unmanageable solution, which in time also results in unsecured solution. Just my two cents. Alon. On Tue, Jul 28, 2009 at 5:05 PM, David Sommerseth wrote: > > > Alon Bar-Lev wrote: >> >> I do not understand, but it looks that two of you are searching for a >> solution inside the box, while the solution is out side the box. >> >> I added the ability for OpenVPN to run using unprivileged user, yes, >> please read it as-is, unprivileged user!!! >> This means that you don't need any special permission to run OpenVPN. >> >> How did I manage to do this? >> >> Simply, >> 1. Linux's tun device access may be enabled to a specific user or group. >> 2. Wrap iproute2 calls. > > This is not what SELinux primarily solves, even though it also solves this > too. But it can restrict access to resources OpenVPN initially should only > have. > > OpenVPN depends on devices in kernel space, even if you restrict that on the > "normal" file system level (chmod 600 /dev/net/tun*), a bug/exploit in the > device being used can still be used for privilege escalation. This is one > of the attack vectors SELinux tries to solve. It makes sure the application > do not get access to devices, files, processes, etc which is not defined in > the security context - because this is possible attack vectors. > >> I am not against SELinux usage in OpenVPN. I just want you to be aware >> that there is alternatives that can use OpenVPN without any special >> right. > > Agreed, there are plenty of alternatives, but they only focus on the > user-space area primarily, not kernel space. In the wrapper you suggest, > there is nothing here protecting against malformed information being sent to > the wrapper around iproute2, combine that with some buffer overflows bugs in > iproute2, and you have yet another attack vector. Take a look after the > latest cheddar_bay exploit being found recently. Here several small flaws > are used together to gain root shell access on a vulnerable system. > > SELinux will make it more difficult, as it is even more tricky to disable > the SELinux controll mechanism on the way. > > > Kind regards, > > David Sommerseth > > >> On Tue, Jul 28, 2009 at 4:28 PM, David >> Sommerseth wrote: >>> >>> Alon Bar-Lev wrote: I do not understand either. If you run OpenVPN from unprivileged user from startup, this apposed of letting OpenVPN to setuid(), what do you need to protect in middle of operation? On Tue, Jul 28, 2009 at 11:33 AM, Sebastien Raveau wrote: > > I'm not sure I understand you... > > As I explained in > http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed > possible to apply SELinux "from the outside" of a program, like > chroot, and just like chroot doing that is less efficient and less > practical. > >>> I hope I'm not interrupting badly now. >>> >>> A little basic part, for those wanting to understand the depths. What >>> SELinux provides is access control on different kind of layers inside the >>> kernel space, also on system calls. For a brief overview over SELinux, >>> have >>> a look here: >>> http://www.ibm.com/developerworks/linux/library/l-sppriv.html, >>> >>> http://www.ibm.com/developerworks/linux/library/l-selinux/index.html?S_TACT=105AGX03&S_CMP=EDU >>> (A lot of more good SELinux information is available on IBM's >>> developerWorks >>> site) >>> >>> It makes sense to do a security context switch after OpenVPN has >>> initialised >>> and chrooted, then changing security context and drop the rest of the >>> privileges. In the new OpenVPN security context, it should then not be >>> allowed to do any chrooting or network configuration (as this is a part >>> of >>> the initialisation, IMO), and even if possible, setuid() should be >>> disallowed. That way you can really lock down everything OpenVPN should >>> not >>> do - just allowing what it needs to do. Basically, the OpenVPN security >>> context should only be allowed to write to log files, execute code in >>> plug-ins, read a limited range of files, and read/write to a network >>> device >>> granting access to the openvpn context. >>> >>> What I am lacking in this patch, is a security context definition (at >>> least >>> an example of how to configure a proper context for OpenVPN). Further; >>> has >>> it been investigated if there need to be done some other context changes >>> to >>> the TUN/TAP devices? What about other files? If a log file
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Alon Bar-Lev wrote: I do not understand, but it looks that two of you are searching for a solution inside the box, while the solution is out side the box. I added the ability for OpenVPN to run using unprivileged user, yes, please read it as-is, unprivileged user!!! This means that you don't need any special permission to run OpenVPN. How did I manage to do this? Simply, 1. Linux's tun device access may be enabled to a specific user or group. 2. Wrap iproute2 calls. This is not what SELinux primarily solves, even though it also solves this too. But it can restrict access to resources OpenVPN initially should only have. OpenVPN depends on devices in kernel space, even if you restrict that on the "normal" file system level (chmod 600 /dev/net/tun*), a bug/exploit in the device being used can still be used for privilege escalation. This is one of the attack vectors SELinux tries to solve. It makes sure the application do not get access to devices, files, processes, etc which is not defined in the security context - because this is possible attack vectors. I am not against SELinux usage in OpenVPN. I just want you to be aware that there is alternatives that can use OpenVPN without any special right. Agreed, there are plenty of alternatives, but they only focus on the user-space area primarily, not kernel space. In the wrapper you suggest, there is nothing here protecting against malformed information being sent to the wrapper around iproute2, combine that with some buffer overflows bugs in iproute2, and you have yet another attack vector. Take a look after the latest cheddar_bay exploit being found recently. Here several small flaws are used together to gain root shell access on a vulnerable system. SELinux will make it more difficult, as it is even more tricky to disable the SELinux controll mechanism on the way. Kind regards, David Sommerseth On Tue, Jul 28, 2009 at 4:28 PM, David Sommerseth wrote: Alon Bar-Lev wrote: I do not understand either. If you run OpenVPN from unprivileged user from startup, this apposed of letting OpenVPN to setuid(), what do you need to protect in middle of operation? On Tue, Jul 28, 2009 at 11:33 AM, Sebastien Raveau wrote: I'm not sure I understand you... As I explained in http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed possible to apply SELinux "from the outside" of a program, like chroot, and just like chroot doing that is less efficient and less practical. I hope I'm not interrupting badly now. A little basic part, for those wanting to understand the depths. What SELinux provides is access control on different kind of layers inside the kernel space, also on system calls. For a brief overview over SELinux, have a look here: http://www.ibm.com/developerworks/linux/library/l-sppriv.html, http://www.ibm.com/developerworks/linux/library/l-selinux/index.html?S_TACT=105AGX03&S_CMP=EDU (A lot of more good SELinux information is available on IBM's developerWorks site) It makes sense to do a security context switch after OpenVPN has initialised and chrooted, then changing security context and drop the rest of the privileges. In the new OpenVPN security context, it should then not be allowed to do any chrooting or network configuration (as this is a part of the initialisation, IMO), and even if possible, setuid() should be disallowed. That way you can really lock down everything OpenVPN should not do - just allowing what it needs to do. Basically, the OpenVPN security context should only be allowed to write to log files, execute code in plug-ins, read a limited range of files, and read/write to a network device granting access to the openvpn context. What I am lacking in this patch, is a security context definition (at least an example of how to configure a proper context for OpenVPN). Further; has it been investigated if there need to be done some other context changes to the TUN/TAP devices? What about other files? If a log file is labelled var_log_t, will the new openvpn security context be allowed to write to this log file? How would this work with the security context of the directory of the log file? (It might be that the easy approach would to do logging via syslog()) Then what about plug-ins, how would OpenVPN work in these settings when the SELinux context is changed? F.ex. how would this patch work against the down-root.so plugin? I do agree, implementing SELinux in the openvpn code is an important step! But it seems to be just too easy to do setcon(). It is just missing a consequence analysis of what else needs to be changed in addition to this patch. I'm not an SELinux expert, and Sebastien might know far more about SElinux than anyone of us. I don't want to trample on anyone feet ... but I just wanted to have clarified these issues before I can give 100% support to this patch, as it just seemed to be too easy. -- kind regards, David Sommerseth
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
I do not understand, but it looks that two of you are searching for a solution inside the box, while the solution is out side the box. I added the ability for OpenVPN to run using unprivileged user, yes, please read it as-is, unprivileged user!!! This means that you don't need any special permission to run OpenVPN. How did I manage to do this? Simply, 1. Linux's tun device access may be enabled to a specific user or group. 2. Wrap iproute2 calls. So I run OpenVPN completely in unprivileged mode, it can access the tun device, then when it wish to alter network configuration it can do so by the wrapper (I used sudo for this). Most OpenVPN configuration requires more than one time network settings. In stead of sudo wrapper you can use SELinux enabled wrapper. The advantage of sudo wrapper is that it is simple, and the script can check if the new network configuration is valid for OpenVPN usage. I am not against SELinux usage in OpenVPN. I just want you to be aware that there is alternatives that can use OpenVPN without any special right. Alon. On Tue, Jul 28, 2009 at 4:28 PM, David Sommerseth wrote: > Alon Bar-Lev wrote: >> >> I do not understand either. >> >> If you run OpenVPN from unprivileged user from startup, this apposed >> of letting OpenVPN to setuid(), what do you need to protect in middle >> of operation? >> >> On Tue, Jul 28, 2009 at 11:33 AM, Sebastien >> Raveau wrote: >>> >>> I'm not sure I understand you... >>> >>> As I explained in >>> http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed >>> possible to apply SELinux "from the outside" of a program, like >>> chroot, and just like chroot doing that is less efficient and less >>> practical. >>> > > I hope I'm not interrupting badly now. > > A little basic part, for those wanting to understand the depths. What > SELinux provides is access control on different kind of layers inside the > kernel space, also on system calls. For a brief overview over SELinux, have > a look here: http://www.ibm.com/developerworks/linux/library/l-sppriv.html, > http://www.ibm.com/developerworks/linux/library/l-selinux/index.html?S_TACT=105AGX03&S_CMP=EDU > (A lot of more good SELinux information is available on IBM's developerWorks > site) > > It makes sense to do a security context switch after OpenVPN has initialised > and chrooted, then changing security context and drop the rest of the > privileges. In the new OpenVPN security context, it should then not be > allowed to do any chrooting or network configuration (as this is a part of > the initialisation, IMO), and even if possible, setuid() should be > disallowed. That way you can really lock down everything OpenVPN should not > do - just allowing what it needs to do. Basically, the OpenVPN security > context should only be allowed to write to log files, execute code in > plug-ins, read a limited range of files, and read/write to a network device > granting access to the openvpn context. > > What I am lacking in this patch, is a security context definition (at least > an example of how to configure a proper context for OpenVPN). Further; has > it been investigated if there need to be done some other context changes to > the TUN/TAP devices? What about other files? If a log file is labelled > var_log_t, will the new openvpn security context be allowed to write to this > log file? How would this work with the security context of the directory of > the log file? (It might be that the easy approach would to do logging via > syslog()) Then what about plug-ins, how would OpenVPN work in these > settings when the SELinux context is changed? F.ex. how would this patch > work against the down-root.so plugin? > > I do agree, implementing SELinux in the openvpn code is an important step! > But it seems to be just too easy to do setcon(). It is just missing a > consequence analysis of what else needs to be changed in addition to this > patch. > > I'm not an SELinux expert, and Sebastien might know far more about SElinux > than anyone of us. I don't want to trample on anyone feet ... but I just > wanted to have clarified these issues before I can give 100% support to this > patch, as it just seemed to be too easy. > > > -- > kind regards, > > David Sommerseth > > >
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Alon Bar-Lev wrote: I do not understand either. If you run OpenVPN from unprivileged user from startup, this apposed of letting OpenVPN to setuid(), what do you need to protect in middle of operation? On Tue, Jul 28, 2009 at 11:33 AM, Sebastien Raveau wrote: I'm not sure I understand you... As I explained in http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed possible to apply SELinux "from the outside" of a program, like chroot, and just like chroot doing that is less efficient and less practical. I hope I'm not interrupting badly now. A little basic part, for those wanting to understand the depths. What SELinux provides is access control on different kind of layers inside the kernel space, also on system calls. For a brief overview over SELinux, have a look here: http://www.ibm.com/developerworks/linux/library/l-sppriv.html, http://www.ibm.com/developerworks/linux/library/l-selinux/index.html?S_TACT=105AGX03&S_CMP=EDU (A lot of more good SELinux information is available on IBM's developerWorks site) It makes sense to do a security context switch after OpenVPN has initialised and chrooted, then changing security context and drop the rest of the privileges. In the new OpenVPN security context, it should then not be allowed to do any chrooting or network configuration (as this is a part of the initialisation, IMO), and even if possible, setuid() should be disallowed. That way you can really lock down everything OpenVPN should not do - just allowing what it needs to do. Basically, the OpenVPN security context should only be allowed to write to log files, execute code in plug-ins, read a limited range of files, and read/write to a network device granting access to the openvpn context. What I am lacking in this patch, is a security context definition (at least an example of how to configure a proper context for OpenVPN). Further; has it been investigated if there need to be done some other context changes to the TUN/TAP devices? What about other files? If a log file is labelled var_log_t, will the new openvpn security context be allowed to write to this log file? How would this work with the security context of the directory of the log file? (It might be that the easy approach would to do logging via syslog()) Then what about plug-ins, how would OpenVPN work in these settings when the SELinux context is changed? F.ex. how would this patch work against the down-root.so plugin? I do agree, implementing SELinux in the openvpn code is an important step! But it seems to be just too easy to do setcon(). It is just missing a consequence analysis of what else needs to be changed in addition to this patch. I'm not an SELinux expert, and Sebastien might know far more about SElinux than anyone of us. I don't want to trample on anyone feet ... but I just wanted to have clarified these issues before I can give 100% support to this patch, as it just seemed to be too easy. -- kind regards, David Sommerseth
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
I do not understand either. If you run OpenVPN from unprivileged user from startup, this apposed of letting OpenVPN to setuid(), what do you need to protect in middle of operation? On Tue, Jul 28, 2009 at 11:33 AM, Sebastien Raveau wrote: > I'm not sure I understand you... > > As I explained in > http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed > possible to apply SELinux "from the outside" of a program, like > chroot, and just like chroot doing that is less efficient and less > practical. > > On Tue, Jul 28, 2009 at 10:18 AM, Alon Bar-Lev wrote: >> Do that. >> But as in this case OpenVPN does not run under privilege account at >> any time, you can do this simply without any selinux code into VPN. >> >> On Tue, Jul 28, 2009 at 11:12 AM, Sebastien >> Raveau wrote: >>> On Tue, Jul 28, 2009 at 9:59 AM, Alon Bar-Lev wrote: Why don't you use openvpn in completely unprivileged mode? Look at [1] search for Unprivileged mode. [1] http://openvpn.net/index.php/open-source/documentation/howto.html#security >>> >>> What makes you think I don't already? :-) >>> >>> I do, and it is *not* sufficient as this does not protect against >>> kernel exploits. If a hacker manages to perform remote code execution >>> in OpenVPN and thus exploit a vulnerable system call, (s)he obtains >>> kernel privileges and all of a sudden all your setuid, chroot etc are >>> useless... >>> >>> This can be countered with SELinux (and equivalents such as >>> GRSecurity, RSBAC, LIDS etc) basically by applying access control on >>> system calls. >>> >>> >>> Kind regards, >>> >>> -- >>> Sebastien Raveau >>> >> > > > > -- > Sebastien Raveau >
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
I'm not sure I understand you... As I explained in http://article.gmane.org/gmane.network.openvpn.devel/2700 it is indeed possible to apply SELinux "from the outside" of a program, like chroot, and just like chroot doing that is less efficient and less practical. On Tue, Jul 28, 2009 at 10:18 AM, Alon Bar-Lev wrote: > Do that. > But as in this case OpenVPN does not run under privilege account at > any time, you can do this simply without any selinux code into VPN. > > On Tue, Jul 28, 2009 at 11:12 AM, Sebastien > Raveau wrote: >> On Tue, Jul 28, 2009 at 9:59 AM, Alon Bar-Lev wrote: >>> Why don't you use openvpn in completely unprivileged mode? >>> Look at [1] search for Unprivileged mode. >>> [1] >>> http://openvpn.net/index.php/open-source/documentation/howto.html#security >> >> What makes you think I don't already? :-) >> >> I do, and it is *not* sufficient as this does not protect against >> kernel exploits. If a hacker manages to perform remote code execution >> in OpenVPN and thus exploit a vulnerable system call, (s)he obtains >> kernel privileges and all of a sudden all your setuid, chroot etc are >> useless... >> >> This can be countered with SELinux (and equivalents such as >> GRSecurity, RSBAC, LIDS etc) basically by applying access control on >> system calls. >> >> >> Kind regards, >> >> -- >> Sebastien Raveau >> > -- Sebastien Raveau
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Do that. But as in this case OpenVPN does not run under privilege account at any time, you can do this simply without any selinux code into VPN. On Tue, Jul 28, 2009 at 11:12 AM, Sebastien Raveau wrote: > On Tue, Jul 28, 2009 at 9:59 AM, Alon Bar-Lev wrote: >> Why don't you use openvpn in completely unprivileged mode? >> Look at [1] search for Unprivileged mode. >> [1] >> http://openvpn.net/index.php/open-source/documentation/howto.html#security > > What makes you think I don't already? :-) > > I do, and it is *not* sufficient as this does not protect against > kernel exploits. If a hacker manages to perform remote code execution > in OpenVPN and thus exploit a vulnerable system call, (s)he obtains > kernel privileges and all of a sudden all your setuid, chroot etc are > useless... > > This can be countered with SELinux (and equivalents such as > GRSecurity, RSBAC, LIDS etc) basically by applying access control on > system calls. > > > Kind regards, > > -- > Sebastien Raveau >
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On Tue, Jul 28, 2009 at 9:59 AM, Alon Bar-Lev wrote: > Why don't you use openvpn in completely unprivileged mode? > Look at [1] search for Unprivileged mode. > [1] http://openvpn.net/index.php/open-source/documentation/howto.html#security What makes you think I don't already? :-) I do, and it is *not* sufficient as this does not protect against kernel exploits. If a hacker manages to perform remote code execution in OpenVPN and thus exploit a vulnerable system call, (s)he obtains kernel privileges and all of a sudden all your setuid, chroot etc are useless... This can be countered with SELinux (and equivalents such as GRSecurity, RSBAC, LIDS etc) basically by applying access control on system calls. Kind regards, -- Sebastien Raveau
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Hello, Why don't you use openvpn in completely unprivileged mode? Look at [1] search for Unprivileged mode. OpenVPN can access tun device as regular user, execute iproute2 using sudo wrapper or any other wrapper you supply. Alon [1] http://openvpn.net/index.php/open-source/documentation/howto.html#security On Tue, Jul 28, 2009 at 10:49 AM, Sebastien Raveau wrote: > > Hi! > > Pardon me for asking but... I see you guys talking about a new release > candidate, and I am still without news about my contribution to > OpenVPN that I submitted one month ago: > http://article.gmane.org/gmane.network.openvpn.devel/2700 > > Is there something wrong about it? > > -- > Sebastien Raveau > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Hi! Pardon me for asking but... I see you guys talking about a new release candidate, and I am still without news about my contribution to OpenVPN that I submitted one month ago: http://article.gmane.org/gmane.network.openvpn.devel/2700 Is there something wrong about it? -- Sebastien Raveau
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Am 16.07.2009, 23:24 Uhr, schrieb James Yonan : Dear Jim, This is backwards. Please don't do that, but revert that change and instead update the argument of AC_PREREQ in configure.ac to read this: AC_PREREQ(2.60) Since you're using autoconf/automake, configure.ac changes and requirements have zero impact on end users who download the tarball that you generate through "make dist". Such changes only affects developers who want to hack configure.ac or use the SVN version, and you can simply expect them to have an autoconf version no older than 36 months. In my experience, newer autoconf versions are more portable, have less bugs, and are good for a much smoother ride than older versions. I'm happy to look into updating configure.ac, which in general needs an overhaul anyways - unless you say "no configure.ac updates before 2.1 release". We need to be able to build OpenVPN on older Linux distros, such as RHEL 4, that use pre-2.60 versions of autoconf. Before I made this change, I found that the previous code (using datarootdir instead of datadir on RHEL 4, autoconf-2.59-5) would generate a make install script that violated the --prefix argument -- i.e. make install would try to write stuff outside the --prefix dir. I was running the make install as a non-root user, so the jailbreak out of --prefix was obvious because it tried to write to parts of the filesystem that generated "permission denied" errors and halted the script. I'm not an autoconf/automake expert, so if there's a better way to fix the issue, I'm open to it. I don't know your build procedure. If you're building from a tarball, you should never need to run autoconf, and you don't even need it installed. The GNU autotools "make dist" rolls the maintainer-generated files such as configure and Makefile.in into the tarball, as well as required scripts such as install-sh. So I'd probably do something like this: 1 - on a system that has autoconf >= 2.60, check out the code from SVN and run autoreconf 2 - configure (you need not use the same operating system to do that), then "make dist" 3 - copy the openvpn-$version.tar.gz to RHEL 4 4 - run rpmbuild -tb --sign openvpn-$version.tar.gz (use rpm on older RPM versions that don't have the rpmbuild executable) NFS mounts can make things even more convenient. On several projects, I use Makefile.am snippets like these: # this target expects a .rsyncs file with lines of this format: # host:directory/ # it will call rsync from a freshly populated dist directory # to the destination for each of the lines, running them in parallel rsync: distdir $(srcdir)/.rsyncs @( cat $(srcdir)/.rsyncs | sed -e 's}^}rsync -aH --delete-after $(PACKAGE)-$(VERSION)/ }; s/\($$\)/ \&/;' ; echo "wait" ) \ | $(SHELL) -x and .rsync is something like this: m...@host1.example.org:/var/tmp/ma/fetchmail mand...@host2.example.com:/home/mandree/tmp/fetchmail then "make rsync" will refresh the mentioned directories on said hosts as though a fresh tarball had just been unpacked into a clean directory, so you only need to log into host1... or host2... I also commonly do VPATH builds on those hosts, so that I can update without losing the object files that need not be recompiled, that goes like - for example on host1: cd /var/tmp/ma mkdir -p build-fetchmail cd build-fetchmail ../fetchmail/configure -C --what-ever-option-you-want make This is a convenience feature for testing. - Most useful if you can authenticate without password; if you can't, remove the s/\($$\)/ \&/; from sed and the echo "wait" from the subshell to serialize the rsync operations. HTH -- Matthias Andree
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On 07/16/2009 04:24:44 PM, James Yonan wrote: Matthias Andree wrote: > James Yonan schrieb: > >> 2009.07.16 -- Version 2.1_rc19 > ... > >> * In configure.ac, use datadir instead of datarootdir for compatibility >>with > Dear Jim, > > This is backwards. Please don't do that, We need to be able to build OpenVPN on older Linux distros, such as RHEL 4, that use pre-2.60 versions of autoconf. I don't know about earlier, but autoconf 2.59 comes with # m4_version_prereq(VERSION, [IF-OK], [IF-NOT = FAIL]) # # Check this Autoconf version against VERSION. AFICT this can be used to do things one way with older versions and another with newer. m4_version_preqreq(`2.60', datarootdir, datadir) I can't say whether this is actually a better way to do things. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
Matthias Andree wrote: James Yonan schrieb: 2009.07.16 -- Version 2.1_rc19 ... * In configure.ac, use datadir instead of datarootdir for compatibility with Dear Jim, This is backwards. Please don't do that, but revert that change and instead update the argument of AC_PREREQ in configure.ac to read this: AC_PREREQ(2.60) Since you're using autoconf/automake, configure.ac changes and requirements have zero impact on end users who download the tarball that you generate through "make dist". Such changes only affects developers who want to hack configure.ac or use the SVN version, and you can simply expect them to have an autoconf version no older than 36 months. In my experience, newer autoconf versions are more portable, have less bugs, and are good for a much smoother ride than older versions. I'm happy to look into updating configure.ac, which in general needs an overhaul anyways - unless you say "no configure.ac updates before 2.1 release". We need to be able to build OpenVPN on older Linux distros, such as RHEL 4, that use pre-2.60 versions of autoconf. Before I made this change, I found that the previous code (using datarootdir instead of datadir on RHEL 4, autoconf-2.59-5) would generate a make install script that violated the --prefix argument -- i.e. make install would try to write stuff outside the --prefix dir. I was running the make install as a non-root user, so the jailbreak out of --prefix was obvious because it tried to write to parts of the filesystem that generated "permission denied" errors and halted the script. I'm not an autoconf/automake expert, so if there's a better way to fix the issue, I'm open to it. James
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
James Yonan schrieb: > 2009.07.16 -- Version 2.1_rc19 ... > * In configure.ac, use datadir instead of datarootdir for compatibility >with