From Newsgroup: alt.os.linux.slackware

This is another one of those things that I've been running for years and
wish was a part of base Slackware. Slackware gets alot of its support
for older TCPIP tools from multiple packages: the net-kit stuff,
net-tools, iputils and others. Many of these are unmaintained. Then
there's inetd and sysklog. If you use inetutils, you don't need almost
all of that. It's just one package. This is a Slack build (but not a SlackBuild) for Slackware Current (but likely works on 15).

Pros:
- inetutils is a mature GNU project that changes little
- inetutils is being actively maintained (there was a release recently)
- inetutils can install with Linux caps, thus increasing security
because setruid binaries are no longer needed. Consider the recent
dirty.frag vulns for a reason why to avoid setruid
- inetutils has a larger collection of utilities
- inetutuls has an texinfo file detailing all the tools in one place

Cons:
- some conflicts with net-kit, net-tools (uninstall or let them be
clobbered)
- two 'pings', you can leave both /bin/ping and /usr/bin/ping or delete
the old one at /bin/ping if you are confident
- ifconfig does not support ipv6 (I left it off the build list for this
reason) so the net-tools one is still needed if you care about ifconfig

inetutils works well with xinetd, rsyslog, and iproute2 (which is how I
have it setup) though inetutil's inetd and syslogd are fully usable.

Note no setruid:
-rwxr-xr-x 1 root root 60632 May 30 14:44 traceroute*
-rwxr-xr-x 1 root root 145368 May 30 14:44 telnet*
-rwxr-xr-x 1 root root 68560 May 30 14:44 talk*
-rwxr-xr-x 1 root root 56400 May 30 14:44 rsh*
-rwxr-xr-x 1 root root 60752 May 30 14:44 rlogin*
-rwxr-xr-x 1 root root 56464 May 30 14:44 rexec*
-rwxr-xr-x 1 root root 64696 May 30 14:44 rcp*
-rwxr-xr-x 1 root root 65528 May 30 14:44 ping6*
-rwxr-xr-x 1 root root 74648 May 30 14:44 ping*
-rwxr-xr-x 1 root root 136920 May 30 14:44 ftp*
-rwxr-xr-x 1 root root 55896 May 30 14:44 dnsdomainname*

getcap /usr/bin/rlogin
/usr/bin/rlogin cap_net_bind_service=eip
getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=eip

Old way:
ls -l /bin/ping
-rws--x--x 1 root root 164216 Jun 5 2025 /bin/ping*

Full functionality without setruid:
/usr/bin/ping -c 2 kirin.lan
PING kirin (192.168.20.4): 56 data bytes
64 bytes from 192.168.20.4: icmp_seq=0 ttl=255 time=5.397 ms
64 bytes from 192.168.20.4: icmp_seq=1 ttl=255 time=7.032 ms
--- kirin ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.397/6.215/7.032/0.817 ms

rlogin kirin
$ show system /noproc
OpenVMS V7.3 on node KIRIN 30-MAY-2026 16:03:45.64 Uptime 9 20:32:48
$ logout
rlogin: Connection to kirin closed normally.03:54.69

traceroute fatalis.lan
traceroute to fatalis (192.168.20.59), 64 hops max
1 192.168.20.59 1.440ms 1.348ms 1.362ms


I know approaching zero people will actually use this, and Slackware
would never consider it, but once I have a project in mind I have to
complete it so here we are.

ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/inetutils.tar.gz
PGP in inetutils.tar.gz.asc

Note inetutils wants gnulib from GIT, unlike days past when this was
included in the source archive. The script handles all of this and is
explained at the top of inetutils.SlackBuild . A blacklist snippet is
also suggested for you if you use slackpkg (I do). The pulling down of
the GIT repo (for gnulib) only happens once, during bootstrap; the
script checks for the existance of a source directory and doesn't do it
again if it doesn't have to.

A detailed buildlog is kept as well, so if something goes wrong you can
see what it was.

cat BuildLog.txt
++++ Sat May 30 14:43:19 EDT 2026 building inetutils
VERSION -> v2.8
DIRVER -> v2.8
TARARCH -> inetutils-v2.8-src.tar.gz
BUILD -> 1_jayjwa
NUMJOBS -> -j9
ARCH -> x86_64
CC -> ccache gcc
CFLAGS -> -pipe -O2
TMP -> /tmp
PKG -> /tmp/package-inetutils
Opening source tar archive
Source code tree available
Configured
Running make
Packaging the files and binaries
Loaded docs
Populated /install/ subdir
Moving binaries into place and cleaning up unused dirs
Man pages zipped
Binaries stripped for size
++++ inetutils build complete at Sat May 30 14:44:33 EDT 2026
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sat, 30 May 2026 16:35:39 -0400, jayjwa wrote:

