Re: [Openvpn-devel] Options that are "safe" for users to modify?
Hi, On Sat, Dec 12, 2015 at 4:47 PM, Jonathan K. Bullard wrote: > > My tentative plan is to allow users to update without authorization > any files that are the "targets" of the following options: > I suppose, not just adding but also removing options will be allowed. There could be more options that are ok (i.e not unsafe) to remove but not change. > --askpass > --auth-user-pass > --ca > --cert > --dh > --extra-certs > --key > --pkcs1 > --static > --ta > --tls-auth --ta ? As remote cant change, several more options may be safe, though note necessarily very useful. Here are a couple of options that could help when the server is updated, for example --topology t (mainly to remove from client so that a new setting at the server can take effect through push -- say moving from net30 to subnet) --comp-lzo --secret (for non-tls) --auth --cipher Selva
Re: [Openvpn-devel] Options that are "safe" for users to modify?
Hi. On Sat, Dec 12, 2015 at 5:23 PM, Arne Schwabe wrote: > Might not really be related to this but have looked into the work that > provides the certificates and keys via the managment console? We have > even have a contrib program that gets certificates from the Mac OS X > keychain and provides them to OpenVPN. Thanks, but I think that should be a separate discussion. That would work for some situations, but the keychain (actually, OS X has several keychains) may not be accessible to OpenVPN; files are always accessible, even before a user is logged in. And I don't think (I'm doing this from memory, so I might be wrong) that the Keychain patch allows **all** of the encryption info to be taken from the keychain: I don't think it allows --secret, --ta, etc.
Re: [Openvpn-devel] Options that are "safe" for users to modify?
Am 12.12.15 um 22:47 schrieb Jonathan K. Bullard: > Inspired by Gert, I am considering adding a new feature to Tunnelblick > (FOSS GUI for OpenVPN on OS X) and would like your reactions. In an > earlier thread on openvpn-users, my original more grandiose idea was > (with good reason) NAKed. It was also suggested that openvpn-devel was > a better place for the discussion. > > The goal is to allow a non-admin to update keys and certificates > without needing the admin authorization that is currently required by > Tunnelblick. Changing Tunnelblick so that it runs OpenVPN as the user > is one way of doing that, but is much more work and has broader > consequences than what I am proposing and I'd like to avoid discussion > of that in this thread if possible. > > Tunnelblick currently "secures" OpenVPN configuration files and the > files they reference (e.g., "targets" of --ca, --key, etc.) by making > them writable only by root. A user can change a configuration only by > getting admin authorization. (Some files may be readable only by root, > too, but that's not relevant here.) Might not really be related to this but have looked into the work that provides the certificates and keys via the managment console? We have even have a contrib program that gets certificates from the Mac OS X keychain and provides them to OpenVPN. Arne
[Openvpn-devel] Options that are "safe" for users to modify?
Inspired by Gert, I am considering adding a new feature to Tunnelblick (FOSS GUI for OpenVPN on OS X) and would like your reactions. In an earlier thread on openvpn-users, my original more grandiose idea was (with good reason) NAKed. It was also suggested that openvpn-devel was a better place for the discussion. The goal is to allow a non-admin to update keys and certificates without needing the admin authorization that is currently required by Tunnelblick. Changing Tunnelblick so that it runs OpenVPN as the user is one way of doing that, but is much more work and has broader consequences than what I am proposing and I'd like to avoid discussion of that in this thread if possible. Tunnelblick currently "secures" OpenVPN configuration files and the files they reference (e.g., "targets" of --ca, --key, etc.) by making them writable only by root. A user can change a configuration only by getting admin authorization. (Some files may be readable only by root, too, but that's not relevant here.) What I am proposing is for Tunnelblick to allow the user to replace certain files referred to in a configuration without admin authorization. This would be done by allowing changes to files referenced by options that are on a whitelist. So what options should go on that whitelist? My tentative plan is to allow users to update without authorization any files that are the "targets" of the following options: --askpass --auth-user-pass --ca --cert --dh --extra-certs --key --pkcs1 --static --ta --tls-auth I'm not proposing to let the user modify the files directly -- they would continue to be writable only by root. The files would be modified by the same privileged Tunnelblick daemon that starts OpenVPN as root ( and which will enforce the restrictions). The original implementation would only replace files but it could be extended to replace inline options in the configuration file itself, too. My hope is that it would be "safe" to allow this, in the sense that the user couldn't get themselves into much trouble: no escalation of privileges, no messing up routing tables, etc. I think the worst that could happen is that a configuration would stop working. (But I'd like some reassurance that that is true, which is why I'm asking for your advice.) For anyone interested, it would work like this: the simplest Tunnelblick configuration is a folder with an extension of ".tblk" that contain one .ovpn file and all the files referred to in that file. A Tunnelblick configuration is installed or replaced by double-clicking it, which invokes Tunnelblick to do the installation/replacement. Currently, installing or replacing (or deleting) a Tunnelblick configuration requires getting authorization from an admin; the plan is to skip the authorization if replacing and the only changes are to files as described above. So double-clicking a .tblk for the original installation would need admin authorization, but double-clicking it to replace a configuration would not, as long as the only changes were to the files described above. Double-clicking a replacement .tblk that includes a modified OpenVPN configuration file itself (or script files, etc.) would continue to require admin authorization. System admins would distribute a single .tblk that could be used to do either an original install or a replacement; Tunnelblick would figure out which it was and get authorization or not. The ability to do these non-admin-authorized replacements would be disabled by default and would need to be authorized by an admin, so it would only work for users if the admin wants it to. Reactions? Thanks in advance. (Oh, and please don't blame Gert for any of this; any good ideas are his but I'm to blame for any bad ones : )
[Openvpn-devel] [PATCH] Pass adapter index to up/down scripts
Trac #637
Signed-off-by: Lev Stipakov
---
src/openvpn/init.c | 18 ++
src/openvpn/misc.c | 6 ++
src/openvpn/misc.h | 3 +++
3 files changed, 27 insertions(+)
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 179c7ef..b0c0e26 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1485,6 +1485,9 @@ do_open_tun (struct context *c)
c->plugins,
OPENVPN_PLUGIN_UP,
c->c1.tuntap->actual_name,
+#ifdef WIN32
+ c->c1.tuntap->adapter_index,
+#endif
dev_type_string (c->options.dev, c->options.dev_type),
TUN_MTU_SIZE (&c->c2.frame),
EXPANDED_SIZE (&c->c2.frame),
@@ -1526,6 +1529,9 @@ do_open_tun (struct context *c)
c->plugins,
OPENVPN_PLUGIN_UP,
c->c1.tuntap->actual_name,
+#ifdef WIN32
+c->c1.tuntap->adapter_index,
+#endif
dev_type_string (c->options.dev, c->options.dev_type),
TUN_MTU_SIZE (&c->c2.frame),
EXPANDED_SIZE (&c->c2.frame),
@@ -1564,6 +1570,9 @@ do_close_tun (struct context *c, bool force)
if (c->c1.tuntap && c->c1.tuntap_owned)
{
const char *tuntap_actual = string_alloc (c->c1.tuntap->actual_name,
&gc);
+#ifdef WIN32
+ DWORD adapter_index = c->c1.tuntap->adapter_index;
+#endif
const in_addr_t local = c->c1.tuntap->local;
const in_addr_t remote_netmask = c->c1.tuntap->remote_netmask;
@@ -1587,6 +1596,9 @@ do_close_tun (struct context *c, bool force)
c->plugins,
OPENVPN_PLUGIN_ROUTE_PREDOWN,
tuntap_actual,
+#ifdef WIN32
+ adapter_index,
+#endif
NULL,
TUN_MTU_SIZE (&c->c2.frame),
EXPANDED_SIZE (&c->c2.frame),
@@ -1612,6 +1624,9 @@ do_close_tun (struct context *c, bool force)
c->plugins,
OPENVPN_PLUGIN_DOWN,
tuntap_actual,
+#ifdef WIN32
+ adapter_index,
+#endif
NULL,
TUN_MTU_SIZE (&c->c2.frame),
EXPANDED_SIZE (&c->c2.frame),
@@ -1635,6 +1650,9 @@ do_close_tun (struct context *c, bool force)
c->plugins,
OPENVPN_PLUGIN_DOWN,
tuntap_actual,
+#ifdef WIN32
+adapter_index,
+#endif
NULL,
TUN_MTU_SIZE (&c->c2.frame),
EXPANDED_SIZE (&c->c2.frame),
diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index bc411bf..05ed073 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -62,6 +62,9 @@ run_up_down (const char *command,
const struct plugin_list *plugins,
int plugin_type,
const char *arg,
+#ifdef WIN32
+DWORD adapter_index,
+#endif
const char *dev_type,
int tun_mtu,
int link_mtu,
@@ -82,6 +85,9 @@ run_up_down (const char *command,
setenv_str (es, "dev", arg);
if (dev_type)
setenv_str (es, "dev_type", dev_type);
+#ifdef WIN32
+ setenv_int (es, "dev_idx", adapter_index);
+#endif
if (!ifconfig_local)
ifconfig_local = "";
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index dbe899e..65a6e55 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -63,6 +63,9 @@ void run_up_down (const char *command,
const struct plugin_list *plugins,
int plugin_type,
const char *arg,
+#ifdef WIN32
+ DWORD adapter_index,
+#endif
const char *dev_type,
int tun_mtu,
int link_mtu,
--
1.9.1
[Openvpn-devel] On defaulting the GUI to run as administrator
continuing from the -users list thread Ref: http://thread.gmane.org/gmane.network.openvpn.user/36387/focus=36417 Hi, I have posted a pull request to openvpn-gui with a one line patch. It just requests the highest Privilege from invoking user, and leaves the manifest embedded. This means, when an admin user runs the GUI it will start with full admin privileges, no change in behaviour for non-admin users. Assuming a vast majorty of windows users work with admin accounts, this may be enough to avoid most complaints that result from UAC preventing elevation by default. I'm reluctantly open to change this to "requireAdministrator" with external manifest (just a small xml file that accompany the .exe). Even with an external manifest it is not without issues. Such a GUI will be unusable for any "limited user" who has no access to admin credentials -- until an admin fixes it by editing the manifest,, . Any strong voices out there? Comments from those who support a large windows user base would be especially helpful. On a related, note, currently the GUI shows no error when routes are not setup (most often due to lack of privileges, I presume). This could be improved if the management interface reports something more useful than "CONNECTED,SUCCESS" as the state after route setup errors. Then the GUI can be made to pop up a message alerting the user. The alternative of parsing route errors from the log is hard and error-prone. Selva
