All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fan Wu <wufan@linux.microsoft.com>
To: Paul Moore <paul@paul-moore.com>,
	corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org,
	serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org,
	axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org,
	eparis@redhat.com
Cc: linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
	dm-devel@lists.linux.dev, audit@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v12 5/20] initramfs|security: Add security hook to initramfs unpack
Date: Mon, 5 Feb 2024 13:18:03 -0800	[thread overview]
Message-ID: <13daca32-ee3f-46f5-a6ca-66bb02726e5c@linux.microsoft.com> (raw)
In-Reply-To: <b9ca171301d5abeb78922dd79d65136a@paul-moore.com>



On 2/3/2024 2:25 PM, Paul Moore wrote:
> On Jan 30, 2024 Fan Wu <wufan@linux.microsoft.com> wrote:
>>
>> This patch introduces a new hook to notify security system that the
>> content of initramfs has been unpacked into the rootfs.
>>
>> Upon receiving this notification, the security system can activate
>> a policy to allow only files that originated from the initramfs to
>> execute or load into kernel during the early stages of booting.
>>
>> This approach is crucial for minimizing the attack surface by
>> ensuring that only trusted files from the initramfs are operational
>> in the critical boot phase.
>>
>> Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
>> ---
>> v1-v11:
>>    + Not present
>>
>> v12:
>>    + Introduced
>> ---
>>   include/linux/lsm_hook_defs.h |  4 ++++
>>   include/linux/security.h      | 10 ++++++++++
>>   init/initramfs.c              |  3 +++
>>   security/security.c           | 12 ++++++++++++
>>   4 files changed, 29 insertions(+)
>>
>> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
>> index 185924c56378..b247388786a9 100644
>> --- a/include/linux/lsm_hook_defs.h
>> +++ b/include/linux/lsm_hook_defs.h
>> @@ -425,3 +425,7 @@ LSM_HOOK(int, 0, uring_override_creds, const struct cred *new)
>>   LSM_HOOK(int, 0, uring_sqpoll, void)
>>   LSM_HOOK(int, 0, uring_cmd, struct io_uring_cmd *ioucmd)
>>   #endif /* CONFIG_IO_URING */
>> +
>> +#ifdef CONFIG_BLK_DEV_INITRD
>> +LSM_HOOK(void, LSM_RET_VOID, unpack_initramfs_security, void)
>> +#endif /* CONFIG_BLK_DEV_INITRD */
> 
> Let's just call it "unpack_initramfs", the "_security" part is somewhat
> implied since we are talking about a LSM hook ;)
> 
>> diff --git a/init/initramfs.c b/init/initramfs.c
>> index 76deb48c38cb..075a5794cde5 100644
>> --- a/init/initramfs.c
>> +++ b/init/initramfs.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/init_syscalls.h>
>>   #include <linux/task_work.h>
>>   #include <linux/umh.h>
>> +#include <linux/security.h>
>>   
>>   static __initdata bool csum_present;
>>   static __initdata u32 io_csum;
>> @@ -720,6 +721,8 @@ static void __init do_populate_rootfs(void *unused, async_cookie_t cookie)
>>   #endif
>>   	}
>>   
>> +	security_unpack_initramfs();
> 
> Given the caller, what do you think of changing the hook name to
> "security_initramfs_populated()"?  I think this not only matches up
> better with the caller, "do_populate_rootfs()", but since in using the
> past tense we help indicate that this hook happens *after* the rootfs
> is populated with the initramfs data.
> 

Yeah, I agree this sounds better. I will update this part.

-Fan
>>   done:
>>   	/*
>>   	 * If the initrd region is overlapped with crashkernel reserved region,
>> diff --git a/security/security.c b/security/security.c
>> index ddf2e69cf8f2..2a527d4c69bc 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -5581,3 +5581,15 @@ int security_uring_cmd(struct io_uring_cmd *ioucmd)
>>   	return call_int_hook(uring_cmd, 0, ioucmd);
>>   }
>>   #endif /* CONFIG_IO_URING */
>> +
>> +#ifdef CONFIG_BLK_DEV_INITRD
>> +/**
>> + * security_unpack_initramfs() - Notify LSM that initramfs has been loaded
>> + *
>> + * Tells the LSM the initramfs has been unpacked into the rootfs.
>> + */
>> +void security_unpack_initramfs(void)
>> +{
>> +	call_void_hook(unpack_initramfs_security);
>> +}
>> +#endif /* CONFIG_BLK_DEV_INITRD */
>> -- 
>> 2.43.0
> 
> --
> paul-moore.com

  reply	other threads:[~2024-02-05 21:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 22:36 [RFC PATCH v12 00/20] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 01/20] security: add ipe lsm Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 02/20] ipe: add policy parser Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 03/20] ipe: add evaluation loop Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 04/20] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-02-02 14:47   ` kernel test robot
2024-01-30 22:36 ` [RFC PATCH v12 05/20] initramfs|security: Add security hook to initramfs unpack Fan Wu
2024-02-03 22:25   ` [PATCH RFC v12 5/20] " Paul Moore
2024-02-05 21:18     ` Fan Wu [this message]
2024-01-30 22:36 ` [RFC PATCH v12 06/20] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-02-03 22:25   ` [PATCH RFC v12 6/20] " Paul Moore
2024-02-05 22:39     ` Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 07/20] security: add new securityfs delete function Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 08/20] ipe: add userspace interface Fan Wu
2024-02-03 22:25   ` [PATCH RFC v12 8/20] " Paul Moore
2024-02-05 23:01     ` Fan Wu
2024-02-05 23:10       ` Paul Moore
2024-02-05 23:21         ` Fan Wu
2024-01-30 22:36 ` [RFC PATCH v12 09/20] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-02-03 22:25   ` [PATCH RFC v12 9/20] " Paul Moore
2024-01-30 22:36 ` [RFC PATCH v12 10/20] ipe: add permissive toggle Fan Wu
2024-02-03 22:25   ` [PATCH RFC " Paul Moore
2024-01-30 22:36 ` [RFC PATCH v12 11/20] block|security: add LSM blob to block_device Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 12/20] dm verity: set DM_TARGET_SINGLETON feature flag Fan Wu
2024-02-02 18:51   ` Mike Snitzer
2024-02-03  3:56     ` Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 13/20] dm: add finalize hook to target_type Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 14/20] dm verity: consume root hash digest and signature data via LSM hook Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 15/20] ipe: add support for dm-verity as a trust provider Fan Wu
2024-02-03 22:25   ` [PATCH RFC " Paul Moore
2024-02-05 23:11     ` Fan Wu
2024-02-06 21:53       ` Paul Moore
2024-01-30 22:37 ` [RFC PATCH v12 16/20] fsverity: consume builtin signature via LSM hook Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 17/20] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-02-03 22:25   ` [PATCH RFC " Paul Moore
2024-01-30 22:37 ` [RFC PATCH v12 18/20] scripts: add boot policy generation program Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 19/20] ipe: kunit test for parser Fan Wu
2024-01-30 22:37 ` [RFC PATCH v12 20/20] documentation: add ipe documentation Fan Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13daca32-ee3f-46f5-a6ca-66bb02726e5c@linux.microsoft.com \
    --to=wufan@linux.microsoft.com \
    --cc=agk@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=dm-devel@lists.linux.dev \
    --cc=ebiggers@kernel.org \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=snitzer@kernel.org \
    --cc=tytso@mit.edu \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.