[NEW] wiresep - privilege separated implementation of WireGuard

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[NEW] wiresep - privilege separated implementation of WireGuard

Tim Kuijsten-4
Hi all,

This is a port of my implementation of WireGuard.

I had some trouble with the following when creating the port:

1. I was not able to set "SEPARATE_BUILD = Yes", I get the error "cannot open
Makefile":

/usr/ports/net/wiresep/ $ make build
===>  Verifying specs:  c crypto
===>  found c.95.1 crypto.45.5
===>  Checking files for wiresep-0.8.2-rc.3
`/usr/ports/distfiles/wiresep-0.8.2-rc.3.tar.gz' is up to date.
>> (SHA256) wiresep-0.8.2-rc.3.tar.gz: OK
===>  Extracting for wiresep-0.8.2-rc.3
===>  Patching for wiresep-0.8.2-rc.3
===>  Compiler link: clang -> /usr/bin/clang
===>  Compiler link: clang++ -> /usr/bin/clang++
===>  Compiler link: cc -> /usr/bin/cc
===>  Compiler link: c++ -> /usr/bin/c++
===>  Generating configure for wiresep-0.8.2-rc.3
===>  Configuring for wiresep-0.8.2-rc.3
===>  Building for wiresep-0.8.2-rc.3
make: cannot open Makefile.
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2800
'/usr/ports/pobj/wiresep-0.8.2-rc.3/build-amd64/.build_done')
*** Error 1 in /usr/ports/net/wiresep
(/usr/ports/infrastructure/mk/bsd.port.mk:2466 'build')


2. somehow `rcctl stop wiresep` does not execute my custom rc_stop
function in /etc/rc.d/wiresep

3. portcheck(1) issues "hardcoded paths detected in pkg/MESSAGE,
consider using SUBST_VARS and TRUEPREFIX/LOCALBASE/LOCALSTATEDIR/VARBASE"

When I try to replace "/usr/local" with ${TRUEPREFIX} it does not
get substituted and is displayed verbatim when the MESSAGE file is
displayed right after installing the package with `doas make install`.

Kind regards,

Tim

wiresep.tar.gz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
This is a new version of the port which fixes all my previous
questions (thanks Bjorn Ketelaars for all the help).

This is based on the final v0.8.2 which I released today and includes
some additional tweaks and fixes (is the version number v0.8.2
semantically higher in ports compared to v0.8.2-rc.3?).

Hope somebody can test or comment on it.

For completeness a link to the homepage and a short description which I
forgot to mention yesterday: https://github.com/timkuijsten/wiresep

============
WireSep is a privilege separated implementation of WireGuard for
OpenBSD.

WireGuard is a VPN that aims to be simpler and faster than IPsec
and OpenVPN. Simpler both in configuration and in implementation.
============

Cheers!

Tim


Tim Kuijsten <[hidden email]> wrote:

> Hi all,
>
> This is a port of my implementation of WireGuard.
>
> I had some trouble with the following when creating the port:
>
> 1. I was not able to set "SEPARATE_BUILD = Yes", I get the error "cannot open
> Makefile":
>
> /usr/ports/net/wiresep/ $ make build
> ===>  Verifying specs:  c crypto
> ===>  found c.95.1 crypto.45.5
> ===>  Checking files for wiresep-0.8.2-rc.3
> `/usr/ports/distfiles/wiresep-0.8.2-rc.3.tar.gz' is up to date.
> >> (SHA256) wiresep-0.8.2-rc.3.tar.gz: OK
> ===>  Extracting for wiresep-0.8.2-rc.3
> ===>  Patching for wiresep-0.8.2-rc.3
> ===>  Compiler link: clang -> /usr/bin/clang
> ===>  Compiler link: clang++ -> /usr/bin/clang++
> ===>  Compiler link: cc -> /usr/bin/cc
> ===>  Compiler link: c++ -> /usr/bin/c++
> ===>  Generating configure for wiresep-0.8.2-rc.3
> ===>  Configuring for wiresep-0.8.2-rc.3
> ===>  Building for wiresep-0.8.2-rc.3
> make: cannot open Makefile.
> *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2800
> '/usr/ports/pobj/wiresep-0.8.2-rc.3/build-amd64/.build_done')
> *** Error 1 in /usr/ports/net/wiresep
> (/usr/ports/infrastructure/mk/bsd.port.mk:2466 'build')
>
>
> 2. somehow `rcctl stop wiresep` does not execute my custom rc_stop
> function in /etc/rc.d/wiresep
>
> 3. portcheck(1) issues "hardcoded paths detected in pkg/MESSAGE,
> consider using SUBST_VARS and TRUEPREFIX/LOCALBASE/LOCALSTATEDIR/VARBASE"
>
> When I try to replace "/usr/local" with ${TRUEPREFIX} it does not
> get substituted and is displayed verbatim when the MESSAGE file is
> displayed right after installing the package with `doas make install`.
>
> Kind regards,
>
> Tim


