Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp923177rdb; Tue, 30 Jan 2024 02:48:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IFGDiYMf4ghrx02JkgGaPlOpe9HpHCbIQ1kbSNnkmskWujmskBiCZIlWGaHPKQTtqybN3mS X-Received: by 2002:a17:906:52cb:b0:a31:8dd6:6ae0 with SMTP id w11-20020a17090652cb00b00a318dd66ae0mr6639506ejn.7.1706611716358; Tue, 30 Jan 2024 02:48:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706611716; cv=pass; d=google.com; s=arc-20160816; b=y7/P6mAHZ+Rb3glAwJCviincO8oMswvL9y+d0W6K/peW0mV8L7YUKkD+TFeNpQsXoM 3puFEDIJ4iTYtmBqx33sZFWG45wacxl1tOmyavhamRP4H43Vdbj1orO8NFzz2xKmeG6D zMotGuGeUK3cRY/jownIqyEJqy1CpPUJvAVW6Kjy46xaZ+4VboaXrSMaYJTu4PuPoYBE VpoaVvou0nzIblZh4H/B2RMkDnZxs5XjiUWnZn4WZUgI0GA8HQyfWVFHshrtqPDwXuB7 M5XXEJd2er9dTLIoXdw0ZLW+8pqL/Mht6BdboujbqskaJRjrCAOs4neeDva6RDQ4nrjd etcg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=aeWWumiMvO7G/LJJ1VlLUj/BhZ+xYyfibdhy/OeiNMc=; fh=oA4vKbIVKVm21Z5TxCAERFFi3qdTNtKQrynLK26oGA4=; b=eLErCY7t0UzIVMFyceZJVPh1q3V82gs048BIqFxfcafF8G2nwkHDOhmBOyqNuBElSZ vIVke9HCvQYQbXxgjyADwbf6JAGoLm53uuht4EvoapH2l7JBVf/yQbdkViSMwqSX82Xx TNCUK5ZqIuyAC74fA2nCFsgPjif+wo5TzVJw4SbfUOjzXWpwd1H3SzUggvISufIs65ZS 94juJI+DMqAMT9WqZHmNzZSIHit9DK/TFuZo8DWop+Yj2GiZ1ZEhpOev7+3yhRfpuGAI SQdzt7cgWq9eEGmCIyzEwqi+PSdAx+GEImphvtSXVOgncTgCA+MZVZvo/CjxTwxgwbVU BZNg== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=i-love.sakura.ne.jp); spf=pass (google.com: domain of linux-kernel+bounces-44415-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44415-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id o19-20020a1709061d5300b00a3104ffeabfsi4391010ejh.558.2024.01.30.02.48.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 02:48:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44415-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=i-love.sakura.ne.jp); spf=pass (google.com: domain of linux-kernel+bounces-44415-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44415-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 67CF01F27FDE for ; Tue, 30 Jan 2024 10:46:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 647606BB30; Tue, 30 Jan 2024 10:44:04 +0000 (UTC) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 502F76A03A; Tue, 30 Jan 2024 10:44:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.181.97.72 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706611443; cv=none; b=fZ/tbsvnVyqqwtqemq4VirWeP+Vg6fonAKXpffylNMaS8umUJvaNHDWtcaQLn4x/u4HmU63YGuFMDe4biFl3/GCmnwreChrgYtL7lZ1CjmpittEBTGX5OoY25KVqyOQG4Hjdt7LxjEy70uPMHS2L2H/PFwWtv1GB2bwdi7nznIs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706611443; c=relaxed/simple; bh=LR4Tqdwk6o5B3sBkOoFmCKb782ENpektt/aVbGbwqOo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DDn/6LwfTwhrFKK1uwtfht69SiPaiy3g/s33mIwJ1PewMkFcyZzhzNiaVcgAVQraEtRp/1OQymndMaPwkSLDYDDd5XOvnJ3Bs+9UOrLtUh6RhY5Quecwg8114MsitkpcfmlzIdRee/1sGrYuf/bnHP2BYz7nrBXwph91ekj6H8Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=I-love.SAKURA.ne.jp; spf=pass smtp.mailfrom=I-love.SAKURA.ne.jp; arc=none smtp.client-ip=202.181.97.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=I-love.SAKURA.ne.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=I-love.SAKURA.ne.jp Received: from fsav413.sakura.ne.jp (fsav413.sakura.ne.jp [133.242.250.112]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 40UAh0Lq008630; Tue, 30 Jan 2024 19:43:00 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav413.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav413.sakura.ne.jp); Tue, 30 Jan 2024 19:43:00 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav413.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 40UAh0YY008627 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jan 2024 19:43:00 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <56432241-1947-4701-a3d1-febd57fb3096@I-love.SAKURA.ne.jp> Date: Tue, 30 Jan 2024 19:42:59 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] LSM: add security_bprm_aborting_creds() hook Content-Language: en-US To: "Eric W. Biederman" Cc: Linus Torvalds , Kees Cook , Christian Brauner , Jan Kara , Paul Moore , James Morris , "Serge E. Hallyn" , linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, LKML References: <613a54d2-9508-4f87-a163-a25a77a101cd@I-love.SAKURA.ne.jp> <87frygbx04.fsf@email.froward.int.ebiederm.org> <8734ug9fbt.fsf@email.froward.int.ebiederm.org> From: Tetsuo Handa In-Reply-To: <8734ug9fbt.fsf@email.froward.int.ebiederm.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2024/01/30 3:15, Eric W. Biederman wrote: > If you aren't going to change your design your new hook should be: > security_execve_revert(current); > Or maybe: > security_execve_abort(current); > > At least then it is based upon the reality that you plan to revert > changes to current->security. Saying anything about creds or bprm when > you don't touch them, makes no sense at all. Causing people to > completely misunderstand what is going on, and making it more likely > they will change the code in ways that will break TOMOYO. Fine for me. The current argument is redundant, for nobody will try to call security_execve_abort() on a remote thread. > > > What I understand from the documentation you provided about TOMOYO is: > - TOMOYO provides the domain transition early so that the executable > can be read. > - TOMOYO did that because it could not detect reliably when a file > was opened for execve and read for execve. > > Am I wrong in my understanding? > > If that understanding is correct, now that (file->f_mode & __FMODE_EXEC) > is a reliable indication of a file used exclusively for exec then it > should be possible to take advantage of the new information and get > TOMOYO and the rest of the execve playing nicely with each other without > having to add new hooks. current->in_execve flag has two purposes: "whether to check permission" and "what domain is used for checking permission (if need to check permission)". One is to distinguish "open from execve()" and "open from uselib()". This was replaced by the (file->f_mode & __FMODE_EXEC) change, for __FMODE_EXEC was now removed from uselib(). But this is after all about "whether to check permission". The other is to emulate security_execve_abort(). security_execve_abort() is needed because TOMOYO checks permission for opening interpreter file from execve() using a domain which the current thread will belong to if execve() succeeds (whereas DAC checks permission for opening interpreter file from execve() using credentials which the current thread is currently using). This is about "what domain is used for checking permission". Since security_file_open() hook cannot see bprm->cred, TOMOYO cannot know "what domain is used for checking permission" from security_file_open(). TOMOYO can know only "whether to check permission" from security_file_open(). Since TOMOYO cannot pass bprm->cred to security_file_open() hook using override_creds()/revert_creds(), TOMOYO is passing "what domain is used for checking permission" to security_file_open() via "struct task_struct"->security. "struct task_struct"->security is updated _before_ security_file_open() for the interpreter file is called. Since security_execve_abort() was missing, when execve() failed, TOMOYO had to keep the domain which the current thread would belong to if execve() succeeded. The kept domain is cleared when TOMOYO finds that previous execve() was finished (indicated by current->in_execve == 0) or when TOMOYO finds that new execve() is in progress (indicated by current->in_execve == 0 when security_cred_prepare() is called). It is not possible to extract "what domain is used for checking permission" from "whether file->f_mode includes __FMODE_EXEC". Talking about the (file->f_mode & __FMODE_EXEC) change (i.e. "whether to check permission") is pointless when talking about "what domain is used for checking permission".