Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2276557ybk; Mon, 11 May 2020 17:01:33 -0700 (PDT) X-Google-Smtp-Source: APiQypIsocvtpVVPTeiC3KXRzhEzP4Psy3KinLno/+LrgYIFVQR+XZLR3voIkOVzSbQxJS0kNE0G X-Received: by 2002:a05:6402:684:: with SMTP id f4mr16230583edy.240.1589241693583; Mon, 11 May 2020 17:01:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589241693; cv=none; d=google.com; s=arc-20160816; b=sW7tOHFZMqM78FS/RF+4NfJ1iLG+oZQMeWB/OdwKJs5OZKyBk2H+zL/yjQbrG3jBWH vlWEONLPE9BVL0zPymrFLvRTxW/jIoKN3ySCrln8X5TimbKIwxULBeYHCrJKCXazP8As tDw2Lf0xQ9l9+M8/h3YrlAxonDZgtsPtLe6boeJKgaZD1VoOJrQiaMNpyY2sKiFWm6A+ sLlDfx01jIYfyyC1wapITehr3X2rJFaKIAu8EwlKCMHthRXuHMEB/0j/kISG57Y/mA+c i2ea8o6e2XDXCqqagQVMuPAPhuPVONfrBWUcD3SPaBN1KJaZWX4yK/FcDTIZWHCF+2AC 5vog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=su7IZNhrlE7HNdooJKGpydIdN6GK+u6wNKS/k/H3gwU=; b=RxRcE42s8g47qkyDflAFUOwXg3Vp/RMMbK8F2hT9cHmhWAzzsXwz/dc386hBe+CKQZ f/CP0ygkB89988Jdwj9S1Y2oKawiYer8TbG18XIkFeJMorSvud4OdwUOWZSZKFaUQbNm rM3TZBa7rOkt7gA1GA0NIYiLyfec8CXFd9rKy+B0jv9MMbvvGhnsFUuYWHCddDGVObtE QFCDi8X3ZNtQWIGVmkSxtzUgu6T0+LH7KqdoIWBmMbd6kN/sHB5imDrh6BgEwPpS8iwb NJfV8gfmTxFCzh/T6E9Tq/htc5grvqnu9pglqS1tRastBhChvWU4GTK2h+4j/9Z89IQr ykEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gV0GwK5c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si1979232edm.59.2020.05.11.17.01.11; Mon, 11 May 2020 17:01:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gV0GwK5c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728208AbgEKX72 (ORCPT + 99 others); Mon, 11 May 2020 19:59:28 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:28060 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725836AbgEKX71 (ORCPT ); Mon, 11 May 2020 19:59:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589241565; 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: in-reply-to:in-reply-to:references:references; bh=su7IZNhrlE7HNdooJKGpydIdN6GK+u6wNKS/k/H3gwU=; b=gV0GwK5cUb7WDE3saJPkEc7ym4otGNFxXbOroWcjUlHVgVibM/QgZAOvVNVaKMfyVZH0TJ UYkEiNXXmzxbMhkL8JScCXv7txb4OLFFBSrhue6cEUITXJuPT1+zaX9iO+mjtEPfIA1CV6 nWv1KledZg0AmOzjwADt0LWejIFEt1Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-304-5uBBaGbQOweF80mZGFTuOA-1; Mon, 11 May 2020 19:59:21 -0400 X-MC-Unique: 5uBBaGbQOweF80mZGFTuOA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B203518A0724; Mon, 11 May 2020 23:59:19 +0000 (UTC) Received: from optiplex-lnx (unknown [10.3.128.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 974156444B; Mon, 11 May 2020 23:59:17 +0000 (UTC) Date: Mon, 11 May 2020 19:59:14 -0400 From: Rafael Aquini To: Luis Chamberlain Cc: Tso Ted , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, keescook@chromium.org, yzaikin@google.com Subject: Re: [PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes Message-ID: <20200511235914.GF367616@optiplex-lnx> References: <20200511215904.719257-1-aquini@redhat.com> <20200511231045.GV11244@42.do-not-panic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200511231045.GV11244@42.do-not-panic.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 11:10:45PM +0000, Luis Chamberlain wrote: > On Mon, May 11, 2020 at 05:59:04PM -0400, Rafael Aquini wrote: > > The sysctl knob allows any user with SYS_ADMIN capability to > > taint the kernel with any arbitrary value, but this might > > produce an invalid flags bitset being committed to tainted_mask. > > > > This patch introduces a simple way for proc_taint() to ignore > > any eventual invalid bit coming from the user input before > > committing those bits to the kernel tainted_mask, as well as > > it makes clear use of TAINT_USER flag to mark the kernel > > tainted by user everytime a taint value is written > > to the kernel.tainted sysctl. > > > > Signed-off-by: Rafael Aquini > > --- > > kernel/sysctl.c | 17 ++++++++++++++++- > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c > > index 8a176d8727a3..f0a4fb38ac62 100644 > > --- a/kernel/sysctl.c > > +++ b/kernel/sysctl.c > > @@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table *table, int write, > > return err; > > > > if (write) { > > + int i; > > + > > + /* > > + * Ignore user input that would make us committing > > + * arbitrary invalid TAINT flags in the loop below. > > + */ > > + tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1; > > This looks good but we don't pr_warn() of information lost on intention. > Are you thinking in sth like: + if (tmptaint > TAINT_FLAGS_MAX) { + tmptaint &= TAINT_FLAGS_MAX; + pr_warn("proc_taint: out-of-range invalid input ignored" + " tainted_mask adjusted to 0x%x\n", tmptaint); + } ? > > + > > /* > > * Poor man's atomic or. Not worth adding a primitive > > * to everyone's atomic.h for this > > */ > > - int i; > > for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) { > > if ((tmptaint >> i) & 1) > > add_taint(i, LOCKDEP_STILL_OK); > > } > > + > > + /* > > + * Users with SYS_ADMIN capability can include any arbitrary > > + * taint flag by writing to this interface. If that's the case, > > + * we also need to mark the kernel "tainted by user". > > + */ > > + add_taint(TAINT_USER, LOCKDEP_STILL_OK); > > I'm in favor of this however I'd like to hear from Ted on if it meets > the original intention. I would think he had a good reason not to add > it here. > Fair enough. The impression I got by reading Ted's original commit message is that the intent was to have TAINT_USER as the flag set via this interface, even though the code was allowing for any arbitrary value. I think it's OK to let the user fiddle with the flags, as it's been allowed since the introduction of this interface, but we need to reflect that fact in the tainting itself. Since TAINT_USER is not used anywhere, this change perfectly communicates that fact without the need for introducing yet another taint flag. Cheers! -- Rafael