wiresep.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
On 2019/11/15 00:39, Tim Kuijsten wrote:
> This is a new version of the port which fixes all my previous
> questions (thanks Bjorn Ketelaars for all the help).
>
> This is based on the final v0.8.2 which I released today and includes
> some additional tweaks and fixes (is the version number v0.8.2
> semantically higher in ports compared to v0.8.2-rc.3?).

0.8.2 is semantically higher than 0.8.2rc3; the version number part in
ports can't have a - as that makes it treated like a flavour named
"rc.3".

> Hope somebody can test or comment on it.
>
> For completeness a link to the homepage and a short description which I
> forgot to mention yesterday: https://github.com/timkuijsten/wiresep
>
> ============
> WireSep is a privilege separated implementation of WireGuard for
> OpenBSD.
>
> WireGuard is a VPN that aims to be simpler and faster than IPsec
> and OpenVPN. Simpler both in configuration and in implementation.
> ============

- In 6.6+, PERMIT_PACKAGE_CDROM now needs to just be PERMIT_PACKAGE.

- The example config share/examples/wiresep/wiresep.conf.example
would usually want to be followed by "@sample ${SYSCONFDIR}/wiresep/wiresep.conf"
to copy it into the normal place - if not then there should be an @extraunexec
to remove the file that users would create themselves.

- pkg/README should follow the layout in templates/README.template.

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Janne Johansson-3
Works on my ERL/octeon/mips64 against my work-mac-laptop with wireguard!

[ ID] Interval           Transfer     Bitrate

[  5]   0.00-10.01  sec  13.5 MBytes  11.3 Mbits/sec
receiver

decent perf also.

Den fre 15 nov. 2019 kl 02:47 skrev Stuart Henderson <[hidden email]>:

> On 2019/11/15 00:39, Tim Kuijsten wrote:
> > This is a new version of the port which fixes all my previous
> > questions (thanks Bjorn Ketelaars for all the help).
> > This is based on the final v0.8.2 which I released today and includes
> > some additional tweaks and fixes (is the version number v0.8.2
> > semantically higher in ports compared to v0.8.2-rc.3?).
>

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Janne Johansson-3
In reply to this post by Stuart Henderson
./wiresep -d -vv

master[25128]: 25128

master[25128]: enclave 4:6

master[25128]: proxy 8:9

master[25128]: tun0 master 3:4, enclave 5:6, proxy 7:8

master[25128]: config sent to enclave 4

master[25128]: config sent to proxy 8

proxy[19229]: enclave[46390]: 1922946390


master[25128]: config sent to tun0 3

tun0[95120]: 95120

proxy[19229]: config received from 9

proxy[19229]: socket receive buffer: 524216

proxy[19229]: listening 192.168.1.110:1234

proxy[19229]: server sockets created:

proxy[19229]: decreasing current data limit from 17179869184 to 2097152

proxy[19229]: decreasing maximum data limit from 17179869184 to 2097152

proxy[19229]: decreasing current fsize limit from 9223372036854775807 to 0

proxy[19229]: decreasing maximum fsize limit from 9223372036854775807 to 0

proxy[19229]: decreasing current memlock limit from 168908117 to 0

proxy[19229]: decreasing maximum memlock limit from 506724352 to 0

proxy[19229]: decreasing current nofile limit from 128 to 8

proxy[19229]: decreasing maximum nofile limit from 1024 to 8

proxy[19229]: decreasing current nproc limit from 542 to 0

proxy[19229]: decreasing maximum nproc limit from 542 to 0

proxy[19229]: decreasing current stack limit from 8388608 to 32768

proxy[19229]: decreasing maximum stack limit from 33554432 to 32768

enclave[46390]: config received from 6

enclave[46390]: decreasing current data limit from 17179869184 to 1048576

enclave[46390]: decreasing maximum data limit from 17179869184 to 1048576

enclave[46390]: decreasing current fsize limit from 9223372036854775807 to 0

enclave[46390]: decreasing maximum fsize limit from 9223372036854775807 to 0

enclave[46390]: decreasing current memlock limit from 168908117 to 0

enclave[46390]: decreasing maximum memlock limit from 506724352 to 0

enclave[46390]: decreasing current nofile limit from 128 to 7

enclave[46390]: decreasing maximum nofile limit from 1024 to 7

enclave[46390]: decreasing current nproc limit from 542 to 0

enclave[46390]: decreasing maximum nproc limit from 542 to 0

enclave[46390]: decreasing current stack limit from 8388608 to 32768

enclave[46390]: decreasing maximum stack limit from 33554432 to 32768

