| Message ID | 1710560151-28904-13-git-send-email-wufan@linux.microsoft.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Integrity Policy Enforcement LSM (IPE) | expand |
On Mar 15, 2024 Fan Wu <wufan@linux.microsoft.com> wrote: > > This patch introduces a new hook to save block device's integrity > data. For example, for dm-verity, LSMs can use this hook to save > the roothash signature of a dm-verity into the security blob, > and LSMs can make access decisions based on the data inside > the signature, like the signer certificate. > > Signed-off-by: Fan Wu <wufan@linux.microsoft.com> > > -- > v1-v14: > + Not present > > v15: > + Introduced > > --- > include/linux/lsm_hook_defs.h | 2 ++ > include/linux/security.h | 14 ++++++++++++++ > security/security.c | 28 ++++++++++++++++++++++++++++ > 3 files changed, 44 insertions(+) I'm not sure why you made this a separate patch, help? If there is no significant reason why this is separate, please squash it together with patch 11/21. > diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h > index c335404470dc..6808ae763913 100644 > --- a/include/linux/lsm_hook_defs.h > +++ b/include/linux/lsm_hook_defs.h > @@ -455,4 +455,6 @@ LSM_HOOK(void, LSM_RET_VOID, initramfs_populated, void) > > LSM_HOOK(int, 0, bdev_alloc_security, struct block_device *bdev) > LSM_HOOK(void, LSM_RET_VOID, bdev_free_security, struct block_device *bdev) > +LSM_HOOK(int, 0, bdev_setintegrity, struct block_device *bdev, > + enum lsm_intgr_type type, const void *value, size_t size) > > diff --git a/include/linux/security.h b/include/linux/security.h > index 9965b5c50df4..eaff8868766a 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -83,6 +83,10 @@ enum lsm_event { > LSM_POLICY_CHANGE, > }; > > +enum lsm_intgr_type { > + __LSM_INTGR_MAX > +}; > + > /* > * These are reasons that can be passed to the security_locked_down() > * LSM hook. Lockdown reasons that protect kernel integrity (ie, the > @@ -511,6 +515,9 @@ int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len, > void *val, size_t val_len, u64 id, u64 flags); > int security_bdev_alloc(struct block_device *bdev); > void security_bdev_free(struct block_device *bdev); > +int security_bdev_setintegrity(struct block_device *bdev, > + enum lsm_intgr_type type, const void *value, > + size_t size); > #else /* CONFIG_SECURITY */ > > static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data) > @@ -1495,6 +1502,13 @@ static inline void security_bdev_free(struct block_device *bdev) > { > } > > +static inline int security_bdev_setintegrity(struct block_device *bdev, > + enum lsm_intgr_type, type, > + const void *value, size_t size) > +{ > + return 0; > +} > + > #endif /* CONFIG_SECURITY */ > > #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE) > diff --git a/security/security.c b/security/security.c > index 4274bbee40d0..8d88529ac904 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -5637,6 +5637,34 @@ void security_bdev_free(struct block_device *bdev) > } > EXPORT_SYMBOL(security_bdev_free); > > +/** > + * security_bdev_setintegrity() - Set the bdev's integrity data Let's just say "Set the device's integrity data" and not ask people to figure out "bdev", although I will admit it should be fairly obvious :) > + * @bdev: block device > + * @type: type of integrity, e.g. hash digest, signature, etc > + * @value: the integrity value > + * @size: size of the integrity value > + * > + * Register a verified integrity measurement of a bdev with the LSM. > + * > + * Return: Returns 0 on success, negative values on failure. > + */ > +int security_bdev_setintegrity(struct block_device *bdev, > + enum lsm_intgr_type type, const void *value, > + size_t size) > +{ > + int rc = 0; > + struct security_hook_list *p; > + > + hlist_for_each_entry(p, &security_hook_heads.bdev_setintegrity, list) { > + rc = p->hook.bdev_setintegrity(bdev, type, value, size); > + if (rc) > + return rc; > + } > + > + return LSM_RET_DEFAULT(bdev_setintegrity); We can just use the call_int_hook() macro here instead of open coding everything, right? > +} > +EXPORT_SYMBOL(security_bdev_setintegrity); > + > #ifdef CONFIG_PERF_EVENTS > /** > * security_perf_event_open() - Check if a perf event open is allowed > -- > 2.44.0 -- paul-moore.com
On Wed Mar 20, 2024 at 1:00 AM EET, Paul Moore wrote: > On Mar 15, 2024 Fan Wu <wufan@linux.microsoft.com> wrote: > > > > This patch introduces a new hook to save block device's integrity > > data. For example, for dm-verity, LSMs can use this hook to save > > the roothash signature of a dm-verity into the security blob, > > and LSMs can make access decisions based on the data inside > > the signature, like the signer certificate. > > > > Signed-off-by: Fan Wu <wufan@linux.microsoft.com> > > > > -- > > v1-v14: > > + Not present > > > > v15: > > + Introduced > > > > --- > > include/linux/lsm_hook_defs.h | 2 ++ > > include/linux/security.h | 14 ++++++++++++++ > > security/security.c | 28 ++++++++++++++++++++++++++++ > > 3 files changed, 44 insertions(+) > > I'm not sure why you made this a separate patch, help? If there is > no significant reason why this is separate, please squash it together > with patch 11/21. Off-topic: it is weird to have *RFC* patch set at v15. RFC by de-facto is something that can be safely ignored if you don't have bandwidth. 15 versions of anything that can be safely ignored is by definition spamming :-) I mean just conceptually. So does the RFC still hold or what the heck is going on with this one? Haven't followed for some time now... BR, Jarkko
On Wed Mar 20, 2024 at 10:28 AM EET, Jarkko Sakkinen wrote: > On Wed Mar 20, 2024 at 1:00 AM EET, Paul Moore wrote: > > On Mar 15, 2024 Fan Wu <wufan@linux.microsoft.com> wrote: > > > > > > This patch introduces a new hook to save block device's integrity > > > data. For example, for dm-verity, LSMs can use this hook to save > > > the roothash signature of a dm-verity into the security blob, > > > and LSMs can make access decisions based on the data inside > > > the signature, like the signer certificate. > > > > > > Signed-off-by: Fan Wu <wufan@linux.microsoft.com> > > > > > > -- > > > v1-v14: > > > + Not present > > > > > > v15: > > > + Introduced > > > > > > --- > > > include/linux/lsm_hook_defs.h | 2 ++ > > > include/linux/security.h | 14 ++++++++++++++ > > > security/security.c | 28 ++++++++++++++++++++++++++++ > > > 3 files changed, 44 insertions(+) > > > > I'm not sure why you made this a separate patch, help? If there is > > no significant reason why this is separate, please squash it together > > with patch 11/21. > > Off-topic: it is weird to have *RFC* patch set at v15. > > RFC by de-facto is something that can be safely ignored if you don't > have bandwidth. 15 versions of anything that can be safely ignored > is by definition spamming :-) I mean just conceptually. > > So does the RFC still hold or what the heck is going on with this one? > > Haven't followed for some time now... I mean if this RFC trend continues I'll just put auto-filter for this thread to put straight to the bin. There's enough non-RFC patch sets to review. BR, Jarkko
On 3/20/2024 1:31 AM, Jarkko Sakkinen wrote: > On Wed Mar 20, 2024 at 10:28 AM EET, Jarkko Sakkinen wrote: >> On Wed Mar 20, 2024 at 1:00 AM EET, Paul Moore wrote: >>> On Mar 15, 2024 Fan Wu <wufan@linux.microsoft.com> wrote: >>>> >>>> This patch introduces a new hook to save block device's integrity >>>> data. For example, for dm-verity, LSMs can use this hook to save >>>> the roothash signature of a dm-verity into the security blob, >>>> and LSMs can make access decisions based on the data inside >>>> the signature, like the signer certificate. >>>> >>>> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> >>>> >>>> -- >>>> v1-v14: >>>> + Not present >>>> >>>> v15: >>>> + Introduced >>>> >>>> --- >>>> include/linux/lsm_hook_defs.h | 2 ++ >>>> include/linux/security.h | 14 ++++++++++++++ >>>> security/security.c | 28 ++++++++++++++++++++++++++++ >>>> 3 files changed, 44 insertions(+) >>> >>> I'm not sure why you made this a separate patch, help? If there is >>> no significant reason why this is separate, please squash it together >>> with patch 11/21. >> >> Off-topic: it is weird to have *RFC* patch set at v15. >> >> RFC by de-facto is something that can be safely ignored if you don't >> have bandwidth. 15 versions of anything that can be safely ignored >> is by definition spamming :-) I mean just conceptually. >> >> So does the RFC still hold or what the heck is going on with this one? >> >> Haven't followed for some time now... > > I mean if this RFC trend continues I'll just put auto-filter for this > thread to put straight to the bin. There's enough non-RFC patch sets > to review. > > BR, Jarkko Sorry about the confusion with the RFC tag – I wasn't fully aware of its conventional meaning and how it's perceived in terms of importance and urgency. Point taken, and I'll make sure to remove the RFC tag for future submissions. Definitely not my intention to clog up the workflow or seem like I'm spamming. -Fan
On Wed Mar 20, 2024 at 10:31 PM EET, Fan Wu wrote: > > > On 3/20/2024 1:31 AM, Jarkko Sakkinen wrote: > > On Wed Mar 20, 2024 at 10:28 AM EET, Jarkko Sakkinen wrote: > >> On Wed Mar 20, 2024 at 1:00 AM EET, Paul Moore wrote: > >>> On Mar 15, 2024 Fan Wu <wufan@linux.microsoft.com> wrote: > >>>> > >>>> This patch introduces a new hook to save block device's integrity > >>>> data. For example, for dm-verity, LSMs can use this hook to save > >>>> the roothash signature of a dm-verity into the security blob, > >>>> and LSMs can make access decisions based on the data inside > >>>> the signature, like the signer certificate. > >>>> > >>>> Signed-off-by: Fan Wu <wufan@linux.microsoft.com> > >>>> > >>>> -- > >>>> v1-v14: > >>>> + Not present > >>>> > >>>> v15: > >>>> + Introduced > >>>> > >>>> --- > >>>> include/linux/lsm_hook_defs.h | 2 ++ > >>>> include/linux/security.h | 14 ++++++++++++++ > >>>> security/security.c | 28 ++++++++++++++++++++++++++++ > >>>> 3 files changed, 44 insertions(+) > >>> > >>> I'm not sure why you made this a separate patch, help? If there is > >>> no significant reason why this is separate, please squash it together > >>> with patch 11/21. > >> > >> Off-topic: it is weird to have *RFC* patch set at v15. > >> > >> RFC by de-facto is something that can be safely ignored if you don't > >> have bandwidth. 15 versions of anything that can be safely ignored > >> is by definition spamming :-) I mean just conceptually. > >> > >> So does the RFC still hold or what the heck is going on with this one? > >> > >> Haven't followed for some time now... > > > > I mean if this RFC trend continues I'll just put auto-filter for this > > thread to put straight to the bin. There's enough non-RFC patch sets > > to review. > > > > BR, Jarkko > > Sorry about the confusion with the RFC tag – I wasn't fully aware of its > conventional meaning and how it's perceived in terms of importance and > urgency. Point taken, and I'll make sure to remove the RFC tag for > future submissions. Definitely not my intention to clog up the workflow > or seem like I'm spamming. OK cool! Just wanted to point this out also because it already looks good enough not to be considered as RFC in my eyes :-) If you keep RFC it is by definition "look into if you have the bandwidth but please do not take this to mainline". No means to nitpick here... BR, Jarkko
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h index c335404470dc..6808ae763913 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -455,4 +455,6 @@ LSM_HOOK(void, LSM_RET_VOID, initramfs_populated, void) LSM_HOOK(int, 0, bdev_alloc_security, struct block_device *bdev) LSM_HOOK(void, LSM_RET_VOID, bdev_free_security, struct block_device *bdev) +LSM_HOOK(int, 0, bdev_setintegrity, struct block_device *bdev, + enum lsm_intgr_type type, const void *value, size_t size) diff --git a/include/linux/security.h b/include/linux/security.h index 9965b5c50df4..eaff8868766a 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -83,6 +83,10 @@ enum lsm_event { LSM_POLICY_CHANGE, }; +enum lsm_intgr_type { + __LSM_INTGR_MAX +}; + /* * These are reasons that can be passed to the security_locked_down() * LSM hook. Lockdown reasons that protect kernel integrity (ie, the @@ -511,6 +515,9 @@ int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len, void *val, size_t val_len, u64 id, u64 flags); int security_bdev_alloc(struct block_device *bdev); void security_bdev_free(struct block_device *bdev); +int security_bdev_setintegrity(struct block_device *bdev, + enum lsm_intgr_type type, const void *value, + size_t size); #else /* CONFIG_SECURITY */ static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data) @@ -1495,6 +1502,13 @@ static inline void security_bdev_free(struct block_device *bdev) { } +static inline int security_bdev_setintegrity(struct block_device *bdev, + enum lsm_intgr_type, type, + const void *value, size_t size) +{ + return 0; +} + #endif /* CONFIG_SECURITY */ #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE) diff --git a/security/security.c b/security/security.c index 4274bbee40d0..8d88529ac904 100644 --- a/security/security.c +++ b/security/security.c @@ -5637,6 +5637,34 @@ void security_bdev_free(struct block_device *bdev) } EXPORT_SYMBOL(security_bdev_free); +/** + * security_bdev_setintegrity() - Set the bdev's integrity data + * @bdev: block device + * @type: type of integrity, e.g. hash digest, signature, etc + * @value: the integrity value + * @size: size of the integrity value + * + * Register a verified integrity measurement of a bdev with the LSM. + * + * Return: Returns 0 on success, negative values on failure. + */ +int security_bdev_setintegrity(struct block_device *bdev, + enum lsm_intgr_type type, const void *value, + size_t size) +{ + int rc = 0; + struct security_hook_list *p; + + hlist_for_each_entry(p, &security_hook_heads.bdev_setintegrity, list) { + rc = p->hook.bdev_setintegrity(bdev, type, value, size); + if (rc) + return rc; + } + + return LSM_RET_DEFAULT(bdev_setintegrity); +} +EXPORT_SYMBOL(security_bdev_setintegrity); + #ifdef CONFIG_PERF_EVENTS /** * security_perf_event_open() - Check if a perf event open is allowed
This patch introduces a new hook to save block device's integrity data. For example, for dm-verity, LSMs can use this hook to save the roothash signature of a dm-verity into the security blob, and LSMs can make access decisions based on the data inside the signature, like the signer certificate. Signed-off-by: Fan Wu <wufan@linux.microsoft.com> -- v1-v14: + Not present v15: + Introduced --- include/linux/lsm_hook_defs.h | 2 ++ include/linux/security.h | 14 ++++++++++++++ security/security.c | 28 ++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+)