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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C944C4363A for ; Thu, 29 Oct 2020 13:59:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CEBC2076A for ; Thu, 29 Oct 2020 13:59:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727735AbgJ2N4T (ORCPT ); Thu, 29 Oct 2020 09:56:19 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:38314 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727524AbgJ2N4S (ORCPT ); Thu, 29 Oct 2020 09:56:18 -0400 Date: Thu, 29 Oct 2020 09:56:17 -0400 From: Rich Felker To: Sargun Dhillon Cc: Kees Cook , Camille Mougey , lkml , Jann Horn , Tycho Andersen , Christian Brauner , "Michael Kerrisk (man-pages)" , Denis Efremov , Andy Lutomirski Subject: Re: [seccomp] Request for a "enable on execve" mode for Seccomp filters Message-ID: <20201029135614.GM534@brightrain.aerifal.cx> References: <202010281503.3D1FCFE0@keescook> <20201029075841.GB29881@ircssh-2.c.rugged-nimbus-611.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201029075841.GB29881@ircssh-2.c.rugged-nimbus-611.internal> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 29, 2020 at 07:58:42AM +0000, Sargun Dhillon wrote: > A mechanism for the thing listening on the listener FD to turn itself on or off > and indicate that it is no longer interested in receiving notifications and to > always continue / return an error code, or that it has taken an interest now, > and it would like to return to handling these events. The idea of an action > other than ENOSYS (specifically SECCOMP_USER_NOTIF_FLAG_CONTINUE) if the > listener goes away is attractive as well, in case the supervisor crashes. EPERM > is somewhat "cleaner" of an error code than ENOSYS (most people don't write > handling for ENOSYS on connect). This is a common misconception that really needs to be addressed. EPERM is not a suitable error code for as-yet-unknown seccomp-blocked syscalls, and is not suitable for a large portion of currently known ones either. It use has actively broken lots of things that would have worked fine with ENOSYS returned. This is because a caller will react to ENOSYS by attempting to do whatever it wanted to do in another way, one which your policy might handlle better (for example, if your filter is outdated and blocking clock_gettime64 but not clock_gettime, or blocking statx but not stat64) while it will react to EPERM as an indication that your filter understands the abstract operation it was trying to perform and considers that action forbidden. We hit issues like this with virtually every seccomp-using application while moving to time64 because the wrong idiom is so widespread, and further vdso prevented it from being caught right away (only users without vdso hit it later). >From a standards perspective (and thus of programming to them), POSIX does permit implementations to define additional errors for any interface that already has errors defined, but does not permit overloading the standard errors defined, so if EPERM is already defined for an interface, returning it is probably not ok. (IMO it is defensible if the seccomp policy can be thought of as an extension of the permission model that would cause the standaed EPERM, but it's not defensible if the policy is just "we don't know about this syscall yet" since the syscall might just be a new/better way of implementing some existing operation that makes the policy appear inconsistent.) In your example of connect, I think either is semantically defensible; one is "you lack suitable privilege to perform the operation" and the other is "you're running on a type of system that doesn't have socket connect functionality" (because it's a minimal execution environment). Rich