From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound.smtp.vt.edu ([198.82.183.121]:53056 "EHLO omr2.cc.vt.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726190AbeIZGy6 (ORCPT ); Wed, 26 Sep 2018 02:54:58 -0400 Received: from mr6.cc.vt.edu (mr6.cc.vt.edu [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id w8Q0imPt015260 for ; Tue, 25 Sep 2018 20:44:48 -0400 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mr6.cc.vt.edu (8.14.7/8.14.7) with ESMTP id w8Q0ih6m001812 for ; Tue, 25 Sep 2018 20:44:48 -0400 Received: by mail-qk1-f197.google.com with SMTP id s22-v6so1930278qkg.2 for ; Tue, 25 Sep 2018 17:44:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: Leaking path for set_task_comm From: TongZhang In-Reply-To: <20180925183953.GI15710@uranus> Date: Tue, 25 Sep 2018 20:44:39 -0400 Cc: adobriyan@gmail.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, LKML , linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, Wenbo Shen Content-Transfer-Encoding: 8BIT Message-Id: <0CD63E6E-7512-4DD6-8858-4408416DC730@vt.edu> References: <20180925183953.GI15710@uranus> To: Cyrill Gorcunov Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Yes, this is exactly what I am saying. A process can change its own name using prctl or /proc/self/comm. prctl is protected by security_task_prctl, whereas /proc/self/comm is not protected by this LSM hook. A system admin may expect to use security_task_prctl to block all attempt to change process name, however, it can still change name using /proc/self/comm. > On Sep 25, 2018, at 2:39 PM, Cyrill Gorcunov wrote: > > On Tue, Sep 25, 2018 at 01:27:08PM -0400, Tong Zhang wrote: >> Kernel Version: 4.18.5 >> >> Problem Description: >> >> When using prctl(PR_SET_NAME) to set the thread name, it is checked by security_task_prctl. >> >> We discovered a leaking path that can also use method implemented in >> fs/proc/base.c:1526 comm_write(), to do similar thing without asking LSM’s decision. > > I don't understand how it is a problem. Could you please explain? > procfs/comm is created with S_IRUGO|S_IWUSR permissions. So > prctl and procfs are simply different interfaces.