From patchwork Sat Jan 13 12:15:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fedor Pchelkin X-Patchwork-Id: 19007 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp729675dyc; Sat, 13 Jan 2024 04:17:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IEKbM6/M4LFi+5wPj3VGk+OV/4EoPkE6gNBHr9Hhb3wX7pAQxHnLiKtOAPoM+w4DLl+rpSA X-Received: by 2002:a05:600c:13d3:b0:40e:51f6:b825 with SMTP id e19-20020a05600c13d300b0040e51f6b825mr1004215wmg.224.1705148232951; Sat, 13 Jan 2024 04:17:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705148232; cv=none; d=google.com; s=arc-20160816; b=RKAAVF7lSIvnrgXuKqKJB+Ck3JR7ncBgcGL8/tP1+N/Cb+7bhRFUkMUgqRpV6TVcma HnrxuVeEWeZUOSaLxKQPrQoglTwHybHGZh6nNvvQoCUI6SSj66c8wUyqCTAXP0LKOq13 cBjhShi509bcn1H4hDzpIuAvO13T3w5ZB/Y4zYYRysu8+jWGqDTCeuMxg0krvmDBNWlx QhENG66YF/8vpGapNbAV3kVp1S6Xu9JeKzh6rWcWB6YD7tDWUnmqjth/tCamNGQXie/o S9vXWyovPUa9QXdQWB5ylEcDElnqYe1MtrNuNZqlZRLxlz0w4966DzzvpvOkDQQty9rg lwug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature:dkim-filter; bh=pztDEiVv/JTrPlxIE4dKwnm5K1/LAKTBaRFR2rt1P68=; fh=Rd6HdvXkAQOeO9wzvJ4xPYhZ10H20VMbGiok+pAFBP0=; b=sFrxSiscQessSQ7LbgRXRBqzprtz2Om/0xwb60/ujVFeaJVuHi/s0jBWW31p7HuZzN ZiSBCon3SzMy0qNtV2l360VD0omtG4EiSJI/VkWsRIYez4f4RlW9BT4jG7ASUymkD/Ar J8b/SgsJMLhiO6KAEXk4z3irO0qcIBDnsqnFNfHa74kHpzGNm0kK8fH7juQEevrMMLDg ur2auut6ZsOV68lJYSVDDupplVE3GrK8Njhz9hcgT0qaM7LZWNMw1V36M1SvNtk0Cst1 Juyi6GgZTsTDVBxbv3JQK+5S+ZPArb27vBcK0+z8LZ+f3f3JS8kDYHTEMJm+yFg4KZzI T5XA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ispras.ru header.s=default header.b=PD2gf3WV; spf=pass (google.com: domain of linux-kernel+bounces-25281-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25281-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id s22-20020a05640217d600b0055337154dfbsi2262156edy.437.2024.01.13.04.17.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jan 2024 04:17:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25281-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@ispras.ru header.s=default header.b=PD2gf3WV; spf=pass (google.com: domain of linux-kernel+bounces-25281-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25281-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 6E7AD1F22D74 for ; Sat, 13 Jan 2024 12:17:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1C9452137A; Sat, 13 Jan 2024 12:16:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ispras.ru header.i=@ispras.ru header.b="PD2gf3WV" Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7698A210EA; Sat, 13 Jan 2024 12:16:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ispras.ru Received: from localhost.ispras.ru (unknown [10.10.165.8]) by mail.ispras.ru (Postfix) with ESMTPSA id 3F10640F1DE8; Sat, 13 Jan 2024 12:16:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 3F10640F1DE8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1705148170; bh=pztDEiVv/JTrPlxIE4dKwnm5K1/LAKTBaRFR2rt1P68=; h=From:To:Cc:Subject:Date:From; b=PD2gf3WVCf/07T/Z491LAw57ctIf56C9+WM0RlTGAYEnWpvdlI52uNZdowMqYpF+n Ap2+RNSpVAs3c5VW816FiB55bbq/rB9psKG6oAzQBiXb/3E20pPBlBUmCwe8DozDdq yzTDNvkIfUI57Sf9QtSFykO6VuMlUmFhJ7JhSjG0= From: Fedor Pchelkin To: John Johansen Cc: Fedor Pchelkin , Paul Moore , James Morris , "Serge E. Hallyn" , apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Alexey Khoroshilov , lvc-project@linuxtesting.org Subject: [PATCH 0/2] apparmor: fix namespace check in serialized stream headers from the same policy load Date: Sat, 13 Jan 2024 15:15:50 +0300 Message-ID: <20240113121556.12948-1-pchelkin@ispras.ru> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787977513581801099 X-GMAIL-MSGID: 1787977513581801099 This series is intended to fix the supposedly invalid behaviour of verify_header() function when checking unpacked profiles namespace declarations. Consider having a profiles file called 'testfile' with contents as profile :ns1:profile1 ... {} profile :ns2:profile2 ... {} then packing it in a binary format and trying a load-replace operation $ apparmor_parser -Q -W -T testfile $ apparmor_parser -r -B /var/cache/apparmor/ac27e0ee.0/testfile Per dmesg output this leads the profiles to be loaded into the same namespace (trimmed for more convenient display): [ 414.616098] audit: apparmor="STATUS" operation="profile_load" name="profile1" comm="apparmor_parser" ns="ns2" [ 414.619304] audit: apparmor="STATUS" operation="profile_load" name="profile2" comm="apparmor_parser" ns="ns2" while the string "ns1" unpacked inside verify_header() is leaked: unreferenced object 0xffff888012ff9b18 (size 8): comm "apparmor_parser", pid 1198, jiffies 4295081077 (age 164.892s) hex dump (first 8 bytes): 6e 73 31 00 80 88 ff ff ns1..... backtrace: [] __kmem_cache_alloc_node+0x1e2/0x2d0 [] __kmalloc_node_track_caller+0x54/0x170 [] kstrdup+0x3c/0x70 [] aa_unpack+0xb5f/0x1540 [] aa_replace_profiles+0x1f6/0x4040 [] policy_update+0x238/0x350 [] profile_replace+0x20e/0x2a0 [] vfs_write+0x2af/0xe00 [] ksys_write+0x126/0x250 [] do_syscall_64+0x46/0xf0 [] entry_SYSCALL_64_after_hwframe+0x6e/0x76 With the following patches this situation is detected and the whole profiles load set is denied because of the mixed namespaces. Note that the following multiple profiles load will also fail after these patches - quite similar to the namespace check inside aa_replace_profiles(). profile profile1 ... {} profile :ns:profile2 ... {} This behaviour may directly affect userspace part of AppArmor, though I've not been able to find any valid use case when e.g. the user writes profile profile1 ... {} profile :ns:profile2 ... {} and expects `profile1` to be associated with `ns`. I think it's actually an invalid expectation so such profiles set should be also denied with a 'mixed namespaces' explaining message. There is no difference in AppArmor regression tests with and without the changes.