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<openvpn.l...@topphemmelig.net> 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<sebastien.rav...@epita.fr> 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 > > >
