Thanks for your support :-)
On Tue, Jul 28, 2009 at 10:45 PM, David Sommerseth<openvpn.l...@topphemmelig.net> 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
