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 D98D4C4167B for ; Wed, 6 Dec 2023 14:22:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7842E6B007D; Wed, 6 Dec 2023 09:22:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7343F6B007E; Wed, 6 Dec 2023 09:22:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FCEF6B0080; Wed, 6 Dec 2023 09:22:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 503DA6B007D for ; Wed, 6 Dec 2023 09:22:24 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 12F4BC0251 for ; Wed, 6 Dec 2023 14:22:24 +0000 (UTC) X-FDA: 81536608608.23.196BBE8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id E995F1C0019 for ; Wed, 6 Dec 2023 14:22:20 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YlUNG9h9; spf=pass (imf18.hostedemail.com: domain of omosnace@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=omosnace@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701872541; 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=MLB0xakptmZK/paEeR6NK/S0tuH0grZlEHMYROWR5jg=; b=BshnXk3NTNj88cIP02CL2yGFeVPPd7A5aTG319OWlhJKU4sj2mc5ktmOoQXrnyipEgxlj6 kf7tpcuUdNvJ5bzlmkevv6zhUKHDdIs9/ys8gMZAUICJt9DrhOKHJpkJranfK0eET7FoiA KphxzFTv+/8Z+5KDlZCC4YeC0795qVQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701872541; a=rsa-sha256; cv=none; b=sdL32FZM9/JaMTbWNSNdkeMn0SM0VwB51NN0K3wWw3ay6YAXPtnUJTYOqm2V5mu9wT7ooM 4pbt5La/NXdlDIp0rnBVDPrPZ4uLen+fYYRv08LDrGrNI34J+bjF7DxdpRyDMXcqR1dscO /SdIl4ByYqK4o+oLz7nNxfRdA+DAmUA= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YlUNG9h9; spf=pass (imf18.hostedemail.com: domain of omosnace@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=omosnace@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701872540; 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=MLB0xakptmZK/paEeR6NK/S0tuH0grZlEHMYROWR5jg=; b=YlUNG9h9kGk6pogeVSCdV5GK1P/yN3qxrOn716bF3GjKSZW5pDbzEtg6c/1K84uPOYtuV5 KLez/HLXjcDyO3nIo43b2QxuB+q0ZzVq9/FQqIm0M8wnOSu4Ajez95frB2kKSakMCalWks qL6FnSVoIHNWtXTwK5nwTwDqiCLHtOU= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-645-j_NyluDbMUW2gdVsEBBVdw-1; Wed, 06 Dec 2023 09:22:18 -0500 X-MC-Unique: j_NyluDbMUW2gdVsEBBVdw-1 Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-286da86884aso2185192a91.2 for ; Wed, 06 Dec 2023 06:22:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701872537; x=1702477337; 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=MLB0xakptmZK/paEeR6NK/S0tuH0grZlEHMYROWR5jg=; b=YDCvDm+2Md5gqk/v+XhwZ6+h9iaE5IRSBZ+6T4Inkq5eVGeMmQW1liooX37gv3EDA3 jVN0KL7pfCmkSRIRiYvMn0uDt5fdXs/P42+p0KPvBWDCTZqGnocTNrBzbQe6RL6RqNiX kjNUNR5q8RjDOqt3LRL074fpPqlRA45iGvs6GJ3/d3/vlq45i6Va687CeRPacGenRDn/ yMbVAHwiIg6kPWs4BVAawVbpnAynBFS09/B00oP9kLweqibF5nd+MgHNxRM+Mh2NHWND PYDgRMXTsy4F2V2KNrJlRJcCw6+nU2G4mbD4lAYbIiQC96Wu0nsfCAxskIuB0QWhvX2N BOww== X-Gm-Message-State: AOJu0Yzxa8Hc2yPLQr6iEPmc5UyqH5Bq1ADLBlVqQvRIoR52AWEptZR0 xWqbQIJUInQWXH76tG6fBe5aRk6dhNReQInmYGyxziON8FPS6Mhi/LAKGrNLuhkRto47zMhkwrm C/a3fmIBmq1vzezAwDwMv5zOy2O8= X-Received: by 2002:a17:90b:3d86:b0:286:6cc1:781d with SMTP id pq6-20020a17090b3d8600b002866cc1781dmr860866pjb.96.1701872537754; Wed, 06 Dec 2023 06:22:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IHKKfSjsOWVtPWTod+zg2CvvPowf53VSChdD7/z222jTPryWrvyHr1oecWgSe35Jxv4C03V1qXtJKXvufCz8Ks= X-Received: by 2002:a17:90b:3d86:b0:286:6cc1:781d with SMTP id pq6-20020a17090b3d8600b002866cc1781dmr860850pjb.96.1701872537481; Wed, 06 Dec 2023 06:22:17 -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: Ondrej Mosnacek Date: Wed, 6 Dec 2023 15:22:06 +0100 Message-ID: Subject: Re: [PATCH v3 3/4] selinux: use vma_is_initial_stack() and vma_is_initial_heap() To: Paul Moore Cc: Stephen Smalley , SElinux list , "open list:MEMORY MANAGEMENT" , Kefeng Wang , David Hildenbrand , peterz@infradead.org, Andrew Morton X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 8oi85npahjpsbpuj4fn8ssb1b75kukfk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E995F1C0019 X-Rspam-User: X-HE-Tag: 1701872540-438049 X-HE-Meta: U2FsdGVkX1+XhrVy9baxTx1gz27XfvGfPm9C7Do9nZN1kyfxWWan3+6i+6cqEmmdSVZgymrSdvJN43Rsg21BTnJMYf9Krzpsd2xXdoir1yI9OROfGPyl3fFvhcrrPm7PEN/RIy/G+wtsXIBPNbjowstbsDMfIY8IQx40FD0C4bdFoDoRl/5hAm7M/VzoZ21ZIDHmhhHeOyYAHZhyZyPASkVO0e7sz0mxa74JJsyZBBEc/A7jK2lSxR0zA5+VcJxz7MVGexkZEqnqiPF70n61xFatplb8iIRq3U7TmdKw5UevpdXWGZRBY+Y6EEABaz85KFy5wMHARRCCRQqfZfQMetfbbNRnaHFPFw5O9viUgABFv8xBvuLuFBf3dTs6cKFaX2vBJkOmtiViLTwS8Ux51LeneMvSObR9ut8ed/l5g3NPwHoq8TWJgOOafwQSxh/RPqinaY8hmzWKz55JW0D0lVGn/zrmkMzRXGjRvJ2SFl2EUMU/bYGm1ulmZRnJNBxDTUOS9hIN/7QunjPhEVugYtSfjxiY2+VOLlWh9n/Ae0LeQbiaJFlIUTvRO2MkWd93pQsMeNX1+reve0t9aADvpmXa95mdqUitESzKGP33fxJJcoFBlhCSMNffJecyxw39lovJEU+1A3EQTRRYWF+bWPzJ+pH61/NCfHvntXeee2LZXbnDsDB5+HTetIRPVLBPuI0vX/OdloCbvBSiKyTjN1WtQrJVlJRpKsGzQwnc+jCyJ/S7mbFybFMTXaYmoz9XJ/0UZm1cFzZKt0SiiShmo7q+/Veoh9iL0VgYXWpOzFCinnrT4AlYTa8NFUc6G14ipw3kzUMigjT3/58noih3eYxhCD+kjz0qgQlab9fR1e6N1u6CVX6msEv2FihCTHKN7P0YxiX9g2UgwCSC2dqBVAkfDORgGfGkxn+QjKbUjvyGEc/M5kP72vMp/go9pJcWExZ8b7x88vP8zwdc5zL GACUpIHl bWwW9cNSuA9YgLrMUQAdPNa6qeTvzFxb5RrfDgfkyr/LiLKQZYDsSJUlh/AhP3rKkYZ+63Lcfw76jvajqzx8AeL8eamR1MKGKxa/JU8vcigFV5QuL3k+AeMesTy5Dx1RBXT4ljBEpvLJ8c3Z7kXawdKdGE7GKgo0kU+lMYEOJDEU5UFcrr9FNPckL6KILLj7A2ivaADQHR8IhmcJQ6ZXrFx0gYn9lKEWAZ85M4QBrA2S9RPPzDkrfYigZ+YjtZPU9qCP/F2FE5ipD9/zTw4RSlgwbst7kt2/XTz3HohIcaTxRBshJOqSHEIdG7PCY5ZOceoD3LVao7tG8CR+mpmidsQCPXv3DIYdJ6uAY/Cbbg+bjN0saFO9jC3aXjk7iqkc4OjyWTOVk+dQsS8yu004bs76JBA1n3mveaTSuXNydcbUGcaZ3j3kThNxwsfIt+3MFUxT1fnbQmUxmo9yFORQnhmj1Yl0/m0HIcBa8KZV4o5hBUUPhFfRfHxRM9m4IFjpQkRLNUtg8iVLdzc+W6aMokSS5O8SI8p3YZEt3DLniWWkIx9sM646dG3l0OoKj99+7p9gg 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: (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@huaw= ei.com/) On Tue, Aug 1, 2023 at 1:08=E2=80=AFAM Paul Moore wro= te: > > 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 exeche= ap > > > > 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 -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.