#78179 - [PATCH 0/4] Add wireshark-service-type with privileged wrapper

Package	Source(s)		Maintainer(s)
guix-patches		PTS Buildd Popcon

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

Received: (at submit) by debbugs.gnu.org; 1 May 2025 08:27:24 +0000
From debbugs-submit-bounces@debbugs.gnu.org Thu May 01 04:27:24 2025
Received: from localhost ([127.0.0.1]:48365 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1uAPGN-0005nu-L8
	for submit@debbugs.gnu.org; Thu, 01 May 2025 04:27:24 -0400
Received: from lists.gnu.org ([2001:470:142::17]:39808)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@ditigal.xyz>)
 id 1uAPGK-0005nW-OZ
 for submit@debbugs.gnu.org; Thu, 01 May 2025 04:27:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rutherther@ditigal.xyz>)
 id 1uAPGE-0005m1-C6
 for guix-patches@gnu.org; Thu, 01 May 2025 04:27:15 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::] helo=mail.ditigal.xyz)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
 (Exim 4.90_1) (envelope-from <rutherther@ditigal.xyz>)
 id 1uAPGC-0001kB-Fc
 for guix-patches@gnu.org; Thu, 01 May 2025 04:27:14 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 7f1a4ec3
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Thu, 1 May 2025 08:27:09 +0000 (UTC)
From: Rutherther <rutherther@ditigal.xyz>
To: guix-patches@gnu.org
Subject: [PATCH 0/4] Add wireshark-service-type with privileged wrapper
Date: Thu,  1 May 2025 10:26:59 +0200
Message-ID: <cover.1746086472.git.rutherther@ditigal.xyz>
X-Mailer: git-send-email 2.49.0
MIME-Version: 1.0
X-Debbugs-Cc: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>,
 Maxim Cournoyer <maxim.cournoyer@gmail.com>
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746088029; h=from : to : cc
 : subject : date : message-id : mime-version :
 content-transfer-encoding : from;
 bh=m1VWQMXmQEXbweL+3Rz0fBl5IVqvug+0sijcEySdARM=;
 b=G6/hyoscK4Bsu/s7+em9y1wuuLkgt1Qx70HB9q/0jSndMVTUGryjJbxbYdIWhxHdnWZtx
 9CqwiylVr5hCkSDAw8B2UAD8OvK2rjQQzSe1/tL3PJ4y5G87mmLw1+8YZH8vWsa3064FejU
 gTFxmMi8IDoBZsXVsmjR/qzihy7MzhM=
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
 envelope-from=rutherther@ditigal.xyz; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.498,
 FROM_SUSPICIOUS_NTLD_FP=1.997, PDS_OTHER_BAD_TLD=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hi, recently I discucced on devel mailing list on the topic
 of a wireshark service type. I would like to thank Denis 'GNUtoo' Carikli
 who helped me a lot in coming to this idea. # Motivation 
 Content analysis details:   (3.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 2.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
X-Debbugs-Envelope-To: submit
Cc: Rutherther <rutherther@ditigal.xyz>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: 0.4 (/)

Hi,

recently I discucced on devel mailing list on the topic of a wireshark service type.
I would like to thank Denis 'GNUtoo' Carikli who helped me a lot in coming to this idea.

# Motivation

The issue with wireshark is that it refers to dumpcap from the bin folder of the output.
That is good usually, but not so with Wireshark as dumpcap needs to run with capabilities,
and the store cannot have binaries with capabilities.
In addition to that, dumpcap was wrapped with gtk wrapping phase, unnecessarily,
this complicates the matter a bit, since interpreted executables cannot get setuid or capabilities.
I think that is still something to look at in the future - wrap-program doesn't work for setuid/capabilities,
maybe it would be good to introduce wrap-program-binary that would make a binary instead for the wrapping,
but it's not topic of this patch series.

# Solution

The solution works like this:
1. #$output/bin/dumpcap is unwrapped (mv #$output/bin/.dumpcap-real #$output/bin/dumpcap)
2. #$output/bin/dumpcap is replaced with a shell script that looks if /run/privileged/bindumpcap exists,
   if it does, it is executed. If it doesn't, the original dumpcap binary is executed. Additionally GUIX_SKIP_PRIVILEGED=1
   will skip the check and start the original binary
3. The original binary is put to #$output/privileged/dumpcap (we can change the folder, but name of the binary is important here for privileged-program - it cannot change name)
4. The service will make privileged program referring to #$output/privileged/dumpcap

# Implementation

I've decided to introduce a new module, (guix build privileged), this module exposes just one function: wrap-privileged.
This function accepts:
- output - output folder of the package (/gnu/store/...-dumpcap-ver)
- original - path to the original binary under the output (bin/dumpcap)
- target-name - name that will end up in #$output/privileged
- #:unwrap - whether to try unwrapping the binary. This has to be #t currently to work properly (#t)
  only binary wrappers would allow for it to be #f.
- #:target-folder - what folder under output to put the target to (privileged)
- #:privileged-directory - where are privileged programs. I've exposed %privileged-program-directory
  from (gnu build activation) (/run/privileged/bin)

This function is then used in a new phase of wireshark wrap-privileged, that is happening
after qt-wrap (so that the binary can be unwrapped).
Additionally I added bash to inputs of wireshark, so that the shebang is patched
(I've decided to let this be handled by the patch-shebang phase rather than passing path to
bash to the wrap-privileged function which would add complexity, unnecessarily imho)

```
(add-after 'qt-wrap 'wrap-dumpcap
  (lambda _
    (wrap-privileged
      #$output
      "bin/dumpcap"
      "dumpcap")))
```

Then I added the service, referring to the wireshark/privileged/dumpcap.

# Future

After this feature is introduced into the Guix code, other packages could be changed to it.
I've checked the code and there seem to be a few packages that already patch the source to refer
to /run/privileged.
- singularity, spice-gtk: refer to their own binary.
- spacefm, udevil, zabbix-agentd, xsecurelock: refer to a binary of different package.

The second category is going to have to be thought through further, I am not sure
what the best approach is going to be. If to make shell scripts in the packages
or consider adding new packages that would have such shell scripts in their bin folder.

# Considerations

- Maybe the wrapped script should be a guile script instead of a shell one?
- Wrapped executables cannot work with this as was discussed in intro.
- I really had trouble coming up with the wrap-privileged function interface, maybe the parameters could be made more intuitive.
- Should this be added to the manual
- During testing I found out that wireshark binary doesn't pass GUIX_SKIP_PRIVILEGED env var through
  to dumpcap wrapper :(

Feedback welcome,
Cheers!
Rutherther

Rutherther (4):
  gnu: %privileged-program-directory: Export variable.
  guix: Add (guix build privileged) module.
  gnu: wireshark: Wrap dumpcap with wrap-privileged.
  services: Add wireshark-service-type.

 gnu/build/activation.scm    |  4 +++-
 gnu/packages/networking.scm | 17 +++++++++++--
 gnu/services/networking.scm | 35 ++++++++++++++++++++++++++-
 guix/build/privileged.scm   | 48 +++++++++++++++++++++++++++++++++++++
 4 files changed, 100 insertions(+), 4 deletions(-)
 create mode 100644 guix/build/privileged.scm


base-commit: d505cb960fd1e670be9a66d9fdbad94bc49e891d
--
2.49.0

Display info messages

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Tue Sep 9 23:27:22 2025; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

#78179 [PATCH 0/4] Add wireshark-service-type with privileged wrapper