From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=D5AvD+Zh; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 7704B5A0262 for ; Thu, 02 Apr 2026 14:24:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775132696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VwzvYCdqqVsF6sGV20zUHSQTItPKwwlosloH4UPANfM=; b=D5AvD+ZhtD8eyxHcfFLIka+p5kCyyNH3HR2mC631+htzS6tFjjmOy/eiosBhVVhUDTCSBZ hkmQDTBmdW8s0wC25f6Iix74Nywnpdg6XuW1cP2iuv1jFpKx05u3fhZLkDvpMI0rdZXwFv szMcJx1ZcULEJDB7bz7pDjrObNm8xBE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-157-NFJcqwHXM2-EadfRLtnGNg-1; Thu, 02 Apr 2026 08:24:54 -0400 X-MC-Unique: NFJcqwHXM2-EadfRLtnGNg-1 X-Mimecast-MFC-AGG-ID: NFJcqwHXM2-EadfRLtnGNg_1775132694 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43d07f0aca0so673745f8f.3 for ; Thu, 02 Apr 2026 05:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775132693; x=1775737493; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VwzvYCdqqVsF6sGV20zUHSQTItPKwwlosloH4UPANfM=; b=c47AyTsk6tDoJFCJhcsJm9nkMQjvDBSws9HnqL6S4ocm99Dy6FCAYQCJ1+9m7JJ4x9 p4stck6h3k8Zxr8hZxbPRZS7gJf3WNTPB+lfaTgZEmAr03GK3jysCpmdEJvF9z/9Uhnx 63gHM8wlUhEu0JAYgHXZY1bXkSoilv8/PUhFTYOEFS6vodW92Nou3nPo/MAdd9PB3G8J i/aHTXuNg7UH6xByMNBpj5WYFTV2q6+mr6UFC6LzmtXMLERBAkW7VkkxLM8eWe5XjKog cye3a4XEWR7KwdTyod3ptUGbm3tDBIo8NEfRv6AwWsItSRXl4eTcX5uWZ86R82sNAv20 dWoQ== X-Gm-Message-State: AOJu0Yyf+M3NcTSkie//H+PLRsr1NLzt2033Zg6juADncUEDuxo//bfM PF4ZL22Ok/j0ytVzQtNkVZMet34LqTXp6HQVEKyy/hyqUexmy+R+fqaplYSGRVHkyVPFA8sW381 R+abX1YXIRcmKNpwBZcjFnghgJ41HJeK0gWx7/emSb8XkAvDBDtNh0R+2mw5wow== X-Gm-Gg: AeBDies3dj1+vSe1Ihx2cm2Q4RGgQdTBepPXwsTEz2rK4yRGMPyDovh5IoO1MYM5r6n Wr6nrzgiU8ejyqPYroCbtxOWcK0viAYZUDTCOEZ6seCcdvTh2IbE0BmIxTe8U3aC6mEiJkHz2QR y2E3S4KbTx4seOu0550WENAu6ZZXEEoqWKJGhrSmgKXydSjR9eQmI4CDWrxPqvVdaF5Whg5XWiN oE8bRwGe1Dn1eV2RxCDBoXB3lsFNQYyBBq3wT4ZsqPGK5Cpf84/jsG4CB8oIfNeTVxuDeXgJNtn ZREG9jj4oIN1EUegsP3Q71XX+qhZ/TxSyXfYj0EZ0yYs8h2kwhhJ7VwTgHfdKARQDpbwKA4cHgr R/Q+DQ8ZsihAZs3Gjx/il/g5sveg= X-Received: by 2002:a05:6000:22c9:b0:43d:71b:204b with SMTP id ffacd0b85a97d-43d1f25abc3mr5864746f8f.39.1775132693153; Thu, 02 Apr 2026 05:24:53 -0700 (PDT) X-Received: by 2002:a05:6000:22c9:b0:43d:71b:204b with SMTP id ffacd0b85a97d-43d1f25abc3mr5864685f8f.39.1775132692619; Thu, 02 Apr 2026 05:24:52 -0700 (PDT) Received: from [192.168.188.22] ([80.243.52.136]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d214f2b63sm4519648f8f.28.2026.04.02.05.24.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2026 05:24:51 -0700 (PDT) Message-ID: <3b5af0d8-1f88-4190-b4ac-5bab780b2781@redhat.com> Date: Thu, 2 Apr 2026 14:24:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] SELinux: Dontaudit access to dri devices To: Stefano Brivio , Johannes Segitz References: <20260330110557.2569119-1-jsegitz@suse.de> <20260330171541.15a8b5d0@elisabeth> <20260331214758.227f3fac@elisabeth> From: Paul Holzinger In-Reply-To: <20260331214758.227f3fac@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: muTXS4i_1cHQzUEHLUQWRmBX3C09VcZ9fDOd8LuVxKE_1775132694 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: V356DBYUS5YUQ447G6ZAPDN5TSPTMAMG X-Message-ID-Hash: V356DBYUS5YUQ447G6ZAPDN5TSPTMAMG X-MailFrom: pholzing@redhat.com 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 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: Hi, On 31/03/2026 21:47, Stefano Brivio wrote: > On Tue, 31 Mar 2026 09:00:47 +0200 > Johannes Segitz wrote: > >> Hi, >> >> On Mon, Mar 30, 2026 at 05:15:42PM +0200, Stefano Brivio wrote: >>> On Mon, 30 Mar 2026 13:05:57 +0200 Johannes Segitz wrote: >>>> Currently podman can pass a FD to a DRI device to pasta, leading to AVCs >>>> like this: >>>> avc: denied { read write } >>>> comm="pasta" path="/dev/dri/renderD128" >>>> scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 >>>> tcontext=system_u:object_r:dri_device_t:s0 >>>> tclass=chr_file >>>> These are harmless, so dontaudit them >>>> >>>> Signed-off-by: Johannes Segitz >>> Thanks for the patch. >>> >>> I'm wondering how can this still happen though, as commit 09603cab28f9 >>> ("passt, util: Close any open file that the parent might have leaked") >>> should take care of those. Do you happen to know? >> No, I just read the code and it seems like this should prevent this. I >> unfortunately can't debug this in depth, because it doesn't happen on my >> system. The reporter is helpful with debugging, but going into gdb sessions >> with remote hands doesn't sound feasible ;) > Yeah, I see. :) ...I finally had a quick look at it. > > I think it's actually good that SELinux caught this, because *maybe* we > just call close_range() too late and things would be fine otherwise, > but if not, we would leave pasta running with access to an unrelated > device, which isn't great, even though we don't run as root so it's > unlikely we could really do something with it. > > By the way I wonder if it's similar to this report: > > https://bugzilla.redhat.com/show_bug.cgi?id=2374197 > > which I never really tried to figure out. I described here I think: https://bugzilla.redhat.com/show_bug.cgi?id=2374291#c10 There is never time to close fds earlier, it validates sometime during execve(). My guess because that is the point where it transitions into the pasta_t context so it checks all files against the new policy? So any leak warnings are impossible to avoid on the pasta side and must be fixed where we leak them. Johannes it would be good if you can find out where that files gets opened? Is it Podman? The go runtime uses O_CLOEXEC but we do have some manual open calls where we might forget it and as such leaks, it would be good to find and fix them. It would be good if you have a reproducer. >>> Perhaps the access happens before we call isolate_initial()... but then >>> I guess we should try to close leaked files before that point, to be on >>> the safe side? >> Would be worth a try. If you have a patch for that I can provide an updated >> package to the reporter and ask him to test it > Assuming that the kernel version is >= 5.9 (otherwise we don't have > close_range() at all), you could try something like this: > > --- > diff --git a/passt.c b/passt.c > index f84419c..d5dad4c 100644 > --- a/passt.c > +++ b/passt.c > @@ -340,6 +340,8 @@ int main(int argc, char **argv) > struct timespec now; > struct sigaction sa; > > + close_range(STDERR_FILENO + 1, ~0U, CLOSE_RANGE_UNSHARE); > + > if (clock_gettime(CLOCK_MONOTONIC, &log_start)) > die_perror("Failed to get CLOCK_MONOTONIC time"); > > --- > > and, if it doesn't work, try to close standard error as well (no idea > why a DRI device would be passed as standard error but I'm not sure why > we would have it as any other open file descriptor either): > > close_range(STDERR_FILENO, ~0U, CLOSE_RANGE_UNSHARE); > > ...all the way to: > > close_range(0, ~0U, CLOSE_RANGE_UNSHARE); > > ...if that doesn't work, the next thing I would try is to add a delay > in the Podman thread starting pasta (or even there at the beginning > of main() in pasta itself), use that delay to attach with strace (as > root, pasta won't let you do that otherwise), correlate timestamps > with SELinux logs, and from there everything should be clear. > -- Paul Holzinger