Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On Wed, Jul 29, 2009 at 6:47 AM, Alon Bar-Lev<alon.bar...@gmail.com> 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
ut 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<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_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 >>>> >>>> >>>> >> > -- 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<alon.bar...@gmail.com> 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<sebastien.rav...@epita.fr> wrote: >> On Tue, Jul 28, 2009 at 9:59 AM, Alon Bar-Lev<alon.bar...@gmail.com> 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
[Openvpn-devel] [PATCH] Post-initialization SELinux support for OpenVPN
Hi everybody!
OpenVPN already has support for dropping privileges and confining
itself to a directory *after* startup (thanks to calls like setgid,
setuid and chroot) which makes for much better management than if you
had to respectively start OpenVPN unprivileged and add the privileges
it (only) needs during startup, or if you chroot'ed OpenVPN before
startup and had to copy the necessary files in the confinement
directory.
The very same problem occurs with SELinux policy enforcement: one can
apply a policy before startup (such as the ready-to-use one provided
by
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/openvpn.te)
but it is wy too complicated, just because many rights have to be
granted to OpenVPN during its initialization... or one can apply a
very simple SELinux policy to OpenVPN when the only need left is
basically network I/O operations.
The only downside to this is that, just like with setuid() and
chroot(), OpenVPN has to call setcon() itself, which is why I am
submitting this patch :-)
Please note that, while this patch does indeed bring a new dependency
to libselinux in OpenVPN on Linux:
* the feature will of course only be added if detected by ./configure
* libselinux is so common now that even /bin/ls is linked against it
on most Linux systems
so OpenVPN should get SELinux support quite transparently ;-)
Best regards,
--
Sebastien Raveau
Information Warfare Consultant
http://blog.sebastien.raveau.name/
diff -urN -X generated openvpn-2.0.9.orig/configure.ac openvpn-2.0.9/configure.ac
--- openvpn-2.0.9.orig/configure.ac 2006-10-01 14:18:15.0 +0200
+++ openvpn-2.0.9/configure.ac 2009-06-22 22:42:30.0 +0200
@@ -95,6 +95,12 @@
[DEBUG="yes"]
)
+AC_ARG_ENABLE(selinux,
+ [ --disable-selinux Disable SELinux support],
+ [SELINUX="$enableval"],
+ [SELINUX="yes"]
+)
+
AC_ARG_ENABLE(small,
[ --enable-small Enable smaller executable size (disable OCC, usage message, and verb 4 parm list)],
[SMALL="$enableval"],
@@ -568,6 +574,23 @@
fi
fi
+dnl
+dnl check for SELinux library and headers
+dnl
+if test "$SELINUX" = "yes"; then
+ AC_CHECKING([for libselinux Library and Header files])
+ AC_CHECK_HEADER(selinux/selinux.h,
+ [AC_CHECK_LIB(selinux, setcon,
+ [
+OPENVPN_ADD_LIBS(-lselinux)
+AC_DEFINE(HAVE_SETCON, 1, [SELinux support])
+ ],
+[AC_MSG_RESULT([SELinux library not found.])]
+ )],
+ [AC_MSG_RESULT([SELinux headers not found.])]
+ )
+fi
+
dnl enable multi-client mode
if test "$MULTI" = "yes"; then
AC_DEFINE(ENABLE_CLIENT_SERVER, 1, [Enable client/server capability])
diff -urN -X generated openvpn-2.0.9.orig/init.c openvpn-2.0.9/init.c
--- openvpn-2.0.9.orig/init.c 2006-04-05 08:42:32.0 +0200
+++ openvpn-2.0.9/init.c 2009-06-22 22:42:30.0 +0200
@@ -405,6 +405,17 @@
{
msg (M_INFO, "NOTE: UID/GID downgrade %s", why_not);
}
+
+ /* set SELinux context; doing it after chroot requires /proc
+ to be mounted in the chroot (which is annoying indeed but
+ doing it before requires more complex SELinux policies */
+ if (c->options.selinux_context)
+{
+ if (no_delay)
+do_setcon(c->options.selinux_context);
+ else
+msg (M_INFO, "NOTE: setcon %s", why_not);
+}
}
}
@@ -1563,8 +1574,8 @@
if (o->ping_send_timeout && !o->ping_rec_timeout)
msg (M_WARN, "WARNING: --ping should normally be used with --ping-restart or --ping-exit");
- if ((o->username || o->groupname || o->chroot_dir) && (!o->persist_tun || !o->persist_key))
-msg (M_WARN, "WARNING: you are using user/group/chroot without persist-key/persist-tun -- this may cause restarts to fail");
+ if ((o->username || o->groupname || o->chroot_dir || o->selinux_context) && (!o->persist_tun || !o->persist_key))
+msg (M_WARN, "WARNING: you are using user/group/chroot/setcon without persist-key/persist-tun -- this may cause restarts to fail");
#if P2MP
if (o->pull && o->ifconfig_local && c->first_time)
diff -urN -X generated openvpn-2.0.9.orig/misc.c openvpn-2.0.9/misc.c
--- openvpn-2.0.9.orig/misc.c 2005-11-05 08:04:22.0 +0100
+++ openvpn-2.0.9/misc.c 2009-06-22 23:00:36.0 +0200
@@ -62,6 +62,25 @@
}
}
+/* Apply SELinux context in order to restrict what
+ OpenVPN can do to _only_ what it is supposed to
+ do after initialization is complete (basically
+ network I/O operations) */
+void
+do_setcon (const char *context)
+{
+ if (context)
+{
+#ifdef HAVE_SETCON
+ if (-1 == setcon (context))
+msg (M_ERR, "setcon to '%s' failed; is /proc accessible?", context);
