Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp495751ybn; Thu, 3 Oct 2019 08:03:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqy6yb4FNXVKpon9VD4ZB82rMkyfg8tUejpf0alcKQ1JKeB8ZjjSRaJ+n2muaKIZijS8HQv8 X-Received: by 2002:a17:907:214e:: with SMTP id rk14mr8210157ejb.60.1570114998458; Thu, 03 Oct 2019 08:03:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570114998; cv=none; d=google.com; s=arc-20160816; b=hOE4QCaJXrsJ4LBM0g+q5K/tzUcLu0i4kjD1u4nPpB4YBir2UcrIrfTGfjHa688HI+ 7JKAGjc3UwQQ3nQGGLa99q9IRBXi3V9WpOb8j5wiCERBDnSRIzpJCpa5MCaUK4hS0OQZ ojzCu/98NVyTPq3t9s7Ge9yxVrEo3b6fL0GCzTLc4aiiHG/rTClQqE3pcmSJ+NLipbn1 yTovXlcn6Wb8NSWeaGFTBm+ZbvfNsU9b82qY6C2xgX/0jZDpQhyzmXQqa2fVAPfpxPRY J7qJBf3Qbda/09nmqMUolrXrecN2JWbcK/tlTXY6XF9W2LL2PjTQ44iq8h7wMvKKW1a5 UU4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=2w0BQYJOfzWJ25yRyc9a0T0X7XSZB9cIe2qNjFg+QW8=; b=eZrWzlpKkTb1XfJLPwGjnOMfvBWsmtRh5Vm5ml94vAGBqdVGFQEiKo+pyrWMgYWgEp tVFLQ0T6lnw9BASjipXHDLaflMY885dkLH6ODxJzxfrWc3AUQbxBGifjsdST9YJhwLE/ JOMP0PbKV5fDhKUFaMU5p1OKdxRnXYUgZAoTE36DRBHCOFw4rFqGbPuZxilF8Zv9LSEu 4ASkmXGONMf3UPQ10kAh0AI/Wn3kcBDowu/W62BbdRefc4ypiYkcGmUcknnoTKUtgoWo /dvIuYuvXtwcbgCiFnSq9l5cQmBPAMBOvoVPXGiQAU0yqhTHwkj8eFDZxtl+Oen6UZ4W rOSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f21si1472881edb.379.2019.10.03.08.02.51; Thu, 03 Oct 2019 08:03:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730421AbfJCO4X (ORCPT + 99 others); Thu, 3 Oct 2019 10:56:23 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:11276 "EHLO mx2.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726364AbfJCO4V (ORCPT ); Thu, 3 Oct 2019 10:56:21 -0400 Received: from smtp2.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id C800FA1DD9; Thu, 3 Oct 2019 16:56:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id sQCs1Y8x6r5z; Thu, 3 Oct 2019 16:56:15 +0200 (CEST) From: Aleksa Sarai To: Al Viro , Michael Kerrisk Cc: Aleksa Sarai , Christian Brauner , Aleksa Sarai , linux-man@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH RFC 1/3] symlink.7: document magic-links more completely Date: Fri, 4 Oct 2019 00:55:39 +1000 Message-Id: <20191003145542.17490-2-cyphar@cyphar.com> In-Reply-To: <20191003145542.17490-1-cyphar@cyphar.com> References: <20191003145542.17490-1-cyphar@cyphar.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Traditionally, magic-links have not been a well-understood topic in Linux. Given the new changes in their semantics (related to the link mode of trailing magic-links), it seems like a good opportunity to shine more light on magic-links and their semantics. Signed-off-by: Aleksa Sarai --- man7/path_resolution.7 | 15 +++++++++++++++ man7/symlink.7 | 39 ++++++++++++++++++++++++++++++--------- 2 files changed, 45 insertions(+), 9 deletions(-) diff --git a/man7/path_resolution.7 b/man7/path_resolution.7 index 07664ed8faec..46f25ec4cdfa 100644 --- a/man7/path_resolution.7 +++ b/man7/path_resolution.7 @@ -136,6 +136,21 @@ we are just creating it. The details on the treatment of the final entry are described in the manual pages of the specific system calls. +.PP +Since Linux 5.FOO, if the final entry is a "magic-link" (see +.BR symlink (7)), +and the user is attempting to +.BR open (2) +it, then there is an additional permission-related restriction applied to the +operation: the requested access mode must not exceed the "link mode" of the +magic-link (unlike ordinary symlinks, magic-links have their own file mode.) +For example, if +.I /proc/[pid]/fd/[num] +has a link mode of +.BR 0500 , +unprivileged users are not permitted to +.BR open () +the magic-link for writing. .SS . and .. By convention, every directory has the entries "." and "..", which refer to the directory itself and to its parent directory, diff --git a/man7/symlink.7 b/man7/symlink.7 index 9f5bddd5dc21..33f0ec703acd 100644 --- a/man7/symlink.7 +++ b/man7/symlink.7 @@ -84,6 +84,25 @@ as they are implemented on Linux and other systems, are outlined here. It is important that site-local applications also conform to these rules, so that the user interface can be as consistent as possible. +.SS Magic-links +There is a special class of symlink-like objects known as "magic-links" which +can be found in certain pseudo-filesystems such as +.BR proc (5) +(examples include +.IR /proc/[pid]/exe " and " /proc/[pid]/fd/* .) +Unlike normal symlinks, magic-links are not resolved through +pathname-expansion, but instead act as direct references to the kernel's own +representation of a file handle. As such, these magic-links allow users to +access files which cannot be referenced with normal paths (such as unlinked +files still referenced by a running program.) +.PP +Because they can bypass ordinary +.BR mount_namespaces (7)-based +restrictions, magic-links have been used as attack vectors in various exploits. +As such (since Linux 5.FOO), there are additional restrictions placed on the +re-opening of magic-links (see +.BR path_resolution (7) +for more details.) .SS Symbolic link ownership, permissions, and timestamps The owner and group of an existing symbolic link can be changed using @@ -99,16 +118,18 @@ of a symbolic link can be changed using or .BR lutimes (3). .PP -On Linux, the permissions of a symbolic link are not used -in any operations; the permissions are always -0777 (read, write, and execute for all user categories), .\" Linux does not currently implement an lchmod(2). -and can't be changed. -(Note that there are some "magic" symbolic links in the -.I /proc -directory tree\(emfor example, the -.IR /proc/[pid]/fd/* -files\(emthat have different permissions.) +On Linux, the permissions of an ordinary symbolic link are not used in any +operations; the permissions are always 0777 (read, write, and execute for all +user categories), and can't be changed. +.PP +However, magic-links do not follow this rule. They can have a non-0777 mode, +which is used for permission checks when the final +component of an +.BR open (2)'s +path is a magic-link (see +.BR path_resolution (7).) + .\" .\" The .\" 4.4BSD -- 2.23.0