From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202606 header.b=qGefMR0+; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 5465C5A0275 for ; Wed, 22 Jul 2026 10:11:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1784707865; bh=jfdfLkG8i9YS/CxRwEaJi/211fQbLNsYC57rTyAmU1c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qGefMR0+afuVIgY8lUzzu1zLr2WGBRCEYKv53LTyoOVxKihWA29FK9rQmpUGDrDeL fUAoxN6VtweeLdhhKh1NFCzHU0Zy2W7XoDVAn9Tt/+XSQ+zVgJRlhCJm9/W/f4NqiQ w+unoKu2cPymDvCJylIaW8jRa3pa5m3hpDTwavEadVV08pOkQztr1EJcYDbiJbvY4M rlxEutdN/bL3obv/u5aScPDm8EJpWJSJy4RjhY8BDaeuWVhJfHg+uARzTidMFXAszM JcH01hXnyW5QF+yafPVTjbvFP/w/8afuUnbafJr2atDcJ3XlNrI3WnwXqjEj4SazOp kPCUrE801fP5A== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4h4n5559YJz4w2D; Wed, 22 Jul 2026 18:11:05 +1000 (AEST) Date: Wed, 22 Jul 2026 18:10:57 +1000 From: David Gibson To: "Lawrence, Richard E" Subject: Re: [PATCH v3] feat: Add cli option '--pass-fds' for pasta mode. Message-ID: References: <20260719200300.201469-1-rlawrence@tamu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6xiUS8KtmGRoXQTR" Content-Disposition: inline In-Reply-To: Message-ID-Hash: JIKQYDDNEDSXFJDG375OZOQG3PPN2AAA X-Message-ID-Hash: JIKQYDDNEDSXFJDG375OZOQG3PPN2AAA X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "passt-dev@passt.top" , "jbash@jbash.com" X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --6xiUS8KtmGRoXQTR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2026 at 04:44:05AM +0000, Lawrence, Richard E wrote: > Hello David, >=20 > Thank you for your feedback. I see your point that I haven't made > the case why this feature is worthwhile. I would like to explain how > I came to my position. Thanks! > I want to do bubblewrap + pasta so that I can give my personal agent > sandboxed code execution to support SKILLS.md extensions. A very > common pattern in SKILLS.md is python code with inline script > metadata dependencies so that uvx can generate ephemeral virtual > environments on demand to run the scripts. This strategy requires > granting access to the internet, but I still want to deny access to > ports on localhost. I don't want a confused agent or malicious third > party scripts to have the opportunity to tinker with other services > running on my machine or those of my office neighbors. Sounds like a good plan. > Pasta seemed > like the right tool for the job. It can distinguish between local > area and wide area outbound traffic. So, not really relevant to the topic at hand, but a small word of caution here. I'd say pasta definitely aims to be the right tool for this job, but I'm not sure it yet does everything you want. We do distinguish between localhost (127.0.0.1/8 and ::1) traffic and other outbound traffic. We _don't_ otherwise distinguish between network destinations, though, so it won't really protect your network neighbours. We do intend to add forwarding/filtering rules for outbound traffic, but it's not done yet. > I tried many, many combinations for getting bwrap and pasta to get > along. >=20 > I assume that pasta should be running before the sandboxed command > begins to run in the container, since almost the first thing that > would happen is the package manager uv reaching out to the internet > to gather the script's dependencies. If pasta joins the namespace > created by bwrap, then I have to somehow delay the start of the > script execution until pasta signals that it is ready. That is a > very scary proposition to me; I am not sure how I would do it even > in theory. So that makes me want to start pasta first and then start > bubblewrap. Ok, fair point. Delaying the start of the internal command can certainly be done, but it is pretty fiddly. > On the other hand, since bwrap can't yet join existing network > namespaces, it turned out to be a really difficult problem. I tried > wrapping bubblewrap in nsenter, but that exposed a really subtle > issue with nested namespaces. I don't 100% understand it, but in > short, inner namespaces tend to implicity drop capabilities if they > aren't very precisely managed. So the result of my attempt was that > some commands like ping would not work inside the inner namespace > because the user in the inner namespace didn't get mapped to the > range of users in the outer namespace who are allowed to execute > ping. Ah! I'm not certain, but the problem here might be not to do with nested namespaces per se, but because nsenter usually drops the capabilities it gets by entering the namespace. Or, more precisely, it doesn't by default allow the caps it has to pass on to the command it spawns. Try adding --keep-caps to the nsenter command line - at least if you have a new enough util-linux. I added that option myself ~3 years ago to deal with similar sounding problems (unshare has had a similar option for much longer, I just added the nsenter one). > I tried executing bubblewrap within pasta. And it's so close to > being what I wanted! It's a simple one-liner and for some reason I > don't understand, avoids the issue with the nested namespace. But it > still isn't what I wanted, because another thing I like to do is > deliver bwrap's many many args to it via a file descriptor (--args > FD) to simplify the process name for ps and avoid leaking private > information to anyone else running on the same node. But since pasta > couldn't pass FD's through to bubblewrap, so now I have to wrap my > bubblewrap command inside some other bespoke script whose job is to > open a temporary file I am serving somewhere, which just becomes > another opportunity to leak my private information. Right. I certainly agree that passing the fds into your command is a good approach. The question is whether there's a practical way to do that without spawning the command directly from pasta. > Sidebar: if you think about it, the only reason the nsenter strategy > can even be considered a "workaround" for pasta not having --pass-fd > is that nsenter does have the feature to pass FD's through (in fact, > it is the default). That's not a good look for pasta. Well.. it's a question of the context for each program. nsenter is a system tool, it's not really it's job to restrict what you or it can do beyond what the kernel enforces. pasta, on the other hand is an end user tool that has to process traffic from an untrusted guest. For that reason, we try to have multiple layers of defense to limit the damage even if a malicious guest takes us over completely. That's why we close all open fds on entry, not because it's something that most programs would do. > Sidebar: Yes, it can be said that my problem would be solved on the > bubblewrap side if only bubblewrap could join an existing network > namespace. I also submitted the PR to create that > feature. Nevertheless, I feel strongly that passing FD's has other > plausible consumers besides specifically bubblewrap. So, yes I think for the case of bubblewrap specifically it would make sense to do some integration there. But also, agreed, it's certainly not the only case where passing fds is useful. > In the end, I felt super, super frustrated because what seemed like > an easy problem turned out to be nearly impossible. In my workplace, > I am considered the local expert on containers, and even I couldn't > figure it out. My LLM coding agent couldn't figure it out > either. This would be completely hopeless for some gamer trying to > isolate network access for a multiplayer game installed via flatpak. That's understandable. It does seem like doing this with nsenter is rather trickier than I had thought. Would be nice to see if --keep-caps is the secret ingredient, though. > I teach the container shortcourse at my institution, and I genuinely > care about the future of this technology. It is my hope to help make > modern lightweight and secure container technologies as > user-friendly as possible, so that more people will choose them over > "sudo docker". If we can reach a consensus regarding the ideal scope > of this feature, I will gladly address all your technical > complaints. Ok. You've more than halfway convinced me. Here's what I'd like to see: 1) Check if starting pasta first then running bwrap under nsenter --keep-caps can do the trick. Even if we do make the change to pasta, it would be nice to know if this workaround is usable for older versions. 2) Look into implementing this by delaying isolate_fds() until after the command is spawned. 3) If both of those fail, then I agree the case for --pass-fds is strong and I'll no longer object. > If you read this far, I am grateful for your attention, and I > apologise for rambling. It is late here, and my brain don't work so > good just before bed. I know the feeling. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --6xiUS8KtmGRoXQTR Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpgewAACgkQzQJF27ox 2Gfz1A//cXlLs8zkEsbRkOUimn/M4/sEkiDO3UaBsF+b/wKbpSCCvpWochxLK1ca 6YLq5KG3TRaRAaCEZUlTUGUmmH22brJYr/83mnI6Tv7XQyDFHDO1hI4lOwcUE+wN UF1R97kAUf3JBDpWN4LVHpr49S16wHQD6eZ5ZiQq94FUoh9XwOvkBeBd//37+ztO C1TYMHl6TDx6+4uGji9SYsZ2aqaq2EbcEZSCvA0luUr/Fd+LFy418GhFZqfb5FNp kTw2lGm++XB7V44xBMTzsAZtxdALY04EQDRYBQ+hGw/sitMg0SqjOX5P4AhcwinE aTOajkJ69pyByvSv6yI89qPg/y76S89byCDQHA2j2AHVUHMsI/f+J3lFIP9hvw6y 5kXQVqahvwGCX1YkKNGKDh4/nL4+8Quym2I2yPKF39nUbjxF/Mc165UBze6aym2E onLajRC/hMCsUD3bjBNpjFlQKU+twpVZcrUOLgdmxyFuR2D4Q7JtyN8zzSHuaFQJ thDpdQmvJZU8tbcr1MoZwqGIfrULmTlvCneeGiolEBRnbfDKnsXKjZcUXXJQyYuC igdlXNwmbuxILLbOW9/CZCK63eOiLUCLjs3v/gvolOz66A6UebAFPaibkRae4Va+ 8/h2M9r8pPeFkyEeBmcJNFfQEu3WmVI9zSP7w/Ka2grrLyn0kN0= =pgqK -----END PGP SIGNATURE----- --6xiUS8KtmGRoXQTR--