enclave[46390]: calloc ev: Cannot allocate memory

master: child 46390 normal exit 1

proxy[19229]: received TERM, shutting down



and when it works:


./wiresep -d -vv

master[92457]: 92457


master[92457]: enclave 4:6

master[92457]: proxy 8:9

master[92457]: tun0 master 3:4, enclave 5:6, proxy 7:8

master[92457]: enclave[71015]: 71015

config sent to enclave 4

master[92457]: config sent to proxy 8

master[92457]: config sent to tun0 3

tun0[11040]: 11040

proxy[12374]: 12374

enclave[71015]: config received from 6

enclave[71015]: decreasing current data limit from 17179869184 to 1048576

enclave[71015]: decreasing maximum data limit from 17179869184 to 1048576

enclave[71015]: decreasing current fsize limit from 9223372036854775807 to 0

enclave[71015]: decreasing maximum fsize limit from 9223372036854775807 to 0

enclave[71015]: decreasing current memlock limit from 168908117 to 0

enclave[71015]: decreasing maximum memlock limit from 506724352 to 0

enclave[71015]: decreasing current nofile limit from 128 to 7

enclave[71015]: decreasing maximum nofile limit from 1024 to 7

enclave[71015]: decreasing current nproc limit from 542 to 0

enclave[71015]: decreasing maximum nproc limit from 542 to 0

enclave[71015]: decreasing current stack limit from 8388608 to 32768

enclave[71015]: decreasing maximum stack limit from 33554432 to 32768

proxy[12374]: config received from 9

proxy[12374]: socket receive buffer: 524216

proxy[12374]: listening 192.168.1.110:1234tun0[11040]: tun0 172.19.0.1/24


proxy[12374]: server sockets created:

proxy[12374]: tun0[11040]: decreasing current data limit from 17179869184
to 2097152peer udp6 receive buffer: 524216


tun0[11040]: peer udp4 receive buffer: 524216proxy[12374]:

decreasing maximum data limit from 17179869184 to 2097152

proxy[12374]: decreasing current fsize limit from 9223372036854775807 to 0

proxy[12374]: decreasing maximum fsize limit from 9223372036854775807 to 0

tun0[11040]: proxy[12374]: maclap allowedip 0.0.0.0/0decreasing current
memlock limit from 168908117 to 0


proxy[12374]: decreasing maximum memlock limit from 506724352 to 0

tun0[11040]: proxy[12374]: maclap allowedip ::/0decreasing current nofile
limit from 128 to 8


proxy[12374]: decreasing maximum nofile limit from 1024 to 8

tun0[11040]: proxy[12374]: config received from 4decreasing current nproc
limit from 542 to 0


proxy[12374]: decreasing maximum nproc limit from 542 to 0

proxy[12374]: decreasing current stack limit from 8388608 to 32768

proxy[12374]: decreasing maximum stack limit from 33554432 to 32768

tun0[11040]: configuring tun0

tun0[11040]: tun0 created

tun0[11040]: decreasing current data limit from 17179869184 to 2097152

tun0[11040]: decreasing maximum data limit from 17179869184 to 2097152

tun0[11040]: decreasing current fsize limit from 9223372036854775807 to 0

tun0[11040]: decreasing maximum fsize limit from 9223372036854775807 to 0

tun0[11040]: decreasing current memlock limit from 168908117 to 0

tun0[11040]: decreasing maximum memlock limit from 506724352 to 0

tun0[11040]: decreasing current nofile limit from 128 to 10

tun0[11040]: decreasing maximum nofile limit from 1024 to 10

tun0[11040]: decreasing current nproc limit from 542 to 0

tun0[11040]: decreasing maximum nproc limit from 542 to 0

tun0[11040]: decreasing current stack limit from 8388608 to 32768

tun0[11040]: decreasing maximum stack limit from 33554432 to 32768

tun0[11040]: could not find a suitable source address to connect to peer




Den fre 15 nov. 2019 kl 02:47 skrev Stuart Henderson <[hidden email]>:

