From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id 986463854822 for ; Sat, 24 Oct 2020 11:34:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 986463854822 Received: by mail-lf1-x144.google.com with SMTP id 184so5352492lfd.6 for ; Sat, 24 Oct 2020 04:34:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IoKvQwjpmgnwDqwDMU0dzPR0LnLnshRSMNK/AI0kcxw=; b=dPn5LSnUJtXmyqL07wvu45pNBHkU6SBcFNLKIHl8hwfM1N1MRe1uYxe2jjBAZ585eP tp1upX8C+uR7DqpaPgH9kL8rdp7YI9c++M4m4MHI+ASJ6YTXL/7GfSAvp3bGJunMP9No f4YxyvUQpMOpBAZgDl+ngYzOTogmXglK5Tj6jopDrlvnSA9BEU2kTK9gdjnB89y4WfbH 96UnlHEpv/qZAqlCamtZ8qi6dwpWIdXHuYJSDMFU/AuXhs5ikDRo3e2i0/9AuvLj1Nf7 xkvRAbTX8nvGmeAlcJeFksfSKLVxLmSIdGYt3DTg+9mgsDWQ01MzBM2GdDwNgC3jvr2l L2zQ== X-Gm-Message-State: AOAM532Pe0XYox4IEYmYJ4vOs2KtnNHzaFeKF7kJQ/wLrZtTF6dvqPSZ 0pMF0VL1pRQJJbl/LJKZ3sc= X-Google-Smtp-Source: ABdhPJzwvsaTluGQK36qa7V3CiVSFtEKeTqt9O3nz3uBAt8xGRnoa/SVo39MAjPgTAB/taz96NuywQ== X-Received: by 2002:a19:2355:: with SMTP id j82mr1914155lfj.36.1603539267465; Sat, 24 Oct 2020 04:34:27 -0700 (PDT) Received: from [192.168.1.112] (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id y24sm411089lfy.194.2020.10.24.04.34.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Oct 2020 04:34:26 -0700 (PDT) Subject: Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures To: Salvatore Mesoraca Cc: Kees Cook , Szabolcs Nagy , Jeremy Linton , "linux-arm-kernel@lists.infradead.org" , libc-alpha@sourceware.org, systemd-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Mark Rutland , Mark Brown , Dave Martin , Catalin Marinas , Will Deacon , Kernel Hardening , linux-hardening@vger.kernel.org References: <8584c14f-5c28-9d70-c054-7c78127d84ea@arm.com> <20201022075447.GO3819@arm.com> <78464155-f459-773f-d0ee-c5bdbeb39e5d@gmail.com> <202010221256.A4F95FD11@keescook> <180cd894-d42d-2bdb-093c-b5360b0ecb1e@gmail.com> From: Topi Miettinen Message-ID: <3cb894d4-049f-aa25-4450-d1df36a1b92e@gmail.com> Date: Sat, 24 Oct 2020 14:34:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 11:34:30 -0000 On 23.10.2020 20.52, Salvatore Mesoraca wrote: > Hi, > > On Thu, 22 Oct 2020 at 23:24, Topi Miettinen wrote: >> SARA looks interesting. What is missing is a prctl() to enable all W^X >> protections irrevocably for the current process, then systemd could >> enable it for services with MemoryDenyWriteExecute=yes. > > SARA actually has a procattr[0] interface to do just that. > There is also a library[1] to help using it. That means that /proc has to be available and writable at that point, so setting up procattrs has to be done before mount namespaces are set up. In general, it would be nice for sandboxing facilities in kernel if there would be a way to start enforcing restrictions only at next execve(), like setexeccon() for SELinux and aa_change_onexec() for AppArmor. Otherwise the exact order of setting up various sandboxing options can be very tricky to arrange correctly, since each option may have a subtle effect to the sandboxing features enabled later. In case of SARA, the operations done between shuffling the mount namespace and before execve() shouldn't be affected so it isn't important. Even if it did (a new sandboxing feature in the future would need trampolines or JIT code generation), maybe the procattr file could be opened early but it could be written closer to execve(). -Topi