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=TaE9qyqB; 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 B4B1F5A027C for ; Mon, 19 May 2025 09:39:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747640386; 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=vzF3DfwWD4WXBYkhox1Tm1MPhwFlHGGXzdOeR6rNVAU=; b=TaE9qyqBAL7RiyHo/9HYQvJQBgM3ZwX0D5MClnUuAlsnqYaCyV6QNGA25v2ZSy+HVcFSPS BU5mZn95/SPQD9LuePbWBzLZumusMkn3pYQQQagGLu5SPVjyqaKrAfTB9J2qNfHw+V7Z1m W/z/1CSHoKD401qymZ0HfLZR6h1npj0= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-jw8CT4fsPl6x99KDTAAkgQ-1; Mon, 19 May 2025 03:39:45 -0400 X-MC-Unique: jw8CT4fsPl6x99KDTAAkgQ-1 X-Mimecast-MFC-AGG-ID: jw8CT4fsPl6x99KDTAAkgQ_1747640384 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3a3660a9096so588225f8f.2 for ; Mon, 19 May 2025 00:39:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747640384; x=1748245184; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vzF3DfwWD4WXBYkhox1Tm1MPhwFlHGGXzdOeR6rNVAU=; b=ecY24tFHAMSniP8YVPG7vTgtQFdZvUxZmVSWUG60zr9dIY2qTfBx45e2WbJWJURrxe +nT6GTV/Ss7r+bUFBryzUNlp0YmX6521+FF1thSntTCS38yrDrvI38DpNEGBGn3Aq9tQ 4I0tovyMIUaozLcGFZ5lx914PjjBQc0NVDUY8mZRtecwV4KS/x+UucQJgqS7RCNbAQQB 58an6rOTSxH93hueonT4FQsTmt22Ibcr+YEFhEZv9V2ln9a1JcspHHePw71h0CfTuWrx wTB0PBqwnWQZY+OpM1QWUcw0uALRWALddn8+nmX8CKVt9Yuj6Md+jFN+7GUMwK3V2cmd LbBQ== X-Forwarded-Encrypted: i=1; AJvYcCXAZl5xfTognyQgM0c4ZXL35V2cFUm8UC2Ao26IwE7OnqnTvQPtvSL8vWQvDFze9znOl1iOQkd2OQE=@passt.top X-Gm-Message-State: AOJu0YzvgCb5ofPFKn6QxY2/hEsZ3ACw73IKgTnQ9sTv2YKyFIWGcDMF 9kDHVf2CmhkS/vPXtM8p5J2ubcA0BNTDWEIFEJmtRLX2aA2MbOGhG3n3CihRQ8CTPCQXvzK29dO eIix1G8UMYH3InweonFcKXp3DVL9KDRbW2/uxWqCask/6IX//vJ8Aww== X-Gm-Gg: ASbGnctjxVWSAtgDX+6+BH4XDmwMKyfcNfrnpBSEgP5n/9G9wOIUfM04yLeR6+X0zTZ nXWXwrsNTpjtfm4/XIjO0vlRHFDWnXAtM13ceiTVUHNjCY8Foh7Rrj4WGmTFVecTzo1bNmgsnGK 3iIYSpu3SeGvED3BRieACEA8PzEqGgIt5q+y3DnwXGmZD9j5CxvSg8DeKPe4lE0bENK05WTe03o Y5h99HsU0PfduehgNKxdV3qSdi63sP+XMMLesW2/tlpIZaCPGZn2G9r/v2A/6mBMe1EYwQFCTUk MLzTwi7UTMFKy6kgMsptgZ7yGm4MJmVf31qOpBZ0 X-Received: by 2002:a05:6000:4284:b0:3a0:a07b:15f9 with SMTP id ffacd0b85a97d-3a35c84c3bdmr11109871f8f.44.1747640383728; Mon, 19 May 2025 00:39:43 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFJtXDgHTq/z6g7txrf0d8xDkV4tSj6jdrQFCnoZSltnrgnL+Zrgoi8TL+TEbw+hKUZ/rf/bw== X-Received: by 2002:a05:6000:4284:b0:3a0:a07b:15f9 with SMTP id ffacd0b85a97d-3a35c84c3bdmr11109852f8f.44.1747640383330; Mon, 19 May 2025 00:39:43 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a35ca5aba3sm11598787f8f.40.2025.05.19.00.39.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 May 2025 00:39:43 -0700 (PDT) Date: Mon, 19 May 2025 09:39:41 +0200 From: Stefano Brivio To: Max Chernoff Subject: Re: [PATCH v2 1/1] selinux: Transition to pasta_t in containers Message-ID: <20250519093941.4503ae47@elisabeth> In-Reply-To: <3eaa88568e808eed15c49a05515954b51cf35c4e.camel@maxchernoff.ca> References: <20250514104413.197448-2-git@maxchernoff.ca> <20250516051105.432590-2-git@maxchernoff.ca> <2a88e380-05ad-44cd-93c7-b4073e72f242@redhat.com> <99d5f0fb46342ef9675612e64464444e187e4ee7.camel@maxchernoff.ca> <8703e232-0763-4d07-8803-e2f54aaed3f2@redhat.com> <20250516181102.6647635f@elisabeth> <3eaa88568e808eed15c49a05515954b51cf35c4e.camel@maxchernoff.ca> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: dBAg6bfUcM86W-hAJc1qJANAEV9qDiRZdfSPxO3aDpU_1747640384 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: KV76QYWMWANEAULVWCRSBPME2IADK3TQ X-Message-ID-Hash: KV76QYWMWANEAULVWCRSBPME2IADK3TQ 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: Paul Holzinger , 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: On Sat, 17 May 2025 03:34:42 -0600 Max Chernoff wrote: > Hi Stefano > > On Fri, 2025-05-16 at 18:11 +0200, Stefano Brivio wrote: > > Max, could it be that you're running stuff with some customised SELinux > > policy? By the way, with "unconfined disabled": > > Simpler than that: I was testing something with SELinux permissive, and > I forgot to reenable it. Whoops. I'm getting the same results as you > now. > > > Running with SELinux in permissive mode, I'm getting: > > > > # cat /var/log/audit/audit.log > > type=AVC msg=audit(1747410763.621:130615): avc: denied { search } for pid=1352409 comm="pasta.avx2" name="1352408" dev="proc" ino=7022238 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 tclass=dir permissive=1 > > type=AVC msg=audit(1747410763.621:130616): avc: denied { read } for pid=1352409 comm="pasta.avx2" name="net" dev="proc" ino=7022285 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 tclass=lnk_file permissive=1 > > type=AVC msg=audit(1747410763.622:130617): avc: denied { read } for pid=1352409 comm="pasta.avx2" scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 tclass=file permissive=1 > > type=AVC msg=audit(1747410763.622:130618): avc: denied { read } for pid=1352409 comm="pasta.avx2" name="ns" dev="proc" ino=7022284 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 tclass=dir permissive=1 > > type=AVC msg=audit(1747410763.622:130619): avc: denied { open } for pid=1352409 comm="pasta.avx2" path="/proc/1352408/ns" dev="proc" ino=7022284 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:container_runtime_t:s0-s0:c0.c1023 tclass=dir permissive=1 > > type=AVC msg=audit(1747410764.622:130620): avc: denied { read } for pid=1352417 comm="pasta.avx2" name="net" dev="proc" ino=7022285 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_t:s0:c609,c838 tclass=lnk_file permissive=1 > > > > and: > > > > # audit2allow -a > > > > > > #============= pasta_t ============== > > allow pasta_t container_runtime_t:dir { open read search }; > > allow pasta_t container_runtime_t:file read; > > allow pasta_t container_runtime_t:lnk_file read; > > allow pasta_t container_t:lnk_file read; > > > > If I add those rules, everything works > > Yes, adding those rules also fixes things for me. > > > To me those denials look reasonable, in the sense that I would expect > > the namespace links to have container_runtime_t type. > > I'm a little surprised that "container_runtime_t:file read" is necessary > since I thought that "container_runtime_t:lnk_file read" would be > sufficient to get the target of the link, but it indeed does not work > without it. > > > (well, I'm not saying that's the solution...). > > I guess the options are: > > 1. Add the above rules to the pasta SELinux policy > > 2. Have Podman change the context of /proc/self/ns/net to pasta_t > > 3. Have Podman pass a file descriptor to the netns instead of the path > to the netns. > > (1) is arguably the least secure, but is probably fine in practice? Well: 2. is probably the most restrictive but it doesn't really feel correct to me (pasta is not, at least conceptually, the exclusive user of the network namespace link) 3. is pretty much a way to dodge LSM policies (SELinux / AppArmor can't see this, done) ...so I would opt for 1. I see why you mention it's less secure: we didn't really want to be able to open and read *any* container_runtime_t:dir or container_t:lnk_file. But that's not really the part of "fine-grained" security that we typically delegate to SELinux anyway. > > Max, could it be that you're running stuff with some customised SELinux > > policy? By the way, with "unconfined disabled": > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2330512 > > > > we seem to have unconfined_t as type for those links: > > > > type=AVC msg=audit(1733378482.320:31258): avc: denied { open } for pid=651955 comm="pasta.avx2" path="/proc/651954/ns" dev="proc" ino=2904841 scontext=staff_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dir permissive=1 > > > > ...but I'm not sure at which point in time exactly. > > Ah, I wonder if that might be related to this: > > https://github.com/containers/buildah/issues/6160 > > But with the workaround documented there, and the rules from above, > "podman build" works as expected with the unconfined module disabled. Ah, great, then I guess we don't need to fix something that's not broken. > > Wait a moment. I don't think something SELinux-specific belongs to > > pasta's man page, because that's not relevant for all users and > > distributions. > > > > We could maintain that as an addition for Fedora and perhaps Gentoo, > > but I wonder if it's really worth the effort. > > +1 ...so I guess the only remaining point, other than adding those rules, is to figure out why %selinux_relabel_post isn't enough and what we can add to the spec file instead. I'll try to have a look at it within a couple of days unless you find an explanation / solution before then. -- Stefano