Re: rc.d(8) for tcpbench
On Tue, Dec 15, 2020 at 10:59:50PM +, Stuart Henderson wrote: > On 2020/12/15 23:07, Jan Klemkow wrote: > > for frequent performance test it would be nice to just start tcpbench > > as a regular service. tcpbench gets an extra user and group with this > > diff and is already pledged to "stdio". Thus, there should be no > > security risk to do this even in hostile environments. > > "io" is just for client, for server it's: > > $ ps -O pledge -ax|grep [t]cpb > 43696 stdio,inet,unix pf > I+p 0:00.00 tcpbench -s Oh yes, sorry, I missed that by looking over the source too quickly. > > diff -u -p -r1.104 master.passwd > > --- etc/master.passwd 24 Apr 2020 14:57:31 - 1.104 > > +++ etc/master.passwd 15 Dec 2020 21:25:17 - > > @@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem > > _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin > > _syspatch:*:112:112::0:0:syspatch unprivileged > > user:/var/empty:/sbin/nologin > > _slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin > > +_tcpbench:*:116:116::0:0:tcpbench unprivileged > > user:/var/empty:/sbin/nologin > > nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin > > no need to grow the "used system uid" space, 111 is available and was > taken for less than a day so it's unlikely anyone would even need to > merge passwd/group files. or maybe a lower one is better, I don't know > if there's a particular numbering plan for these.. Sure, I will fix that, if this thing has a future. > > Index: etc/rc.d/tcpbench > > === > > RCS file: etc/rc.d/tcpbench > > diff -N etc/rc.d/tcpbench > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ etc/rc.d/tcpbench 15 Dec 2020 20:30:18 - > > @@ -0,0 +1,12 @@ > > +#!/bin/ksh > > + > > +daemon="/usr/bin/tcpbench" > > +daemon_flags="-s" > > +daemon_user=_tcpbench > > + > > +. /etc/rc.d/rc.subr > > + > > +rc_reload=NO > > +rc_bg=YES > > + > > +rc_cmd $1 > > > > I am not a big fan of this to be honest. tcpbench is written more as a > test tool than a network daemon. For starters, the spew on the console > when it's active is not very nice. As I described in answer to Theo, its seems to be easier this way, if you and to script its. Or, you want to test the quality of link to different locations frequently.
Re: rc.d(8) for tcpbench
On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > Jan Klemkow wrote: > > > for frequent performance test it would be nice to just start tcpbench > > as a regular service. tcpbench gets an extra user and group with this > > diff and is already pledged to "stdio". Thus, there should be no > > security risk to do this even in hostile environments. > > You're kidding me. If someone starts this in a hostile environment, their > network/host will be flattened. You are right, someone can use this, to flood a link. But, you can flood someones link with traffic anyway, as botnets do it, or? > I find it difficult to believe there is any environment where someone > wants tcpbench running *all the time*. Sure, its not ideal to run this on public interfaces. I just want to say, its unlikely that someone will take over you system via bugs in this daemon, in my opinion. As it has similar mitigation techniques as our other daemons. I run this daemon in permanent tests setups and on links to different locations. Its easier to use rcctl enable/start then to deal with background sessions on remote machines in shell scripts. Do you think its OK to make a port out of this rc-script for this purpose?
rc.d(8) for tcpbench
Hi,
for frequent performance test it would be nice to just start tcpbench
as a regular service. tcpbench gets an extra user and group with this
diff and is already pledged to "stdio". Thus, there should be no
security risk to do this even in hostile environments.
OK?
bye,
Jan
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.480
diff -u -p -r1.480 Makefile
--- etc/Makefile13 Sep 2020 11:29:52 - 1.480
+++ etc/Makefile15 Dec 2020 21:05:07 -
@@ -64,7 +64,7 @@ RCDAEMONS=amd apmd bgpd bootparamd cron
lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d ospfd \
pflogd portmap rad radiusd rarpd rbootd relayd ripd route6d \
sasyncd sensorsd slowcgi slaacd smtpd sndiod snmpd spamd \
- spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \
+ spamlogd sshd statd switchd syslogd tcpbench tftpd tftpproxy unbound \
unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
MISETS=base${OSrev}.tgz comp${OSrev}.tgz man${OSrev}.tgz
game${OSrev}.tgz
Index: etc/group
===
RCS file: /cvs/src/etc/group,v
retrieving revision 1.94
diff -u -p -r1.94 group
--- etc/group 28 Jan 2020 16:51:03 - 1.94
+++ etc/group 15 Dec 2020 20:48:07 -
@@ -79,6 +79,7 @@ _ftp_proxy:*:109:
_sndiop:*:110:
_syspatch:*:112:
_slaacd:*:115:
+_tcpbench:*:116:
dialer:*:117:
nogroup:*:32766:
nobody:*:32767:
Index: etc/master.passwd
===
RCS file: /cvs/src/etc/master.passwd,v
retrieving revision 1.104
diff -u -p -r1.104 master.passwd
--- etc/master.passwd 24 Apr 2020 14:57:31 - 1.104
+++ etc/master.passwd 15 Dec 2020 21:25:17 -
@@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem
_sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin
_syspatch:*:112:112::0:0:syspatch unprivileged user:/var/empty:/sbin/nologin
_slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin
+_tcpbench:*:116:116::0:0:tcpbench unprivileged user:/var/empty:/sbin/nologin
nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin
Index: etc/rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.220
diff -u -p -r1.220 rc.conf
--- etc/rc.conf 24 Jan 2020 06:17:37 - 1.220
+++ etc/rc.conf 15 Dec 2020 20:32:46 -
@@ -65,6 +65,7 @@ spamlogd_flags= # use eg. "-i interface
sshd_flags=
switchd_flags=NO
syslogd_flags= # add more flags, e.g. "-u -a /chroot/dev/log"
+tcpbench_flags=NO
tftpd_flags=NO
tftpproxy_flags=NO
unbound_flags=NO
Index: etc/mail/aliases
===
RCS file: /cvs/src/etc/mail/aliases,v
retrieving revision 1.68
diff -u -p -r1.68 aliases
--- etc/mail/aliases24 Jan 2020 06:17:37 - 1.68
+++ etc/mail/aliases15 Dec 2020 20:48:31 -
@@ -79,6 +79,7 @@ _ftp_proxy: /dev/null
_sndiop: /dev/null
_syspatch: /dev/null
_slaacd: /dev/null
+_tcpbench: /dev/null
sshd: /dev/null
# Well-known aliases -- these should be filled in!
Index: etc/rc.d/tcpbench
===
RCS file: etc/rc.d/tcpbench
diff -N etc/rc.d/tcpbench
--- /dev/null 1 Jan 1970 00:00:00 -
+++ etc/rc.d/tcpbench 15 Dec 2020 20:30:18 -
@@ -0,0 +1,12 @@
+#!/bin/ksh
+
+daemon="/usr/bin/tcpbench"
+daemon_flags="-s"
+daemon_user=_tcpbench
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+rc_bg=YES
+
+rc_cmd $1
Re: rc.d(8) for tcpbench
On 2020/12/15 17:19, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2020/12/15 16:33, Theo de Raadt wrote: > > > Jan Klemkow wrote: > > > > > > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > > > > Jan Klemkow wrote: > > > > > > > > > > > for frequent performance test it would be nice to just start > > > > > > tcpbench > > > > > > as a regular service. tcpbench gets an extra user and group with > > > > > > this > > > > > > diff and is already pledged to "stdio". Thus, there should be no > > > > > > security risk to do this even in hostile environments. > > > > > > > > > > You're kidding me. If someone starts this in a hostile environment, > > > > > their > > > > > network/host will be flattened. > > > > > > > > You are right, someone can use this, to flood a link. But, you can > > > > flood someones link with traffic anyway, as botnets do it, or? > > > > > > It is not the same at all, because tcpbench will attempt to flow maximum > > > traffic in both directions. No other service has that behaviour. > > > > > > > -s just throws the packets away, it does not transmit > > Regardless, I still don't think it makes any sense placing a debugging > feature into the hands of people who don't know what they are doing. > agreed
Re: rc.d(8) for tcpbench
Stuart Henderson wrote: > On 2020/12/15 16:33, Theo de Raadt wrote: > > Jan Klemkow wrote: > > > > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > > > Jan Klemkow wrote: > > > > > > > > > for frequent performance test it would be nice to just start tcpbench > > > > > as a regular service. tcpbench gets an extra user and group with this > > > > > diff and is already pledged to "stdio". Thus, there should be no > > > > > security risk to do this even in hostile environments. > > > > > > > > You're kidding me. If someone starts this in a hostile environment, > > > > their > > > > network/host will be flattened. > > > > > > You are right, someone can use this, to flood a link. But, you can > > > flood someones link with traffic anyway, as botnets do it, or? > > > > It is not the same at all, because tcpbench will attempt to flow maximum > > traffic in both directions. No other service has that behaviour. > > > > -s just throws the packets away, it does not transmit Regardless, I still don't think it makes any sense placing a debugging feature into the hands of people who don't know what they are doing.
Re: rc.d(8) for tcpbench
On 2020/12/15 16:33, Theo de Raadt wrote: > Jan Klemkow wrote: > > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > > Jan Klemkow wrote: > > > > > > > for frequent performance test it would be nice to just start tcpbench > > > > as a regular service. tcpbench gets an extra user and group with this > > > > diff and is already pledged to "stdio". Thus, there should be no > > > > security risk to do this even in hostile environments. > > > > > > You're kidding me. If someone starts this in a hostile environment, their > > > network/host will be flattened. > > > > You are right, someone can use this, to flood a link. But, you can > > flood someones link with traffic anyway, as botnets do it, or? > > It is not the same at all, because tcpbench will attempt to flow maximum > traffic in both directions. No other service has that behaviour. > -s just throws the packets away, it does not transmit
Re: rc.d(8) for tcpbench
Jan Klemkow wrote: > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > Jan Klemkow wrote: > > > > > for frequent performance test it would be nice to just start tcpbench > > > as a regular service. tcpbench gets an extra user and group with this > > > diff and is already pledged to "stdio". Thus, there should be no > > > security risk to do this even in hostile environments. > > > > You're kidding me. If someone starts this in a hostile environment, their > > network/host will be flattened. > > You are right, someone can use this, to flood a link. But, you can > flood someones link with traffic anyway, as botnets do it, or? It is not the same at all, because tcpbench will attempt to flow maximum traffic in both directions. No other service has that behaviour.
Re: rc.d(8) for tcpbench
On 2020/12/15 23:07, Jan Klemkow wrote: > Hi, > > for frequent performance test it would be nice to just start tcpbench > as a regular service. tcpbench gets an extra user and group with this > diff and is already pledged to "stdio". Thus, there should be no > security risk to do this even in hostile environments. "io" is just for client, for server it's: $ ps -O pledge -ax|grep [t]cpb 43696 stdio,inet,unix pf I+p 0:00.00 tcpbench -s > diff -u -p -r1.104 master.passwd > --- etc/master.passwd 24 Apr 2020 14:57:31 - 1.104 > +++ etc/master.passwd 15 Dec 2020 21:25:17 - > @@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem > _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin > _syspatch:*:112:112::0:0:syspatch unprivileged user:/var/empty:/sbin/nologin > _slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin > +_tcpbench:*:116:116::0:0:tcpbench unprivileged user:/var/empty:/sbin/nologin > nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin no need to grow the "used system uid" space, 111 is available and was taken for less than a day so it's unlikely anyone would even need to merge passwd/group files. or maybe a lower one is better, I don't know if there's a particular numbering plan for these.. > Index: etc/rc.d/tcpbench > === > RCS file: etc/rc.d/tcpbench > diff -N etc/rc.d/tcpbench > --- /dev/null 1 Jan 1970 00:00:00 - > +++ etc/rc.d/tcpbench 15 Dec 2020 20:30:18 - > @@ -0,0 +1,12 @@ > +#!/bin/ksh > + > +daemon="/usr/bin/tcpbench" > +daemon_flags="-s" > +daemon_user=_tcpbench > + > +. /etc/rc.d/rc.subr > + > +rc_reload=NO > +rc_bg=YES > + > +rc_cmd $1 > I am not a big fan of this to be honest. tcpbench is written more as a test tool than a network daemon. For starters, the spew on the console when it's active is not very nice.
Re: rc.d(8) for tcpbench
Jan Klemkow wrote: > for frequent performance test it would be nice to just start tcpbench > as a regular service. tcpbench gets an extra user and group with this > diff and is already pledged to "stdio". Thus, there should be no > security risk to do this even in hostile environments. You're kidding me. If someone starts this in a hostile environment, their network/host will be flattened. I find it difficult to believe there is any environment where someone wants tcpbench running *all the time*.
