On 10/12/16 13:08, Christian Hesse wrote: > David Sommerseth <open...@sf.lists.topphemmelig.net> on Sat, 2016/12/10 01:03: >> On 10/12/16 00:19, Christian Hesse wrote: >>> From: Christian Hesse <m...@eworm.de> >>> >>> sd_notify() uses a socket to communicate with systemd. Communication >>> fails if the socket is not available within the chroot. So bind mount >>> the socket into the chroot when startet from systemd. >>> >>> Unsharing namespace and mounting requires extra capability >>> CAP_SYS_ADMIN. >> >> I will pick up this one after 2.4.0 has been released. This is a very >> promising approach. However, I'm not too happy about CAP_SYS_ADMIN >> though, that grants quite some privileges. Can we look at dropping this >> capability once we know we won't need it any more? Perhaps when we send >> READY=1? > > Never tried to drop capabilities... Have to look into that. > We do no longer need CAP_SYS_ADMIN after the bind mount. (Or not at all > without chrooting.)
Sounds reasonable. Since we need to take CAP_SYS_ADMIN out of the unit
file regardless, we need to drop the CAP_SYS_ADMIN capability inside
OpenVPN anyhow. Just need to figure out the best place for it.
As a pointer for managing capabilities, have a look at the capsetp(3)
man page.
>>> + char * chroot_notify = NULL;
>>> +
>>> + if (sd_notify(0, "READY=0") > 0)
>>> + {
>>> + asprintf(&chroot_notify, "%s/notify",
>>> c->options.chroot_dir);
>>
>> Here we should use the buffer/string functions, based on the gc_arena
>> implementation. Unfortunately we do not have a direct equivalent to
>> asprintf(). A starting point would be to for example look at the string
>> handling in print_sockaddr_ex() [socket.c:2386] or x_msg_va()
>> [error.c:251] ... there might be better examples too, I'm just not able
>> to remember them now :) .... buffer.[ch] keeps most of these functions.
>>
>> The reason for this is basically to use the same well tested
>> infrastructure. And with gc_arena, only a single gc_free() is required,
>> regardless of how many buffers you allocate to that arena.
>
> I do not like this myself. The patch is just a proof of concept... So this
> should be polished before committing. ;)
>
> Thanks for the hints, I will have a look.
It's a great PoC! And good to see that we might find a solution for
this. Will look forward to dig deeper into this in the coming weeks too.
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