> On 2019/11/15 00:39, Tim Kuijsten wrote:
> > This is a new version of the port which fixes all my previous
> > questions (thanks Bjorn Ketelaars for all the help).
> >
> > This is based on the final v0.8.2 which I released today and includes
> > some additional tweaks and fixes (is the version number v0.8.2
> > semantically higher in ports compared to v0.8.2-rc.3?).
>
> 0.8.2 is semantically higher than 0.8.2rc3; the version number part in
> ports can't have a - as that makes it treated like a flavour named
> "rc.3".
>
> > Hope somebody can test or comment on it.
> >
> > For completeness a link to the homepage and a short description which I
> > forgot to mention yesterday: https://github.com/timkuijsten/wiresep
> >
> > ============
> > WireSep is a privilege separated implementation of WireGuard for
> > OpenBSD.
> >
> > WireGuard is a VPN that aims to be simpler and faster than IPsec
> > and OpenVPN. Simpler both in configuration and in implementation.
> > ============
>
> - In 6.6+, PERMIT_PACKAGE_CDROM now needs to just be PERMIT_PACKAGE.
>
> - The example config share/examples/wiresep/wiresep.conf.example
> would usually want to be followed by "@sample
> ${SYSCONFDIR}/wiresep/wiresep.conf"
> to copy it into the normal place - if not then there should be an
> @extraunexec
> to remove the file that users would create themselves.
>
> - pkg/README should follow the layout in templates/README.template.
>
>

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
> enclave[46390]: decreasing current data limit from 17179869184 to 1048576
>
> enclave[46390]: decreasing maximum data limit from 17179869184 to 1048576

In the next branch I have patched the enclave to relax the heap limit to at
least 2M instead of 1M (plus some extra dependant on the number of configured
interfaces and peers).

doas wiresep -dvv
...
enclave[16625]: decreasing current data limit from 34359738368 to 2097624
enclave[16625]: decreasing maximum data limit from 34359738368 to 2097624

could you try with these patches?

https://github.com/timkuijsten/wiresep/tree/next

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Janne Johansson-3
Den mån 18 nov. 2019 kl 14:05 skrev Tim Kuijsten <[hidden email]>:

> > enclave[46390]: decreasing current data limit from 17179869184 to 1048576
> >
> > enclave[46390]: decreasing maximum data limit from 17179869184 to 1048576
>
> In the next branch I have patched the enclave to relax the heap limit to at
> least 2M instead of 1M (plus some extra dependant on the number of
> configured
> interfaces and peers).
>
> doas wiresep -dvv
> ...
> enclave[16625]: decreasing current data limit from 34359738368 to 2097624
> enclave[16625]: decreasing maximum data limit from 34359738368 to 2097624
>
> could you try with these patches?
>
> https://github.com/timkuijsten/wiresep/tree/next
>

Yes, that makes it much more reliable, haven't failed me yet.

Btw, could we make the proctitle slightly nicer on the cpu-bearing process?

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
> Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
>
>   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0

You mean make it more clear in top(1) that tun0 is a process of wiresep?

What about prefixing all processes with "ws" so that we would get:
root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
On 2019/11/18 18:42, Tim Kuijsten wrote:

> > Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
> >
> >   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> > 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0
>
> You mean make it more clear in top(1) that tun0 is a process of wiresep?
>
> What about prefixing all processes with "ws" so that we would get:
> root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
> 3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
> 3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
> 3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)
>

most daemons that change their proctitle still have the process name first, e.g.

wiresep (master), wiresep (tun0), ..

or

wiresep: master, wiresep: tun0, ..

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
Here is a new updated port of wiresep based on v0.8.3.

It incorporates all the feedback I got:
* don't change the process name, keep wiresep
* let resource limits take the configuration into account
  (fixes a pre-mature exit of the enclave on the octeon platform)
* treat OOM errors in the main loop as transient
* don't notify proxy to destroy unsent sessions

Thanks Bjorn, Janne and Stuart for all the feedback!

Stuart Henderson <[hidden email]> wrote:

> On 2019/11/18 18:42, Tim Kuijsten wrote:
> > > Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
> > >
> > >   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> > > 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0
> >
> > You mean make it more clear in top(1) that tun0 is a process of wiresep?
> >
> > What about prefixing all processes with "ws" so that we would get:
> > root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
> > 3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
> > 3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
> > 3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)
> >
>
> most daemons that change their proctitle still have the process name first, e.g.
>
> wiresep (master), wiresep (tun0), ..
>
> or
>
> wiresep: master, wiresep: tun0, ..


wiresep-0.8.3.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
On 2019/11/18 22:19, Tim Kuijsten wrote:

> Here is a new updated port of wiresep based on v0.8.3.
>
> It incorporates all the feedback I got:
> * don't change the process name, keep wiresep
> * let resource limits take the configuration into account
>   (fixes a pre-mature exit of the enclave on the octeon platform)
> * treat OOM errors in the main loop as transient
> * don't notify proxy to destroy unsent sessions
>
> Thanks Bjorn, Janne and Stuart for all the feedback!
>
> Stuart Henderson <[hidden email]> wrote:
> > On 2019/11/18 18:42, Tim Kuijsten wrote:
> > > > Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
> > > >
> > > >   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> > > > 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0
> > >
> > > You mean make it more clear in top(1) that tun0 is a process of wiresep?
> > >
> > > What about prefixing all processes with "ws" so that we would get:
> > > root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
> > > 3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
> > > 3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
> > > 3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)
> > >
> >
> > most daemons that change their proctitle still have the process name first, e.g.
> >
> > wiresep (master), wiresep (tun0), ..
> >
> > or
> >
> > wiresep: master, wiresep: tun0, ..
>
>