Slackware gets alot of its support for older TCPIP tools from multiple packages: the net-kit stuff, net-tools, iputils and others. Many of
these are unmaintained.

The fact that there is a maintained alternative to the currently choosen unmaintained alternative could be a good reason to switch. However, those unmaintained tools also come with a big fat warning, from /usr/doc/netkit-rsh-0.17/README (dated year 2000)

"Note: None of these programs provide encryption or strong
authentication of network connections. As such, their use is
discouraged. The "ssh" protocol and package is a cryptographically
secure replacement."

I do realize that there are situations where you don't want network
traffic to be encrypted, like when streaming live video, but even with
ssh it is still possible to choose not to encrypt X. In most cases
though, ssh with its X tunneling is much more convenient for the user
than manually messing with DISPLA environment variable and xhost.

Cons:
- some conflicts with net-kit, net-tools (uninstall or let them be
clobbered)

Which did you choose? Uninstallation of the conflicting packages?

getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=eip

Old way:
ls -l /bin/ping -rws--x--x 1 root root 164216 Jun 5 2025 /bin/ping*

It would be fully possible to do the same with the stock Slackware
binaries:

Quick test as root:
-8<------------------------------
bash-4.3# cp /bin/ping /tmp
bash-4.3# chmod u-s /tmp/ping
bash-4.3# setcap cap_net_raw=eip /tmp/ping
-8<------------------------------

Then, as a normal user:
-8<------------------------------
nazgul:~> /tmp/ping balrog
PING balrog (192.168.43.3) 56(84) bytes of data.
64 bytes from balrog (192.168.43.3): icmp_seq=1 ttl=64 time=0.134 ms
64 bytes from balrog (192.168.43.3): icmp_seq=2 ttl=64 time=0.192 ms
^C
--- balrog ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.134/0.163/0.192/0.029 ms
nazgul:~>
-8<------------------------------

However, it is nice with an upstream provider which chooses the setcap solution by default.

I know approaching zero people will actually use this, and Slackware
would never consider it, but once I have a project in mind I have to
complete it so here we are.

ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/

inetutils.tar.gz

PGP in inetutils.tar.gz.asc

Thanks for sharing! Maybe someone will find it useful. Maybe, even if not adopted, it will inspire Slackware to replace some setuid binaries with
setcap binaries. However, the setcap properties will get lost in gnu tar archives:

-8<------------------------------
bash-4.3# getcap ping
ping = cap_net_raw+eip
bash-4.3# mkdir 2
bash-4.3# tar -cf - ping | (cd 2; tar -xvf -)
ping
bash-4.3# getcap 2/ping
bash-4.3#
-8<------------------------------

Is that the reason you haven't created any SlackBuild to create a
Slackware package? Such a slackware package would need a doinst.sh to set those properties on the files.

regards Henrik
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:

However, the setcap properties will get lost in gnu tar archives

The same with rsync or cp. Meaning trouble with backups.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Am 30.05.26 um 22:35 schrieb jayjwa:

This is another one of those things that I've been running for years and
wish was a part of base Slackware. Slackware gets alot of its support
for older TCPIP tools from multiple packages: the net-kit stuff,
net-tools, iputils and others. Many of these are unmaintained. Then
there's inetd and sysklog. If you use inetutils, you don't need almost
all of that. It's just one package. This is a Slack build (but not a SlackBuild) for Slackware Current (but likely works on 15).

The manpage looks like Slackware provides an old BSD inetd version.

Dunno why.
--
Gru|f
Marco

Spam bitte an abfalleimer2001@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

"Note: None of these programs provide encryption or strong
authentication of network connections. As such, their use is
discouraged. The "ssh" protocol and package is a cryptographically
secure replacement."

If you can get TOPS-10, TOPS-20, or ITS speaking SSH I'd love to see it
:-))) . Mostly I use the clients, and ftp is being handled by proftpd
at the moment.

Which did you choose? Uninstallation of the conflicting packages?

I just blacklisted the official ones and let inetutils clobber what was
already there.

It would be fully possible to do the same with the stock Slackware
binaries:

Of course. But when I got shot down suggesting mtr-packet be set
cap_net_raw I realized I didn't want to fight this battle - at least on
LQ.

However, the setcap properties will get lost in gnu tar
archives:

You put that code in doinst.sh. That's what my build does. The files
install correctly. doinst.sh runs after binaries are installed
in-system. All this is in the .tar.gz linked yesterday.

## doinst.sh for inetutils
##
## Give Linux capabilities(7) permissions to those few
## binaries that need it rather than using full
## setruid. "setcap" is in /sbin which should always
## be PATH'd

# Function to give cap_net_raw for all files given
lx_cap_setraw() {
local infile
for infile in $@; do
setcap cap_net_raw=eip usr/bin/${infile}
done
}

