Jdesk / tunnelblick

Automatically exported from code.google.com/p/tunnelblick
0 stars 0 forks source link

Config File Permissions #40

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Creating a config file e.g. /Users/max/Library/openvpn/test.ovpn

2. Start the configuration

What is the expected output? What do you see instead?
The configuration can't be startet b/c: Tunnelblick reports into the
/var/log/system.log
--
File /Users/Max/Library/openvpn/test.ovpn has permissions: 644, is owned by
501 and needs repair...
-- 
several times. And than

---
 Repairing permissions of config file /Users/Max/Library/openvpn/test.ovpn
failed. Not starting.

What's wrong with the permission? It's 644. If I change it to for example
777. Tunnelblick is changeing it back. But it still claims that the
permission is wrong....

What version of the product are you using? On what operating system?
Tunnelblick 3.09b
Leopard

Original issue reported on code.google.com by nivo...@gmail.com on 19 Oct 2008 at 11:37

GoogleCodeExporter commented 9 years ago
Found it! 

Tunnelblick tries to change the owner of the config file - and that doesn't 
work. It can't work in my case. I 
configured it that way, that nobody can change the owner of files within my 
home-folder to root. Why is that 
necessary? Thats odd

Is it possible to remove that part of verification-code? B/c it's against the 
philosophy that all files under 
/Users/ belong to the Users.

If owner root:wheel is necessary - The user-home is the wrong location...

Greedings,
nivoc

Original comment by nivo...@gmail.com on 21 Oct 2008 at 12:33

GoogleCodeExporter commented 9 years ago
That's a security issue. If the config file is not owned by root, an 
unprivileged user can insert an arbitrary up-
script that will be executed with root rights when starting an OpenVPN 
connection. 

Removing this security check would produce a local privilege escalation exploit 
in Tunnelblick.

Original comment by angelol...@gmail.com on 19 Nov 2008 at 1:58

GoogleCodeExporter commented 9 years ago
FIxed (crossed fingers) in r188, by implementing "shadow copying" of the config 
file. This is done automatically 
if the config file is on a network volume. It is also done if the 
"useShadowConfigurationFiles" preference is set.

Original comment by jkbull...@gmail.com on 21 Sep 2009 at 11:16