- the custom rc_check and rc_stop don't seem to be needed, it's better
to just adjust pexp (with .* if necessary)

- the "underline" in README should be the same number of chars as the
text on the line above

- rather than the complex

DISTNAME =              ${GH_PROJECT}-${GH_TAGNAME:C/^v//:C/-rc./rc/}

I think it would be better to let the ports infrastructure handle
DISTNAME and just reset PKGNAME, which then only needs simple subst
rather than regex i.e. PKGNAME = ${DISTNAME:S/-rc./rc/}


Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
On 2019/11/18 21:28, Stuart Henderson wrote:

> On 2019/11/18 22:19, Tim Kuijsten wrote:
> > Here is a new updated port of wiresep based on v0.8.3.
> >
> > It incorporates all the feedback I got:
> > * don't change the process name, keep wiresep
> > * let resource limits take the configuration into account
> >   (fixes a pre-mature exit of the enclave on the octeon platform)
> > * treat OOM errors in the main loop as transient
> > * don't notify proxy to destroy unsent sessions
> >
> > Thanks Bjorn, Janne and Stuart for all the feedback!
> >
> > Stuart Henderson <[hidden email]> wrote:
> > > On 2019/11/18 18:42, Tim Kuijsten wrote:
> > > > > Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
> > > > >
> > > > >   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> > > > > 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0
> > > >
> > > > You mean make it more clear in top(1) that tun0 is a process of wiresep?
> > > >
> > > > What about prefixing all processes with "ws" so that we would get:
> > > > root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
> > > > 3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
> > > > 3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
> > > > 3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)
> > > >
> > >
> > > most daemons that change their proctitle still have the process name first, e.g.
> > >
> > > wiresep (master), wiresep (tun0), ..
> > >
> > > or
> > >
> > > wiresep: master, wiresep: tun0, ..
> >
> >
>
>
> - the custom rc_check and rc_stop don't seem to be needed, it's better
> to just adjust pexp (with .* if necessary)
>
> - the "underline" in README should be the same number of chars as the
> text on the line above
>
> - rather than the complex
>
> DISTNAME =              ${GH_PROJECT}-${GH_TAGNAME:C/^v//:C/-rc./rc/}
>
> I think it would be better to let the ports infrastructure handle
> DISTNAME and just reset PKGNAME, which then only needs simple subst
> rather than regex i.e. PKGNAME = ${DISTNAME:S/-rc./rc/}
>
>

Forgot to mention, rather than the patch + SUBST_CMD dance, you can just
override make variables on the command line;

MAKE_FLAGS = PREFIX=${PREFIX} ETCDIR=${SYSCONFDIR}

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
In reply to this post by Stuart Henderson
here a fixed version:
* drop complex use of DISTNAME for -rc.x support, not needed now
* simplify rc script
* align ruler length in README

Stuart Henderson <[hidden email]> wrote:

> On 2019/11/18 22:19, Tim Kuijsten wrote:
> > Here is a new updated port of wiresep based on v0.8.3.
> >
> > It incorporates all the feedback I got:
> > * don't change the process name, keep wiresep
> > * let resource limits take the configuration into account
> >   (fixes a pre-mature exit of the enclave on the octeon platform)
> > * treat OOM errors in the main loop as transient
> > * don't notify proxy to destroy unsent sessions
> >
> > Thanks Bjorn, Janne and Stuart for all the feedback!
> >
> > Stuart Henderson <[hidden email]> wrote:
> > > On 2019/11/18 18:42, Tim Kuijsten wrote:
> > > > > Btw, could we make the proctitle slightly nicer on the cpu-bearing process?
> > > > >
> > > > >   PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
> > > > > 19404 wsep      39    0 1440K 3232K onproc/1  -         0:07 27.88% tun0
> > > >
> > > > You mean make it more clear in top(1) that tun0 is a process of wiresep?
> > > >
> > > > What about prefixing all processes with "ws" so that we would get:
> > > > root     82906  0.0  0.0   608  1844 ??  Ip     Sun11PM    0:00.01 wsmaster (wiresep)
> > > > 3901      8190  0.0  0.1   728  2352 ??  Ip     Sun11PM    0:11.39 wstun0 (wiresep)
> > > > 3900     50475  0.0  0.0   672  2072 ??  Ip     Sun11PM    0:00.04 wsproxy (wiresep)
> > > > 3900     84443  0.0  0.1   656  2196 ??  Ip     Sun11PM    0:00.47 wsenclave (wiresep)
> > > >
> > >
> > > most daemons that change their proctitle still have the process name first, e.g.
> > >
> > > wiresep (master), wiresep (tun0), ..
> > >
> > > or
> > >
> > > wiresep: master, wiresep: tun0, ..
> >
> >
>
>
> - the custom rc_check and rc_stop don't seem to be needed, it's better
> to just adjust pexp (with .* if necessary)
>
> - the "underline" in README should be the same number of chars as the
> text on the line above
>
> - rather than the complex
>
> DISTNAME =              ${GH_PROJECT}-${GH_TAGNAME:C/^v//:C/-rc./rc/}
>
> I think it would be better to let the ports infrastructure handle
> DISTNAME and just reset PKGNAME, which then only needs simple subst
> rather than regex i.e. PKGNAME = ${DISTNAME:S/-rc./rc/}


wiresep-0.8.3.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
In reply to this post by Stuart Henderson
> Forgot to mention, rather than the patch + SUBST_CMD dance, you can just
> override make variables on the command line;
>
> MAKE_FLAGS = PREFIX=${PREFIX} ETCDIR=${SYSCONFDIR}

again, now including the above fix as well.

wiresep-0.8.3.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
On 2019/11/18 23:24, Tim Kuijsten wrote:
> > Forgot to mention, rather than the patch + SUBST_CMD dance, you can just
> > override make variables on the command line;
> >
> > MAKE_FLAGS = PREFIX=${PREFIX} ETCDIR=${SYSCONFDIR}
>
> again, now including the above fix as well.

Looking in sample config,

: # pick an unprivileged user/id
: user 1109

Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
config to use it. For the actual number, pick the next available uid from
ports/infrastructure/db/user.list and include a diff to add to that file too.

Building,

: ===>  Building for wiresep-0.8.3
: cc -Wall -Wextra -pedantic-errors -c tai64n.c
: cc -Wall -Wextra -pedantic-errors -c blake2s-ref.c
[..]

Missing C opt/debug flags, changing your patch as follows fixes that:

-CFLAGS = -Wall -Wextra -pedantic-errors -O0 -g
+CFLAGS += -Wall -Wextra -pedantic-errors

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
> Looking in sample config,
>
> : # pick an unprivileged user/id
> : user 1109
>
> Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> config to use it. For the actual number, pick the next available uid from
> ports/infrastructure/db/user.list and include a diff to add to that file too.

I have some questions about the optimal number of users with regard to
privilege separation and the different processes of my program. I hope it's ok
to ask about it here, if not, please let me know.

Background about the [design]:
In wiresep I have three types of processes, an untrusted and insignificant
proxy (pledge("stdio", "")), a fully trusted enclave (pledge("stdio", "")),
and a semi-trusted ifn process (pledge("stdio inet", "")). There is always
exactly one instance of the proxy and one instance of the enclave process, but
there can be more than one ifn process. One per configured tunnel interface.

Threat model:
If the enclave is exploited, long term secrets leak and we're hosed. It should
be fairly easy to audit the 1300+ LoC of enclave.c and get some sense about
the risk whether or not this will happen one day.
(about the LoC: cc -E enclave.c | wc -l = 6214)

Then the process per tunnel interface, "ifn". This is where most complexity
goes and what touches the decrypted plain text network packets. This process
only has short term session keys and the idea is that if someone manages to
exploit one "ifn" process it won't be able to read/write packets of any other
"ifn" process not access the long term secrets. (but yes, all packets with all
peers on that single exploited interface might leak/be manipulated)

Questions:
1a. Can one process that pledged ("stdio inet", "") somehow access/directly
influence other processes that run by the same user id? I only know of
ptrace(2) and both because of pledge and because none of the mentioned
processes are descendants of each other it should be safe as long as
kern.global_ptrace=0, which currently is the default.

1b. In the case of wiresep, if one ifn process gets exploited, would other ifn
processes be protected from the exploited one if the user ids are different
from each other, and is a different user id really needed for that protection?
Of course it ultimately depends on the integrity of the IPC and shared
resources, about the last I can say, apart from the host, only the proxy and
enclave are shared between all ifn processes and only through a tightly
defined IPC (see [design] and wireprot.h if you're interested).

1c. And lastly, would it be advantageous to run the enclave under a separate
userid than the other processes? (I do that in my setup to be cautious, but
I'm not sure if it's really beneficial to the overall security)

I know most daemons simply use one separate user, but i.e. Dovecot uses one
dovecot user and one separate dovenull user for all the login processes. Also
smtpd has two user ids. So I'm not quite sure which one to pick from "one user
per program" vs "one user per type of process/security domain" vs "one user
per actual process".

Thanks,

Tim

[design] https://github.com/timkuijsten/wiresep/blob/master/doc/design.md

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Theo de Raadt-2
Just make sure your processes call setresuid() or setresgid() to change
(or change to the same...) their uid or gid or gidset, which locks out
ptrace from related processes.  That also kills inadvertent coredump drops.

Beyond that, you are dependent on the code not having take-over bugs which
attempt to leak information, and your information leakages are controlled
by the nature of pledge/unveil to permit new resource allocation for disclosure,
or the utilization of pre-existing resources for discosure.  Naturally
the pre-existing resources become the medium for leakage.

If there's a bug which allows remote control, and if we haven't put enough
control impediments in place.

Tim Kuijsten <[hidden email]> wrote:

> > Looking in sample config,
> >
> > : # pick an unprivileged user/id
> > : user 1109
> >
> > Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> > config to use it. For the actual number, pick the next available uid from
> > ports/infrastructure/db/user.list and include a diff to add to that file too.
>
> I have some questions about the optimal number of users with regard to
> privilege separation and the different processes of my program. I hope it's ok
> to ask about it here, if not, please let me know.
>
> Background about the [design]:
> In wiresep I have three types of processes, an untrusted and insignificant
> proxy (pledge("stdio", "")), a fully trusted enclave (pledge("stdio", "")),
> and a semi-trusted ifn process (pledge("stdio inet", "")). There is always
> exactly one instance of the proxy and one instance of the enclave process, but
> there can be more than one ifn process. One per configured tunnel interface.
>
> Threat model:
> If the enclave is exploited, long term secrets leak and we're hosed. It should
> be fairly easy to audit the 1300+ LoC of enclave.c and get some sense about
> the risk whether or not this will happen one day.
> (about the LoC: cc -E enclave.c | wc -l = 6214)
>
> Then the process per tunnel interface, "ifn". This is where most complexity
> goes and what touches the decrypted plain text network packets. This process
> only has short term session keys and the idea is that if someone manages to
> exploit one "ifn" process it won't be able to read/write packets of any other
> "ifn" process not access the long term secrets. (but yes, all packets with all
> peers on that single exploited interface might leak/be manipulated)
>
> Questions:
> 1a. Can one process that pledged ("stdio inet", "") somehow access/directly
> influence other processes that run by the same user id? I only know of
> ptrace(2) and both because of pledge and because none of the mentioned
> processes are descendants of each other it should be safe as long as
> kern.global_ptrace=0, which currently is the default.
>
> 1b. In the case of wiresep, if one ifn process gets exploited, would other ifn
> processes be protected from the exploited one if the user ids are different
> from each other, and is a different user id really needed for that protection?
> Of course it ultimately depends on the integrity of the IPC and shared
> resources, about the last I can say, apart from the host, only the proxy and
> enclave are shared between all ifn processes and only through a tightly
> defined IPC (see [design] and wireprot.h if you're interested).
>
> 1c. And lastly, would it be advantageous to run the enclave under a separate
> userid than the other processes? (I do that in my setup to be cautious, but
> I'm not sure if it's really beneficial to the overall security)
>
> I know most daemons simply use one separate user, but i.e. Dovecot uses one
> dovecot user and one separate dovenull user for all the login processes. Also
> smtpd has two user ids. So I'm not quite sure which one to pick from "one user
> per program" vs "one user per type of process/security domain" vs "one user
> per actual process".
>
> Thanks,
>
> Tim
>
> [design] https://github.com/timkuijsten/wiresep/blob/master/doc/design.md
>

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
In reply to this post by Tim Kuijsten-4
You'd be better to ask this on tech@ not ports.

Daemons like Dovecot aren't comparable as they don't use pledge which
significantly changes what's possible.


On 2019/11/19 19:03, Tim Kuijsten wrote:

> > Looking in sample config,
> >
> > : # pick an unprivileged user/id
> > : user 1109
> >
> > Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> > config to use it. For the actual number, pick the next available uid from
> > ports/infrastructure/db/user.list and include a diff to add to that file too.
>
> I have some questions about the optimal number of users with regard to
> privilege separation and the different processes of my program. I hope it's ok
> to ask about it here, if not, please let me know.
>
> Background about the [design]:
> In wiresep I have three types of processes, an untrusted and insignificant
> proxy (pledge("stdio", "")), a fully trusted enclave (pledge("stdio", "")),
> and a semi-trusted ifn process (pledge("stdio inet", "")). There is always
> exactly one instance of the proxy and one instance of the enclave process, but
> there can be more than one ifn process. One per configured tunnel interface.
>
> Threat model:
> If the enclave is exploited, long term secrets leak and we're hosed. It should
> be fairly easy to audit the 1300+ LoC of enclave.c and get some sense about
> the risk whether or not this will happen one day.
> (about the LoC: cc -E enclave.c | wc -l = 6214)
>
> Then the process per tunnel interface, "ifn". This is where most complexity
> goes and what touches the decrypted plain text network packets. This process
> only has short term session keys and the idea is that if someone manages to
> exploit one "ifn" process it won't be able to read/write packets of any other
> "ifn" process not access the long term secrets. (but yes, all packets with all
> peers on that single exploited interface might leak/be manipulated)
>
> Questions:
> 1a. Can one process that pledged ("stdio inet", "") somehow access/directly
> influence other processes that run by the same user id? I only know of
> ptrace(2) and both because of pledge and because none of the mentioned
> processes are descendants of each other it should be safe as long as
> kern.global_ptrace=0, which currently is the default.
>
> 1b. In the case of wiresep, if one ifn process gets exploited, would other ifn
> processes be protected from the exploited one if the user ids are different
> from each other, and is a different user id really needed for that protection?
> Of course it ultimately depends on the integrity of the IPC and shared
> resources, about the last I can say, apart from the host, only the proxy and
> enclave are shared between all ifn processes and only through a tightly
> defined IPC (see [design] and wireprot.h if you're interested).
>
> 1c. And lastly, would it be advantageous to run the enclave under a separate
> userid than the other processes? (I do that in my setup to be cautious, but
> I'm not sure if it's really beneficial to the overall security)
>
> I know most daemons simply use one separate user, but i.e. Dovecot uses one
> dovecot user and one separate dovenull user for all the login processes. Also
> smtpd has two user ids. So I'm not quite sure which one to pick from "one user
> per program" vs "one user per type of process/security domain" vs "one user
> per actual process".
>
> Thanks,
>
> Tim
>
> [design] https://github.com/timkuijsten/wiresep/blob/master/doc/design.md

Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Tim Kuijsten-4
In reply to this post by Stuart Henderson
> Looking in sample config,
>
> : # pick an unprivileged user/id
> : user 1109
>
> Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> config to use it. For the actual number, pick the next available uid from
> ports/infrastructure/db/user.list and include a diff to add to that file too.

done, using _wiresep as a default user if not overruled in the configuration
of the daemon.

> Building,
>
> : ===>  Building for wiresep-0.8.3
> : cc -Wall -Wextra -pedantic-errors -c tai64n.c
> : cc -Wall -Wextra -pedantic-errors -c blake2s-ref.c
> [..]
>
> Missing C opt/debug flags, changing your patch as follows fixes that:
>
> -CFLAGS = -Wall -Wextra -pedantic-errors -O0 -g
> +CFLAGS += -Wall -Wextra -pedantic-errors
I made it look like this in my original Makefile so that we don't need a patch
for the package.

user.list.diff (679 bytes) Download Attachment
wiresep-0.8.4.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [NEW] net/wiresep

Stuart Henderson
I think this is OK to import.

Normally we aren't reusing old uids, but in this case the port
previously using the id was removed back in 2003 and it was probably
not all that widely installed anyway, so I think it's fine.

(We do need to do something about the forthcoming uid shortage in ports
by adding a new range but every time something is proposed there's an
objection ..)

On 2019/11/20 01:35, Tim Kuijsten wrote:

> > Looking in sample config,
> >
> > : # pick an unprivileged user/id
> > : user 1109
> >
> > Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> > config to use it. For the actual number, pick the next available uid from
> > ports/infrastructure/db/user.list and include a diff to add to that file too.
>
> done, using _wiresep as a default user if not overruled in the configuration
> of the daemon.
>
> > Building,
> >
> > : ===>  Building for wiresep-0.8.3
> > : cc -Wall -Wextra -pedantic-errors -c tai64n.c
> > : cc -Wall -Wextra -pedantic-errors -c blake2s-ref.c
> > [..]
> >
> > Missing C opt/debug flags, changing your patch as follows fixes that:
> >
> > -CFLAGS = -Wall -Wextra -pedantic-errors -O0 -g
> > +CFLAGS += -Wall -Wextra -pedantic-errors
>
> I made it look like this in my original Makefile so that we don't need a patch
> for the package.

> Index: user.list
> ===================================================================
> RCS file: /cvs/ports/infrastructure/db/user.list,v
> retrieving revision 1.354
> diff -u -p -r1.354 user.list
> --- user.list 4 Oct 2019 20:30:27 -0000 1.354
> +++ user.list 20 Nov 2019 00:28:22 -0000
> @@ -14,6 +14,7 @@ id  user group port options
>  502 _mysql _mysql databases/mariadb,-server
>  503 _postgresql _postgresql databases/postgresql,-server
>  504 _mailman _mailman mail/mailman
> +505 _wiresep _wiresep net/wiresep
>  506 _spamdaemon _spamdaemon mail/p5-Mail-SpamAssassin
>  507 _postfix _postfix mail/postfix/{snapshot,stable}
>  508 _postdrop mail/postfix/{snapshot,stable}