Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3841654pxf; Mon, 22 Mar 2021 17:15:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyw7vfqiA0hKqHpxd4L/wyUL1aD4kv/hqg5A+p2cAvhs+wKs39fZmY8JoHBcWOKhF/fQBOc X-Received: by 2002:a17:906:2786:: with SMTP id j6mr2194624ejc.157.1616458546046; Mon, 22 Mar 2021 17:15:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616458546; cv=none; d=google.com; s=arc-20160816; b=HFFe11Jvz8jUnOb4NRUi32MxeA0hWegXHpgLw1HvTiEJoh2h046N+vRn3rWZL9TXX6 GbcA8Ss77fYAOT1vgpen9QTf8fcMBngMOC+IQWtVZ+hhSj1s+CFsTpFwgic+mP5NeMc6 vHt0chBkElcPCdoq2XRPqe7z0MX5YWbFOJEmXzBzGmWLCKiNMDpNZodYqcqr7Qxrgf6l TtpMqxhaba1MVCV36STbxubLZJo+LswEOmEkPCwbbFRhEM3sNeXT+W4+atiDrNYlCuOp bYN+AC65jHBJ3cuKtyQ8AEm/6B388VcN/SgXtDIMFncx9HN4FAI5G7sboIGhfxS/vKhl JNkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=TIGZs9jCzlV0x2/zD28u6hnF9ziSX82ipPw1eAlhUAk=; b=ZdH9me2BxHI2kbQyln+97ZDNVdwbhOYwOC9UWV7NrNV2ROHcgpHifxF/WDa7UYVDxp VC9wLD7tnDLM74i3ll1ndue6dFjXItc+Lz7XpvxM/c+U3hocs3alJjdNHA8pB4v3N9KQ lPO14eVpBdBt5t8GY1IyXvb7BEAgsRWgLVtxvKxrpER4fppvcSvL+sGGbKKm96ygInP2 J6JMH5UZIn1qmnQlpBCdUEwdszV3uKElic+wY+hj0FLof3EQrZ9HO5Kn0fleOUhaio7Q 4gdHF2ws+mJ7FSvIkqJA/m1yQQadFs6bp3wPGBdaV5UwBGYfOZIKZQrjeGnLn8tSlyCG +vbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NQ71vlDt; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk14si12044554edb.548.2021.03.22.17.15.23; Mon, 22 Mar 2021 17:15:46 -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=@google.com header.s=20161025 header.b=NQ71vlDt; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231289AbhCWAO2 (ORCPT + 99 others); Mon, 22 Mar 2021 20:14:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231327AbhCWAOF (ORCPT ); Mon, 22 Mar 2021 20:14:05 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41CA9C061762 for ; Mon, 22 Mar 2021 17:14:05 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id b14so10772859lfv.8 for ; Mon, 22 Mar 2021 17:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TIGZs9jCzlV0x2/zD28u6hnF9ziSX82ipPw1eAlhUAk=; b=NQ71vlDt19b2qIy3K62/rODvW/ipNZXPs54iaqoCcYgvr0ZoSYMPbU3vdVRzRslzc0 paD44AWGk2fGxml9DqHSXpWchMulVtSjoazoJQCHqMqDiZQv3PQGaTav7G+EZ+/Yz0Ph +I/b57JKRKullcMz8vVJcYd0UwSmrTSWA4CeJdZBKpdTGzNd97/MAdsFkXxVZPhb3k+4 9ZqfVflxIPxDAKr+2r/8JCbzty+q0w/uN+ytri4BJTYKvpQ7fCZjmce6o20eSEVn/bUJ Ik0/GtqeP0J9ZbJyd50mOg9CAXERLBgP8bORDoUzBiazlAWWJUCNW/Nya+XY3VMgqVqW H7xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TIGZs9jCzlV0x2/zD28u6hnF9ziSX82ipPw1eAlhUAk=; b=aNXQykeT+HUNfH9TuMhEZ7nVr1i+qkCPMabt5f41PvKpxAKfVnvNH8iJY4GYWL0wKt BxQSuClUSH11femZ2dHZM5RpeZziZrnfa2uGWrzBMnRKxocbEiTSoileq1m241x2oMwp UDRa0G/XVnm3sJ5al/WrIMXBtOO2N6XoOlDfBwCUyKNwKakSLo/d8zxT7k5eZKdn7AWJ nXRTnl6z8867URZ9L99CMCwUT/pB5xjqCtlbRvpswDwzwispkKNgXYoKBz0/Z+scUCsw Mh0xs+0M1YlOZZIy1KL7300Fw7Wyc1tSNlLHCH4f4D5b9UVZANFhd5QwTnfh7wxDIvOT WKSQ== X-Gm-Message-State: AOAM533W/3boX0CqV79hRxI0jgwdf8mPSuKbYEBDDGnj1qG6CQvIRDoE XPPahHGIEv1qyOZXazEgKdoU1Me82w7X69Dz/6Q8kw== X-Received: by 2002:a19:946:: with SMTP id 67mr1116146lfj.74.1616458443362; Mon, 22 Mar 2021 17:14:03 -0700 (PDT) MIME-Version: 1.0 References: <20210316204252.427806-1-mic@digikod.net> <20210316204252.427806-8-mic@digikod.net> In-Reply-To: <20210316204252.427806-8-mic@digikod.net> From: Jann Horn Date: Tue, 23 Mar 2021 01:13:36 +0100 Message-ID: Subject: Re: [PATCH v30 07/12] landlock: Support filesystem access-control To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: James Morris , "Serge E . Hallyn" , Al Viro , Andrew Morton , Andy Lutomirski , Anton Ivanov , Arnd Bergmann , Casey Schaufler , David Howells , Jeff Dike , Jonathan Corbet , Kees Cook , Michael Kerrisk , Richard Weinberger , Shuah Khan , Vincent Dagonneau , Kernel Hardening , Linux API , linux-arch , "open list:DOCUMENTATION" , linux-fsdevel , kernel list , "open list:KERNEL SELFTEST FRAMEWORK" , linux-security-module , "the arch/x86 maintainers" , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2021 at 9:43 PM Micka=C3=ABl Sala=C3=BCn = wrote: > Using Landlock objects and ruleset, it is possible to tag inodes > according to a process's domain. [...] > +static void release_inode(struct landlock_object *const object) > + __releases(object->lock) > +{ > + struct inode *const inode =3D object->underobj; > + struct super_block *sb; > + > + if (!inode) { > + spin_unlock(&object->lock); > + return; > + } > + > + /* > + * Protects against concurrent use by hook_sb_delete() of the ref= erence > + * to the underlying inode. > + */ > + object->underobj =3D NULL; > + /* > + * Makes sure that if the filesystem is concurrently unmounted, > + * hook_sb_delete() will wait for us to finish iput(). > + */ > + sb =3D inode->i_sb; > + atomic_long_inc(&landlock_superblock(sb)->inode_refs); > + spin_unlock(&object->lock); > + /* > + * Because object->underobj was not NULL, hook_sb_delete() and > + * get_inode_object() guarantee that it is safe to reset > + * landlock_inode(inode)->object while it is not NULL. It is the= refore > + * not necessary to lock inode->i_lock. > + */ > + rcu_assign_pointer(landlock_inode(inode)->object, NULL); > + /* > + * Now, new rules can safely be tied to @inode with get_inode_obj= ect(). > + */ > + > + iput(inode); > + if (atomic_long_dec_and_test(&landlock_superblock(sb)->inode_refs= )) > + wake_up_var(&landlock_superblock(sb)->inode_refs); > +} [...] > +static struct landlock_object *get_inode_object(struct inode *const inod= e) > +{ > + struct landlock_object *object, *new_object; > + struct landlock_inode_security *inode_sec =3D landlock_inode(inod= e); > + > + rcu_read_lock(); > +retry: > + object =3D rcu_dereference(inode_sec->object); > + if (object) { > + if (likely(refcount_inc_not_zero(&object->usage))) { > + rcu_read_unlock(); > + return object; > + } > + /* > + * We are racing with release_inode(), the object is goin= g > + * away. Wait for release_inode(), then retry. > + */ > + spin_lock(&object->lock); > + spin_unlock(&object->lock); > + goto retry; > + } > + rcu_read_unlock(); > + > + /* > + * If there is no object tied to @inode, then create a new one (w= ithout > + * holding any locks). > + */ > + new_object =3D landlock_create_object(&landlock_fs_underops, inod= e); > + if (IS_ERR(new_object)) > + return new_object; > + > + /* Protects against concurrent get_inode_object() calls. */ > + spin_lock(&inode->i_lock); > + object =3D rcu_dereference_protected(inode_sec->object, > + lockdep_is_held(&inode->i_lock)); rcu_dereference_protected() requires that inode_sec->object is not concurrently changed, but I think another thread could call get_inode_object() while we're in landlock_create_object(), and then we could race with the NULL write in release_inode() here? (It wouldn't actually be a UAF though because we're not actually accessing `object` here.) Or am I missing a lock that prevents this? In v28 this wasn't an issue because release_inode() was holding inode->i_lock (and object->lock) during the NULL store; but in v29 and this version the NULL store in release_inode() moved out of the locked region. I think you could just move the NULL store in release_inode() back up (and maybe add a comment explaining the locking rules for landlock_inode(...)->object)? (Or alternatively you could use rcu_dereference_raw() with a comment explaining that the read pointer is only used to check for NULL-ness, and that it is guaranteed that the pointer can't change if it is NULL and we're holding the lock. But that'd be needlessly complicated, I think.) > + if (unlikely(object)) { > + /* Someone else just created the object, bail out and ret= ry. */ > + spin_unlock(&inode->i_lock); > + kfree(new_object); > + > + rcu_read_lock(); > + goto retry; > + } > + > + rcu_assign_pointer(inode_sec->object, new_object); > + /* > + * @inode will be released by hook_sb_delete() on its superblock > + * shutdown. > + */ > + ihold(inode); > + spin_unlock(&inode->i_lock); > + return new_object; > +}