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=MMDKAirw; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 2E02E5A0265 for ; Tue, 31 Mar 2026 21:48:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774986485; 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=KIsFbQNgRgEVO2ix+Z48BdWkuFh28vOWhSbZf5GA7bE=; b=MMDKAirw6qQkIYcC1E8SRfaXZTNdY4BaWrsBQWP0CRYiF0jNxdrdeR8tduBQrowvGYkOZa MN6vIvSdWmRRy85JlaFJMeifM+NK84dr7Kmv+lAI+6CSuyRCH+ngLlJnI7eHfcA4L2tOgY ozjuKX/+aUafxQcsQ/eeL0FeKdlN6lI= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-oRvgcYM8NUWTTzFGCMWewQ-1; Tue, 31 Mar 2026 15:48:04 -0400 X-MC-Unique: oRvgcYM8NUWTTzFGCMWewQ-1 X-Mimecast-MFC-AGG-ID: oRvgcYM8NUWTTzFGCMWewQ_1774986483 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-487018c8244so38339675e9.3 for ; Tue, 31 Mar 2026 12:48:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774986482; x=1775591282; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KIsFbQNgRgEVO2ix+Z48BdWkuFh28vOWhSbZf5GA7bE=; b=gpEvk1oDVxA69D1ymYSmaqxhc6u6qwgyXo75F71NpXgMRfGidtZpWoLpq+Ryjz73Qm /4dwMK4dbJI2ENER54w+ugWvH8npjRbT2pV8YpjU2+ot6vnaTBlx2CO8Aj5HWFrAciIx uxXhigwnXTXnpgS6O0u53/NAWAWOvwH50OZ8sQWIzL9K3eVS5fZvuEQOQbi28MySozG/ EfErBn3byxTs8/5wbXSLwi5asgJS4tTGUhfvY8oH9uTnfTbkXnKr3haVFVL9NkSyn1FC XkDmIFvPkTeqCd81keDkaZkZsru1U5SaDI+B+kuhB5FxBMPAC7UuXb8itUiDk1rUIaEk SCSg== X-Gm-Message-State: AOJu0Ywrdaz2z0ow0NwPKs9T7e5lPwR+1DMtwCXBC2zkHgd+IIPJGXJ6 CkIki8gY5LuRnqXLy3gXSAkl5ZjayUgJRPscFEqKXMcBeAGMaIbiA3dy4sjl14VsGhGZ64yX0hf p7sKZL2DeQLtEBOZhLtUpeq+VMlG4nHqj08x/UPnnaoz2hr9wcZCCuw73lNn+gB1lFRiLdcvxoX pe1dgzrsWAhBjrEcs4galenHrjCdJNAKK10bBH X-Gm-Gg: ATEYQzwQ6Cg9C0uLH7ZRx2u8nOKi21X9k8O4LOZ7o8SvlZU8J3kFyxGMsLt7tKSt3+n 2CdSHjTR0CnXjWQDFOORnerdnTHV5SJ2vSwRgZ4arLz16ntUpTLMd/ya+HfuslmCohr4ks98IIz dHKUebMAKMytt5Jx6G0O4t2Qv5wMc4CT6461J7N8eSBCszoiG4iKAi5O1rFiQRwrXEbE1lIRZc1 3D677lY5QZ6Qunf/Thxq/h1YYvy9H19Mc0FzDcWIDU5rYFmyRRhas4rbFCAcf5iqjvoi1mWPnNh j4zgpWMwQo3vYgK9Boq7Z+3oBuSR+vzMkWSLE8oXWxEk4EBa+QOqRD2ZQ/OzdybSl7PcBKx4T5z gBW6lhfgPY6EPt3WNBMEdmdsm7NyEFSysweExRIKz2SPj791Prw== X-Received: by 2002:a05:600c:c04a:b0:486:f9aa:2b57 with SMTP id 5b1f17b1804b1-48883597e39mr8511885e9.16.1774986482297; Tue, 31 Mar 2026 12:48:02 -0700 (PDT) X-Received: by 2002:a05:600c:c04a:b0:486:f9aa:2b57 with SMTP id 5b1f17b1804b1-48883597e39mr8511245e9.16.1774986480621; Tue, 31 Mar 2026 12:48:00 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e735532sm72907645e9.0.2026.03.31.12.47.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 12:47:59 -0700 (PDT) From: Stefano Brivio To: Johannes Segitz Subject: Re: [PATCH] SELinux: Dontaudit access to dri devices Message-ID: <20260331214758.227f3fac@elisabeth> In-Reply-To: References: <20260330110557.2569119-1-jsegitz@suse.de> <20260330171541.15a8b5d0@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Tue, 31 Mar 2026 21:47:59 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: yezT5Rj1WoUPmghWaQdW4hZ8MkGgj8SIzANXExuQzo8_1774986483 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: LOWLXEOBXIG2YRDF6BLQQSCGM2Q3ZHPI X-Message-ID-Hash: LOWLXEOBXIG2YRDF6BLQQSCGM2Q3ZHPI X-MailFrom: sbrivio@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, Paul Holzinger 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: 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. > > 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. -- Stefano