# Function to give cap_net_bind_service for all files given
lx_cap_setbind() {
local infile
for infile in $@; do
setcap cap_net_bind_service=eip usr/bin/${infile}
done
}

# Give binaries that need raw sockets special powers
lx_cap_setraw ping ping6 traceroute

# Give binaries that need a privileged port special powers
lx_cap_setbind rcp rlogin rsh rexec

## EOF

Is that the reason you haven't created any SlackBuild to create a
Slackware package?

Umm...that's exactly what I did. That is the point of my posting
this. If you mean the compiled binaries, that package is on the same ftp server, but in the pub/operating-systems/linux/slackware-package/
area. I assume most people want to build the binaries themselves.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2026-05-30, jayjwa wrote:

Note no setruid:
-rwxr-xr-x 1 root root 60632 May 30 14:44 traceroute*
-rwxr-xr-x 1 root root 145368 May 30 14:44 telnet*
-rwxr-xr-x 1 root root 68560 May 30 14:44 talk*
-rwxr-xr-x 1 root root 56400 May 30 14:44 rsh*
-rwxr-xr-x 1 root root 60752 May 30 14:44 rlogin*
-rwxr-xr-x 1 root root 56464 May 30 14:44 rexec*
-rwxr-xr-x 1 root root 64696 May 30 14:44 rcp*
-rwxr-xr-x 1 root root 65528 May 30 14:44 ping6*
-rwxr-xr-x 1 root root 74648 May 30 14:44 ping*
-rwxr-xr-x 1 root root 136920 May 30 14:44 ftp*
-rwxr-xr-x 1 root root 55896 May 30 14:44 dnsdomainname*

Some of these utilities don't really serve much use on a modern
system, so I would expect that most folks would simply not install
them. Of those you list that are found on my systems, consider for
an alternative approach to mitigating the setuid risks (this is on
a Slackware-15.0 system):

-rwxr-xr-x 1 root system 23K Feb 13 2021 /bin/dnsdomainname (*)
-rwxr-xr-x 1 root system 92K Feb 13 2021 /bin/ftp
-rwxr-xr-x 1 root system 32K Feb 13 2021 /usr/X11R6/bin/talk
---s--x--- 1 root users 64K Feb 13 2021 /usr/X11R6/bin/traceroute
---s--x--- 1 root users 76K Dec 16 2021 /bin/ping6 (*)
---s--x--- 1 root users 76K Dec 16 2021 /bin/ping (*)
-rwxr-xr-x 1 root system 94K Feb 28 19:13 /bin/telnet

(*) noting that /bin/dnsdomainname symlinks to hostname, and
/bin/ping6 symlinks to ping; these are the permissions after
unravelling those symlinks.

Those in that list that aren't setuid, I believe are shipped from
Slackware that way. Those that are setuid are deliberately set to not
be readable, and although that alone doesn't solve any vulnerabilities,
in practice it does help to mitigate those whose exploits depend on
altering a copy of a setuid program.

I don't wish to diminish your contribution in any way, but I do hope to
present a potential alternate approach. Interestingly, I was intending
to suggest that my approach mught be "closer to 'stock Slackware'",
but I'm left wondering "is it?" On the one hand, I deliberately don't
install some of the packages that you're suggesting would be replaced,
while adjusting file permissions on some files that do get installed.
On the other hand you're suggesting to simply replace some packages
(and portions of packages) with a single package, making use of
Linux capabilities to negate the need to adjust any file permissions.
It's hard to say that either approach is closer to "stock Slackware",
or that either is really "simpler", yet they both accomplish their
intended missions to reduce the likelihood of system compromise by
exploiting setuid binaries.
--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca ----------------------------------------------------------------------

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 31 May 2026 18:27:00 -0400, jayjwa wrote:

It would be fully possible to do the same with the stock Slackware
binaries:

Of course. But when I got shot down suggesting mtr-packet be set
cap_net_raw I realized I didn't want to fight this battle - at least on
LQ.

Sorry, it was probably my post on LQ that you are referring to. I agree
that replacing setuid with a setcap can make things more secure but
applying a new setcap to a file lacking setuid might give normal users
the power to mess things up.

Umm...that's exactly what I did.

Sorry for the confusion, I did not study the files you linked to and your
text "This is a Slack build (but not a SlackBuild)" made me think that
you hadn't written any SlackBuild script to create a package but only a script that built and installed the software.

regards Henrik
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 31 May 2026 19:36:24 +0200, Marco Moock wrote:

The manpage looks like Slackware provides an old BSD inetd version.

Yes, in /usr/doc/inetd-1.79s/README you can see that the "s" in the
version string probably means "Slackware" as Patrick Volkerding has made
som modifications.

regards Henrik
--- Synchronet 3.22a-Linux NewsLink 1.2