From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 386AEC4167B for ; Wed, 6 Dec 2023 20:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2BFB6B0096; Wed, 6 Dec 2023 15:47:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDA3F6B0099; Wed, 6 Dec 2023 15:47:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7B1D6B009A; Wed, 6 Dec 2023 15:47:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8FE176B0096 for ; Wed, 6 Dec 2023 15:47:27 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 68A5A4027C for ; Wed, 6 Dec 2023 20:47:27 +0000 (UTC) X-FDA: 81537578934.05.FA0EA12 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf18.hostedemail.com (Postfix) with ESMTP id 63A701C000E for ; Wed, 6 Dec 2023 20:47:24 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=HAv+gXKK; dmarc=pass (policy=none) header.from=paul-moore.com; spf=pass (imf18.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=paul@paul-moore.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701895644; h=from:from:sender: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:dkim-signature; bh=03m9Q/bw886YTDz9qjzlgtiRQh+DJJBl0Kee3WcgMyc=; b=nP53Tu0Gk5YMbv/z+kAwWMtRmbVwgC3LOKVU20GgoC5neuVMzfJOSmZN0PhIOpc2bKaTPs cARoNFKA7fsaFEMP6oePxpmeVWyAke3Z75cX9FTVgJf43RtcqnqtIi2uwPUGlUSac/jO4u KEY4sWMvjEYWgT9Jqeov4TunwgIc7Yk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=HAv+gXKK; dmarc=pass (policy=none) header.from=paul-moore.com; spf=pass (imf18.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=paul@paul-moore.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701895644; a=rsa-sha256; cv=none; b=NKkCpYHfDy+uwcWqi2orA8kFRKd6EWVcCenBur0V6zI1H21OAOp6luWJRVPK1rKNpetK5U vlMh39hOASsTNCZG5BLI7cYcoEG982+trm7LTDbMZdJLbdTWEC/Wm8J6j4GDfsC0XAoJS7 cwa0ozFQQILY7KaP4CZz79pcGsu1AaA= Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-db632fef2dcso256692276.1 for ; Wed, 06 Dec 2023 12:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1701895643; x=1702500443; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=03m9Q/bw886YTDz9qjzlgtiRQh+DJJBl0Kee3WcgMyc=; b=HAv+gXKK9B8NzVGog371u56U0lrvigBLMVfMPgkFSQFJvT2RQkjEwW6/ZdW7ySrSFT EzukEwJW1UCQ/OGpzrl97R93MeBKaqYTdaXmoQAqvFHgJ9QUz7L88jrY1Xpm870CxNLK sbz7s/bwOx82iwqUK9ywalrXMrQrQ0aXms0MmbsOBvA84U5v4+gwFPChG4BEiFRnTV6U iF+FuJeWhmQU9UY6X0MQw0BThEB/mnWkrK8lHrtO4dotF/nu2XTpfOeKoU8vnK834AsG Sc2SY/6RA4nP1B95YBujwBO5ChIzUTniXq08G2EdKCRV4GFNsCA3yw+jw65KZ2BADVvD LT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701895643; x=1702500443; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=03m9Q/bw886YTDz9qjzlgtiRQh+DJJBl0Kee3WcgMyc=; b=cV2gWd2Wr859FFE2SX40VthqYp9m6tHuS0RbfKnZz0w//bJ204Y/LsDqw87qO15Cr5 xzdZFndih72eHdDBw7vkEqgPjLFQqXw5w0cIE5gFUNVgkLQYVSQpsRPS/eqqltXE3ul/ sLuCg4MVNS7F+xDCWNL5eSYvYc3Q4s8WdBfAca+5PmU/uFSpcUkx9T+04aiKS2FGXx+s 2JYFB2hte3a6dOUMoDlMzoXC+kn0ivXmbMXTlp3WgC0A5P4IKw9ewr/KT3m59aGp+aMw QNhR6RenLu69r6QmKgQ7sQzhd/gykX8FTwlintvpYnyIZJXjOeQL+r/Wtv+a+mLFIFnc h20g== X-Gm-Message-State: AOJu0YxoKBZwQ0ci13c5C6XasAsknF/x9dpD0QsKvzIZD5UO5EPJDxCv qvHT1HkY4Ag27u7PABAf3Ktz3XcpJCHfjHIR9XZS X-Google-Smtp-Source: AGHT+IELdineb8nV+rdBDWW20nkuyyqa6PVAuAq/4Di/FEXsDjy4VsrK+EqH8adItqywpLZ8SrW2ODMTgaG4l5FXB2o= X-Received: by 2002:a25:1657:0:b0:db7:dacf:59fe with SMTP id 84-20020a251657000000b00db7dacf59femr1189834ybw.114.1701895643131; Wed, 06 Dec 2023 12:47:23 -0800 (PST) MIME-Version: 1.0 References: <20230728050043.59880-1-wangkefeng.wang@huawei.com> <20230728050043.59880-4-wangkefeng.wang@huawei.com> In-Reply-To: From: Paul Moore Date: Wed, 6 Dec 2023 15:47:12 -0500 Message-ID: Subject: Re: [PATCH v3 3/4] selinux: use vma_is_initial_stack() and vma_is_initial_heap() To: Ondrej Mosnacek Cc: Stephen Smalley , SElinux list , "open list:MEMORY MANAGEMENT" , Kefeng Wang , David Hildenbrand , peterz@infradead.org, Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 63A701C000E X-Stat-Signature: h6yk9tbqssyjuxrup44jy4kf4jqffj4d X-Rspam-User: X-HE-Tag: 1701895644-159238 X-HE-Meta: U2FsdGVkX1+W8bIeztQX5cHdZgqMeSveS9bpj6aTGdXclAbPPelyiCKmah2rjt3QMp6w1+VQM42Vz0roa1x6mUHIfZT3ibuRD8ePjBhi5FWEG3Wq2xvcBfA9kS6Go2wenItGZZG8ehy+A5zkeqacenRRDR2iWN5q6r9ifL+uSxBNEBhUzK6up5/9JF06L3YcfVjzrw3HGaJAGmZB3l9hacxJwdju1+C2Sh842b+cG8b4zYzXlx9H1mgNX0vihw5e+hzVBCtQckKGf2GAEzMMXiqrAZi9M3ulX/ymw/2Rjul8km7uPKETUwc2dGrMG6L8hW2Z16FfPgVHEulHgmF/s7sHyvOxCMOEFz4pP/JTWqVAFuDMYYY8BIf+po2GHLT1BTbdt+mEs2SCsEjzimn3vw4c3xuAQl3OyOkgWGEf6uQoSCSNW+JDlhSY494tvhHRMVWo0/e/NdkU8XvttqRyn0Mebc9dYXSZr8WDG4EXGLfJ5jPkA20Oxy8XlZYADVegTp3ZWdWP62Gw7S/WwJ9di0MjLT+m7Rrv1wtytwxwjGnBoKUf6V21ep22Xx7wvpHHHfL0Uii/YKLFeHjHiHVfJ/Wmg1/NpdN/5mmLpxZYIacEVXGzgAfNVOHxvY9fs8rBOXta7ecmBFnpAWJbSIavkYQf2n6dgJPhV1ApT+uJkXYpM3Osw8XjzsU60V1Y2FaP2DoFnqke3E+KnAKTw7muvljuC4eBtl/XSx2YgSp+3oAoBEl9yRSjVHVKXPEPvur39ztDcYGD0fAbmUGclfC1drEEqGCZ9noj/PBq3pPmQ8iJBblHX5mpuNrTvRYTe9BJ/hlhl9ch4QBbmv0+Ky2m7qqhgS/PFsTIRu5OTqHGx3NFIGduURiKQ1DJXIGX8lpcOKjfLS/etWJf+33sHgUBsncgln2hM/PdvYLAXCZuj6lIyQFsQRvy3s697N1t6yio5MQyPkxYiNkNABMc2Xn Um16j5JM vPKk3Bp/IeWW43Ua95yV8uoZ/un7PsA6SX62UpDCf837/cUt7cQVbUj444n5KT+1hQQX8HBMbKQjxcqmGfUmrkOgmyXuqEsKeDZIy7oDxb57MWHMGBtaZ3chPTR+n9FkQ4GWzZQdWTtJjnWcTNgAcG4hkcWegZzw+/+CIvNYNAh8p7X67x/uGpfe+0GXlxlylsofGdBTHS804MPK5POw/kkD7VIMwbwNRSGRKzmG6bFT+AacfP5PxZ8kZiCKgtMhhaT5cBANTBjeJ98V6H5rTSaxttkUXIhhOktzKZv09+ghuLL+PGFPlVfSf3suHuOd2JFvcfisoQ9eHObdjyHQP14uO81Bmhfn9kroooYtPaeQW8vPtYiuCOf+inZb2ESauxAzrmfecPycr43EPh5yn10iesh55H49mH21RW7QJXTlo/ge5dqhduzXaSpuMm4EXQCNfuDjOmZ46gm9MZDSacDhky4VFkMmmndOdLbBQDLPWRepm4IbvVG9rqwk9l5FV+i3+ZGZCHdad6yOhpBreIsNuLbjNFnD8W86dXN/OpNSFsUl8loHTLYGi/Brd0Y2sYea6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Dec 6, 2023 at 9:22=E2=80=AFAM Ondrej Mosnacek wrote: > > (Restoring part of the Cc list to include more relevant lists & > people... If you are lost, the original email is here: > https://lore.kernel.org/selinux/20230728050043.59880-4-wangkefeng.wang@hu= awei.com/) > > On Tue, Aug 1, 2023 at 1:08=E2=80=AFAM Paul Moore w= rote: > > On Mon, Jul 31, 2023 at 4:02=E2=80=AFPM Stephen Smalley > > wrote: > > > On Mon, Jul 31, 2023 at 12:19=E2=80=AFPM Paul Moore wrote: > > > > > > > > On Mon, Jul 31, 2023 at 10:26=E2=80=AFAM Stephen Smalley > > > > wrote: > > > > > I believe this patch yields a semantic change in the SELinux exec= heap > > > > > permission check. That said, I think the change is for the better= . > > > > > > > > Agreed. I'm also in favor of using a helper which is maintained by > > > > the VM folks over open coded logic in the SELinux code. > > > > > > Yes, only caveat is in theory it could trigger new execheap denials > > > under existing policies. > > > Trying to construct an example based on the > > > selinux-testsuite/tests/mmap/mprot_heap.c example but coming up empty > > > so far on something that both works and yields different results > > > before and after this patch. > > > > My gut feeling is that this will not be an issue, but I could very > > well be wrong. If it becomes a significant issue we can revert the > > SELinux portion of the patch. > > > > Of course, if you have any luck demonstrating this with reasonable > > code, that would be good input too. > > So, it turns out this does affect actual code. Thus far, we know about > gcl [1] and wine [2]. The gcl case is easy to reproduce (just install > gcl on Fedora and run gcl without arguments), so I was able to dig a > bit deeper. > > gcl has the following relevant memory mappings as captured by gdb: > Start Addr End Addr Size Offset Perms objfile > 0x413000 0xf75000 0xb62000 0x3fa000 rw-p > /usr/lib/gcl-2.6.14/unixport/saved_ansi_gcl > 0xf75000 0xf79000 0x4000 0x0 rwxp [heap] > > It tries to call mprotect(0x883000, 7282688, > PROT_READ|PROT_WRITE|PROT_EXEC), i.e. it tries to make the region > 0x883000 - 0xf75000 executable. Before this patch it was allowed, > whereas now it triggers an execheap SELinux denial. But this seems > wrong - the affected region is merely adjacent to the [heap] region, > it does not actually overlap with it. So even if we accept that the > correct semantics is to catch any region that overlaps with the heap > (before only subregions of the heap were subject to the execheap > check), this corner case doesn't seem to be handled correctly by the > new check (and the same bug seems to have been in fs/proc/task_mmu.c > before commit 11250fd12eb8 ("mm: factor out VMA stack and heap > checks")). > > I didn't analyze the wine case ([2]), but it may be the same situation. > > Unless I'm mistaken, those <=3D & >=3D in should in fact be just < & >. > And the expression in vma_is_initial_stack() is also suspicious (but > I'm not going to make any assumption on what is the intended semantics > there...) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D2252391 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=3D2247299 Thanks Ondrej. I'm hoping the mm folks will comment on this as it looks like this is an issue with the helper functions, but just in case I'm going to prep a revert for just the SELinux changes. If we don't hear anything in the next couple of days I'll send the revert up to Linus with the idea that we can eventually shift back to the helpers when this is sorted. --=20 paul-moore.com