openvpn
openvpn copied to clipboard
OpenVPN
Socket group restrictions issue
Hello,
The management-group directive checks against getpeereid that the peer is in the correct group (manage.c and socks.c).
However this function returns only the primary guid and not other group the user might belong to, giving an access denied when group is not the primary group of the user.
As well, root access is not checked and root is rejected, which of course is not expected. A uid of 0 or a gid of 0 should grant access.
thanks.
The way I understand it, the credentials of the connecting socket obtained via SO_PEERCRED or getpeereid() are the uid and gid effective at the time the client process called connect. Its up to the user to set them to appropriate values in advance.
If root, you have the caps to change the effective uid/gid before calling connect. That said, its arguable that we should just grant access if the effective uid and gid are 0.
Thanks for your answer. it is also what I have understand from this function but I have no strict idea how to change the guid (just for the socket I mean and not system-wide) before Connect or if another function is needed to check all groups like file permissions does. This said, I would be happy to know how to do it because impossible using nc -U that I use to test.
And indeed I do think root should have access directly so allow access when uid is 0, whatever the initial configuration is, without further actions.
I do not think there is any way to check supplemental groups as all we have is a client socket. The process that we are talking to may not be even the one who created the socket or issued connect and could have even dropped privileges later etc.
For nc, you could possibly run it like setpriv --egid ... nc if you are root or have capabilities to set the gid. I haven't tried,
I agree that allowing access if uid = gid = 0 could be a useful improvement.
This command works only for root not casual users during my tests.
I was wondering if using the uid to fetch getpwuid() for pw_name then loop through getgrouplist could work.
Anyways thanks for your help, waiting for other feedbacks about how to manage group and root access.
concerning privileges, it,of course, depends on the program privileges but this is in the scope of OpenVPN users that are awake of programs and files used as root by OpenVPN and afterwards by the defined group and user, mainly nobody.
Hi,
On Tue, Feb 28, 2023 at 10:02:56PM -0800, DorianCoding wrote:
This command works only for root not casual users during my tests. I was wondering if using the uid to fetch
getpwuid()for pw_name then loop through getgrouplist could work.
This could work - but we're not interested in implementing or maintaining such code - if you want to use the --management-client-groups feature (which is a rarely used feature in itself), just ensure that the client uses the correct primary gid, done. This isn't really intended to be used with "netcat" but with "a real client", and having a setgid() call there is easily done.
Anyways thanks for your help, waiting for other feedbacks about how to manage group and root access.
This would be a much smaller patch ("if uid == 0, permit") and we could include that.
gert
"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany @.***
hello,
This could work - but we're not interested in implementing or maintaining such code - if you want to use the --management-client-groups feature (which is a rarely used feature in itself), just ensure that the client uses the correct primary gid, done. This isn't really intended to be used with "netcat" but with "a real client", and having a setgid() call there is easily done.
If you are unwilling to perform any changes on this, there is nothing more to argue. But therefore this feature won’t restrict the group, but the guid, which is not the same. It is indeed possible to setgid but it requires elevated privileges that a casual user has not. It could be possible to put a sguid but this is just solving the limitation.
This would be a much smaller patch ("if uid == 0, permit") and we could include that.
Yes I think checking if user is root (uid==0) and accept the connection would solve root issue.
Hi,
On Wed, Mar 01, 2023 at 06:19:58AM -0800, DorianCoding wrote:
It is indeed possible to setgid but it requires elevated privileges that a casual user has not. It could be possible to put a sguid but this is just solving the limitation.
I was under the assumption that you can do setgid() at will to change between groups that you already have. Unfortunately I can't find documentation right now to back that.
gert
"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany @.***
It is indeed possible to setgid but it requires elevated privileges that a casual user has not. It could be possible to put a sguid but this is just solving the limitation.
If you belong to a group foo and you have a client program named myclient, you can do
$ chgrp foo myclient $ chmod g+s myclient
Now myclient will run with foo as its effective gid. Of course you may not want to do this if myclient is not a private copy. There are also ways like using a private copy of env and run the program under that env etc., all hacky.
It is indeed possible to setgid but it requires elevated privileges that a casual user has not. It could be possible to put a sguid but this is just solving the limitation.
If you belong to a group foo and you have a client program named myclient, you can do
$ chgrp foo myclient $ chmod g+s myclient
Now myclient will run with foo as its effective gid. Of course you may not want to do this if myclient is not a private copy. There are also ways like using a private copy of env and run the program under that env etc., all hacky.
Indeed the suid bit works well to set the effective guid and then you can execute setregid() and allow change real gid and therefore call the socket from this script. This works well without privileges but well it is a trick, not a « as will » functionality but yes this works.
However setgid does return a EPERM when the gid is not the same, even if you are belonging to this group during my tests. However root can of course change the gid.
However setgid does return a EPERM when the gid is not the same, even if you are belonging to this group during my tests.
setgid() requires certain privileges (CAP_SETGID on Linux), so that's doesn't help if the purpose is to restrict access to a certain set of users by group. I tend to agree that as it stands --management-group is not very useful. But this is the first time I heard anyone using that option.
However setgid does return a EPERM when the gid is not the same, even if you are belonging to this group during my tests.
setgid() requires certain privileges (CAP_SETGID on Linux), so that's doesn't help if the purpose is to restrict access to a certain set of users by group. I tend to agree that as it stands --management-group is not very useful. But this is the first time I heard anyone using that option.
It was a way I found to allow admins to access OpenVPN management. At first, I allowed root do for the command but as root is not working either I am kinda blocked.
But indeed the group clause would act as the user one as it cannot detect any supplementary groups unless using some tricks. Either Sudo or setting some capabilities, or easier, the guid bit with a socket agent.
i didn’t know this feature was not used and well as it is still present, I guess we can help to Improve it.
finally I would be glad if at worst, we can solve this root access and allot root whatsoever and at best, find a solution to check all user groups.
There is many guidelines and I’m not that good at C to propose a push (if we need to go through groups but I can for root check if needed) but I would be glad if this could be patched.
Thanks for your help, both of you.
I was looking into making a patch for improving management-client-group and realized there is an alternative way of restricting access to the socket based on group: create the socket in a folder that only a specified group has access to.
For example:
$ sudo mkdir -m 750 /tmp/ovpn
$ sudo chgrp foo /tmp/ovpn
$ sudo openvpn <options> --management /tmp/ovpn/bar unix ....
Then, for example,
$ nc -U /tmp/ovpn/bar
should work for root and users in foo group, and deny access to others.
Though file system permissions on the socket itself is ignored by many unix variants, folder permissions should be honored. But I tried this only on Linux which honors even socket's permissions.
Hello,
You are right. I was thinking as the socket is generating as 777 it was important but yeah creating the directory will fall into global group restrictions and user restrictions based on Unix permissions. Of course it will work only on compatible systems but for me on Debian it works, thanks for that. It allow work with root with this solution.
Of course it will work only on compatible systems
I cannot think of a Unix variant where this wont work as its only dependent on file-system permissions of the directory. Changing the permissions on the socket itself will work only on some systems like Linux.
So this said those functionalities could be replaced by this trick, as it would rely on file permissions. Whereas it does not seem to be a good idea to replace the user by the owner as it would have full control over the directory socket itself, the group can be used and OpenVPN does not complain so I think it is the root process that manages the management, what I was not expecting at first.
So eventually these expected functionalities can be replaced by UNIX permissions it seems. Maybe the key is just to create a directory from user-path sock if possible and set permissions either to root or selected group but for user, I don’t know unless put it as owner which as said earlier relies on the fact that the user is trust enough to hold the directory, which should be the case if we grant him OpenVPN management.