From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE09A646 for ; Sat, 21 Dec 2024 11:06:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734779200; cv=none; b=te1NokeZqvf7DC53yRJb72CTgXRmbSsJiy3FEPkHA/Fho0NtADxWjS6AyUi7H+8/vGhTdKo6Zi9YtQ+yAFCfcWP57L3wUdOYcP3XTRZIGW4EJP/Phq7PRt4qE1tm18qBLtOGK0g2KjzLhZ0HhIZtcVP2+8LIugalFVqMSfOJJLQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734779200; c=relaxed/simple; bh=HKrvtGIaAK3Jab0O+wQO5OrK+dBoeEExyYJNxAwz//M=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=oqyMMOJ02oX4bEVSRdeXPYGU5o1uyM8Ur1UuA5Svt+c3AY03w8zJsL6C7X6a8OEA8xkSYqJNN5EhZ1bWbl7rjiWBXY2kAiBXgLJ/duRg85tqM4RNuw37rQ5NxLp4PwWnOWpDWShSde5BUhQ8kJBS/ZBL78rD/oF/QSD8EpCyI6k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iBFoJJ84; arc=none smtp.client-ip=209.85.218.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iBFoJJ84" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-aa6732a1af5so283811066b.3 for ; Sat, 21 Dec 2024 03:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734779197; x=1735383997; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=9c9a3iVDE+5v7pmjMQqm1QHn7yy3OkjMxC3jrRl0psE=; b=iBFoJJ84n5IQypwq8a/T71FT6GZVYCc9/8mCJxdbLwJPQe6qv3oRACTg+TLLnb1u1W TjD3URVnBjlrYwM3xSQ3oOLFIz4mY+DLv/h2KSQthbm4vwTQDGQNo8CkpDKI6TsDqEX3 G6tEplwCceNHi0VRx9NKkuM0d1TwvWcSrjbvdBiHxcsIqztdfu2uYGM0Ta43CWVQmcAI o3IFnSyn7h997ycaiIsxRHecnGRskJk351yaqR0tqhTfTAYj4O0ewW/eX/rKsCXZUQne uIF/WRDXHFUv3o7UcUREJ26aPRF85Gvxl4DAzPS5W+5/2STi/cE0WSCUsAWIVs777T+y HH5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734779197; x=1735383997; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=9c9a3iVDE+5v7pmjMQqm1QHn7yy3OkjMxC3jrRl0psE=; b=qPff2ZVWMMHq+BqGAo0e2/oPnHk24KEDSJER5chB2wK9JNR9EFrFlEUs2neLWYSYz5 iilQTNy4myXUNg5nw/mSX0cQDa/qPfVfvPf2jeHAxrB4LDfk+FHN4V6Ma6wK3BTuItnN wKkJb3Nl/oMmVV5k4RnEYRrsekW7gLokEYhWiPd1/JCUmxehnyFT6OCy5+g1OLzEAv0Y uLu6pmaV0fAk7KA/D5lsqpxMirXFkVBTEP2BTCafd3w6HvYfkBIsjHKEYnyTNJ0CoP61 ib5vDmW2COISDpMlJx88R7XxD6eQnNo59WAIh47ydY2cPMsNH1wciiA3RCPUNTjAwV3O YT2Q== X-Forwarded-Encrypted: i=1; AJvYcCWPKlwgePXYMA/Bmn13dxKkNQSIeO+8WXYrfZ88cyPiorJ4eH/2/kCeHjwMaBM79qSOAYss0t2NIOTBEkg=@vger.kernel.org X-Gm-Message-State: AOJu0YyQKUu7QEfk4ljp+aRUSxIRuHbuUt/OaWbl2fY1hZP7hEBaqsaL /HsQH3XFSgbVoyo8HtkdHtchqjB2NL8Z2mRmcM130SDyjr5N7DA8OrPE9G8gSh41G33Lz/V2KNC zkA== X-Google-Smtp-Source: AGHT+IEToD+6DqkOSrJAGdf3lwcpFc2nJisfO7vLafkdBubYriBDAdyrh0akWL0n3H+qY6NTTVgq7uQb4Ik= X-Received: from ejcvw10.prod.google.com ([2002:a17:907:a70a:b0:aa6:9dde:9b22]) (user=gnoack job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:2dab:b0:aa6:aa8e:c89c with SMTP id a640c23a62f3a-aac335626acmr489665766b.39.1734779197235; Sat, 21 Dec 2024 03:06:37 -0800 (PST) Date: Sat, 21 Dec 2024 12:06:35 +0100 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <2024121418-blazer-valiant-c51a@gregkh> <20241216150722.4079213-2-gnoack@google.com> <2024121653-unblessed-mummified-c630@gregkh> Message-ID: Subject: Re: [PATCH] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN From: "=?utf-8?Q?G=C3=BCnther?= Noack" To: Greg Kroah-Hartman Cc: Jann Horn , "Hanno =?utf-8?B?QsO2Y2s=?=" , Jiri Slaby , linux-hardening@vger.kernel.org, regressions@lists.linux.dev, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Greg, Hanno and everyone else! On Mon, Dec 16, 2024 at 04:42:50PM +0100, G=C3=BCnther Noack wrote: > On Mon, Dec 16, 2024 at 04:17:15PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Dec 16, 2024 at 03:07:23PM +0000, G=C3=BCnther Noack wrote: > > > With this, processes without CAP_SYS_ADMIN are able to use TIOCLINUX = with > > > subcode TIOCL_SETSEL, in the selection modes TIOCL_SETPOINTER, > > > TIOCL_SELCLEAR and TIOCL_SELMOUSEREPORT. > > >=20 > > > TIOCL_SETSEL was previously changed to require CAP_SYS_ADMIN, as this= IOCTL > > > let callers change the selection buffer and could be used to simulate > > > keypresses. These three TIOCL_SETSEL selection modes, however, are s= afe to > > > use, as they do not modify the selection buffer. > > >=20 > > > This fixes a mouse support regression that affected Emacs (invisible = mouse > > > cursor). > > >=20 > > > Link: https://lore.kernel.org/r/ee3ec63269b43b34e1c90dd8c9743bf8@find= er.org > > > Fixes: 8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-pas= te subcommands") > > > Signed-off-by: G=C3=BCnther Noack > > > --- > > > drivers/tty/vt/selection.c | 14 ++++++++++++++ > > > drivers/tty/vt/vt.c | 3 +-- > > > 2 files changed, 15 insertions(+), 2 deletions(-) > > >=20 > > > diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c > > > index 564341f1a74f..0bd6544e30a6 100644 > > > --- a/drivers/tty/vt/selection.c > > > +++ b/drivers/tty/vt/selection.c > > > @@ -192,6 +192,20 @@ int set_selection_user(const struct tiocl_select= ion __user *sel, > > > if (copy_from_user(&v, sel, sizeof(*sel))) > > > return -EFAULT; > > > =20 > > > + /* > > > + * TIOCL_SELCLEAR, TIOCL_SELPOINTER and TIOCL_SELMOUSEREPORT are OK= to > > > + * use without CAP_SYS_ADMIN as they do not modify the selection. > > > + */ > > > + switch (v.sel_mode) { > > > + case TIOCL_SELCLEAR: > > > + case TIOCL_SELPOINTER: > > > + case TIOCL_SELMOUSEREPORT: > > > + break; > > > + default: > > > + if (!capable(CAP_SYS_ADMIN)) > > > + return -EPERM; > > > + } > >=20 > > Shouldn't you check this _before_ doing the copy_from_user() to emulate > > the previous logic properly? >=20 > You are right, I believe this can technically return a different error co= de. >=20 > There is a data dependency between the two though - the capability check = should > only happen for certain values of v.sel_mode, and v is only populated by > copy_from_user(). >=20 > As far as I can tell, this only makes a difference in scenarios where bot= h > copy_from_user() and the capability check would fail. >=20 > Do you think we have to emulate it down to this level of detail? Another observation which makes it clearer that copy_from_user() failing he= re should really not happen in practice: The 'argp' pointer that gets passed to ioctl(2) here is a pointer to a regi= on in memory whose first byte is a TIOCLINUX subcommand, and at the time we do th= e copy_from_user(), this subcommand byte has already been successfully copied= over from user space. The region that we are now copying with copy_from_user() = here is directly after this byte, and should under normal circumstances work as = well -- I believe that callers would have to construct a specifically crafted io= ctl() so that the first copy-from-userspace works and the second one fails (refer= ring to a byte just before a page boundary, or something like that...?) I'll send a V2 of this patch with the comment removed, the 'Cc: stable' add= ed, but where the CAP_SYS_ADMIN check is still done after copy_from_user(), wit= h the reasoning that: 1. A previous get_user() from an adjacent memory region already worked (making this a very unlikely failure) 2. I do not see a good alternative to reorder the code here, because we ne= ed the data from copy_from_user() in order to know whether the CAP_SYS_ADM= IN check even needs to be performed. Hanno: If you are OK with this patch, I'd still appreciate a more formal "Reviewed-By" or "Tested-By" from you. :) Thanks, and Happy Holidays! =E2=80=94G=C3=BCnther