| Message ID | 20240415142436.2545003-1-roberto.sassu@huaweicloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | security: digest_cache LSM | expand |
On Mon Apr 15, 2024 at 5:24 PM EEST, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > Integrity detection and protection has long been a desirable feature, to > reach a large user base and mitigate the risk of flaws in the software > and attacks. > > However, while solutions exist, they struggle to reach the large user > base, due to requiring higher than desired constraints on performance, > flexibility and configurability, that only security conscious people are > willing to accept. > > This is where the new digest_cache LSM comes into play, it offers > additional support for new and existing integrity solutions, to make > them faster and easier to deploy. Sorry for nitpicking but what are the existing integrity solutions, and how does it help with this struggle? I.e. what is the gist here? BR, Jarkko
On Mon, Apr 15, 2024 at 04:24:22PM +0200, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > Integrity detection and protection has long been a desirable feature, to > reach a large user base and mitigate the risk of flaws in the software > and attacks. > > However, while solutions exist, they struggle to reach the large user > base, due to requiring higher than desired constraints on performance, > flexibility and configurability, that only security conscious people are > willing to accept. > > This is where the new digest_cache LSM comes into play, it offers > additional support for new and existing integrity solutions, to make > them faster and easier to deploy. > > The full documentation with the motivation and the solution details can be > found in patch 14. > > The IMA integration patch set will be introduced separately. Also a PoC > based on the current version of IPE can be provided. > I can't cleanly apply this series (conflict on patch [13/14]). Can you point out the base commit of this series? Confused...
On Mon, 2024-04-15 at 22:18 +0300, Jarkko Sakkinen wrote: > On Mon Apr 15, 2024 at 5:24 PM EEST, Roberto Sassu wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > Integrity detection and protection has long been a desirable feature, to > > reach a large user base and mitigate the risk of flaws in the software > > and attacks. > > > > However, while solutions exist, they struggle to reach the large user > > base, due to requiring higher than desired constraints on performance, > > flexibility and configurability, that only security conscious people are > > willing to accept. > > > > This is where the new digest_cache LSM comes into play, it offers > > additional support for new and existing integrity solutions, to make > > them faster and easier to deploy. > > Sorry for nitpicking but what are the existing integrity solutions, > and how does it help with this struggle? I.e. what is the gist here? No worries... please have a look at patch 14. It should have all the information. Thanks Roberto
On 4/18/24 02:02, Roberto Sassu wrote: > > 72374d71c315 > > Roberto > Still FTA (fail to apply), unfortunately.
On Fri Apr 19, 2024 at 2:18 PM EEST, Bagas Sanjaya wrote: > On 4/18/24 02:02, Roberto Sassu wrote: > > > > 72374d71c315 > > > > Roberto > > > > Still FTA (fail to apply), unfortunately. Robert, quick suggestion. Maybe pick recent rc for the patch set, rebase on top of that and document that to the cover letter? In git: "git rebase <version>" when on branch with the patches applied. BR, Jarkko
On 4/19/2024 4:18 AM, Bagas Sanjaya wrote: > On 4/18/24 02:02, Roberto Sassu wrote: >> >> 72374d71c315 >> >> Roberto >> > > Still FTA (fail to apply), unfortunately. Sorry, looks like I didn't regenerate the patches after rebasing to the latest kernel. The current ones are still based on 6.8-rc3, but they still require some additional patches that I picked up. Will send the new version with Jarkko suggestions implemented. Thanks Roberto
On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > Integrity detection and protection has long been a desirable feature, to > reach a large user base and mitigate the risk of flaws in the software > and attacks. > > However, while solutions exist, they struggle to reach the large user > base, due to requiring higher than desired constraints on performance, > flexibility and configurability, that only security conscious people are > willing to accept. > > This is where the new digest_cache LSM comes into play, it offers > additional support for new and existing integrity solutions, to make > them faster and easier to deploy. > > The full documentation with the motivation and the solution details can be > found in patch 14. > > The IMA integration patch set will be introduced separately. Also a PoC > based on the current version of IPE can be provided. I'm not sure we want to implement a cache as a LSM. I'm sure it would work, but historically LSMs have provided some form of access control, measurement, or other traditional security service. A digest cache, while potentially useful for a variety of security related applications, is not a security service by itself, it is simply a file digest storage mechanism. I think it's fine if an individual LSM wants to implement a file digest cache as part of its own functionality, but a generalized file digest cache seems like something that should be part of the general kernel, and not implemented as a LSM.
On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > Integrity detection and protection has long been a desirable feature, to > > reach a large user base and mitigate the risk of flaws in the software > > and attacks. > > > > However, while solutions exist, they struggle to reach the large user > > base, due to requiring higher than desired constraints on performance, > > flexibility and configurability, that only security conscious people are > > willing to accept. > > > > This is where the new digest_cache LSM comes into play, it offers > > additional support for new and existing integrity solutions, to make > > them faster and easier to deploy. > > > > The full documentation with the motivation and the solution details can be > > found in patch 14. > > > > The IMA integration patch set will be introduced separately. Also a PoC > > based on the current version of IPE can be provided. > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > work, but historically LSMs have provided some form of access control, > measurement, or other traditional security service. A digest cache, > while potentially useful for a variety of security related > applications, is not a security service by itself, it is simply a file > digest storage mechanism. Uhm, currently the digest_cache LSM is heavily based on the LSM infrastructure: static struct security_hook_list digest_cache_hooks[] __ro_after_init = { LSM_HOOK_INIT(inode_alloc_security, digest_cache_inode_alloc_security), LSM_HOOK_INIT(inode_free_security, digest_cache_inode_free_security), LSM_HOOK_INIT(path_truncate, digest_cache_path_truncate), LSM_HOOK_INIT(file_release, digest_cache_file_release), LSM_HOOK_INIT(inode_unlink, digest_cache_inode_unlink), LSM_HOOK_INIT(inode_rename, digest_cache_inode_rename), LSM_HOOK_INIT(inode_post_setxattr, digest_cache_inode_post_setxattr), LSM_HOOK_INIT(inode_post_removexattr, digest_cache_inode_post_removexattr), }; struct lsm_blob_sizes digest_cache_blob_sizes __ro_after_init = { .lbs_inode = sizeof(struct digest_cache_security), .lbs_file = sizeof(struct digest_cache *), }; Sure, there could be a different indexing mechanism, although using the inode security blob seems quite efficient, since resolving the path is sufficient to find a digest cache. Also, registering to inode_alloc/free_security allows the digest_cache LSM to dynamically deallocate data when it is not necessary. In addition to that, there are a number of hooks to determine whether a digest cache should be refreshed or not. In the past, it was part of IMA and known as IMA Digest Lists, and as a separate module, called DIGLIM. Both required explicit loading of the file digests are extract from to the kernel through securityfs. Loading was done by an rpm plugin, invoked when software is installd/removed. That didn't look a good idea. DIGLIM does not know when the system is under memory pressure and when digests can be evicted from memory. All digests needed to be loaded, leading to having a big database. I think this shortcoming has now been effectively solved by attaching the digests to the filesystem. Digests are always there, loadable on demand, unloadable by the system under memory pressure. > I think it's fine if an individual LSM wants to implement a file > digest cache as part of its own functionality, but a generalized file > digest cache seems like something that should be part of the general > kernel, and not implemented as a LSM. If we keep the same design as now, it would be anyway connected to the filesystem, but reusing the LSM infrastructure makes it very easy as I don't require any change anywhere else. Sure, it is not doing access control, but I haven't find another good way to achieve the same. Do you have anything more specific in mind? Thanks Roberto
On Wed, Jun 19, 2024 at 3:59 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > Integrity detection and protection has long been a desirable feature, to > > > reach a large user base and mitigate the risk of flaws in the software > > > and attacks. > > > > > > However, while solutions exist, they struggle to reach the large user > > > base, due to requiring higher than desired constraints on performance, > > > flexibility and configurability, that only security conscious people are > > > willing to accept. > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > additional support for new and existing integrity solutions, to make > > > them faster and easier to deploy. > > > > > > The full documentation with the motivation and the solution details can be > > > found in patch 14. > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > based on the current version of IPE can be provided. > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > work, but historically LSMs have provided some form of access control, > > measurement, or other traditional security service. A digest cache, > > while potentially useful for a variety of security related > > applications, is not a security service by itself, it is simply a file > > digest storage mechanism. > > Uhm, currently the digest_cache LSM is heavily based on the LSM > infrastructure: I understand that, but as I said previously, I don't believe that we want to support a LSM which exists solely to provide a file digest cache. LSMs should be based around the idea of some type of access control, security monitoring, etc. Including a file digest cache in IMA, or implementing it as a standalone piece of kernel functionality, are still options. If you want to pursue this, I would suggest that including the digest cache as part of IMA would be the easier of the two options; if it proves to be generally useful outside of IMA, it can always be abstracted out to a general kernel module/subsystem.
On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote: > On Wed, Jun 19, 2024 at 3:59 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > > On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > Integrity detection and protection has long been a desirable feature, to > > > > reach a large user base and mitigate the risk of flaws in the software > > > > and attacks. > > > > > > > > However, while solutions exist, they struggle to reach the large user > > > > base, due to requiring higher than desired constraints on performance, > > > > flexibility and configurability, that only security conscious people are > > > > willing to accept. > > > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > > additional support for new and existing integrity solutions, to make > > > > them faster and easier to deploy. > > > > > > > > The full documentation with the motivation and the solution details can be > > > > found in patch 14. > > > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > > based on the current version of IPE can be provided. > > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > > work, but historically LSMs have provided some form of access control, > > > measurement, or other traditional security service. A digest cache, > > > while potentially useful for a variety of security related > > > applications, is not a security service by itself, it is simply a file > > > digest storage mechanism. > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM > > infrastructure: > > I understand that, but as I said previously, I don't believe that we > want to support a LSM which exists solely to provide a file digest > cache. LSMs should be based around the idea of some type of access > control, security monitoring, etc. > > Including a file digest cache in IMA, or implementing it as a > standalone piece of kernel functionality, are still options. If you > want to pursue this, I would suggest that including the digest cache > as part of IMA would be the easier of the two options; if it proves to > be generally useful outside of IMA, it can always be abstracted out to > a general kernel module/subsystem. Ok. I thought about IPE and eBPF as potential users. But if you think that adding as part of IMA would be easier, I could try to pursue that. Thanks Roberto
On Wed, Jun 19, 2024 at 11:55 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote: > > On Wed, Jun 19, 2024 at 3:59 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > > > On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > Integrity detection and protection has long been a desirable feature, to > > > > > reach a large user base and mitigate the risk of flaws in the software > > > > > and attacks. > > > > > > > > > > However, while solutions exist, they struggle to reach the large user > > > > > base, due to requiring higher than desired constraints on performance, > > > > > flexibility and configurability, that only security conscious people are > > > > > willing to accept. > > > > > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > > > additional support for new and existing integrity solutions, to make > > > > > them faster and easier to deploy. > > > > > > > > > > The full documentation with the motivation and the solution details can be > > > > > found in patch 14. > > > > > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > > > based on the current version of IPE can be provided. > > > > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > > > work, but historically LSMs have provided some form of access control, > > > > measurement, or other traditional security service. A digest cache, > > > > while potentially useful for a variety of security related > > > > applications, is not a security service by itself, it is simply a file > > > > digest storage mechanism. > > > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM > > > infrastructure: > > > > I understand that, but as I said previously, I don't believe that we > > want to support a LSM which exists solely to provide a file digest > > cache. LSMs should be based around the idea of some type of access > > control, security monitoring, etc. > > > > Including a file digest cache in IMA, or implementing it as a > > standalone piece of kernel functionality, are still options. If you > > want to pursue this, I would suggest that including the digest cache > > as part of IMA would be the easier of the two options; if it proves to > > be generally useful outside of IMA, it can always be abstracted out to > > a general kernel module/subsystem. > > Ok. I thought about IPE and eBPF as potential users. But if you think > that adding as part of IMA would be easier, I could try to pursue that. It isn't clear to me how this would interact with IPE and/or eBPF, but if you believe there is value there I would encourage you to work with those subsystem maintainers. If the consensus is that a general file digest cache is useful then you should pursue the digest cache as a kernel subsystem, just not a LSM.
On Wed, 2024-06-19 at 12:34 -0400, Paul Moore wrote: > On Wed, Jun 19, 2024 at 11:55 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote: > > > On Wed, Jun 19, 2024 at 3:59 AM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > > > > On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > > > Integrity detection and protection has long been a desirable feature, to > > > > > > reach a large user base and mitigate the risk of flaws in the software > > > > > > and attacks. > > > > > > > > > > > > However, while solutions exist, they struggle to reach the large user > > > > > > base, due to requiring higher than desired constraints on performance, > > > > > > flexibility and configurability, that only security conscious people are > > > > > > willing to accept. > > > > > > > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > > > > additional support for new and existing integrity solutions, to make > > > > > > them faster and easier to deploy. > > > > > > > > > > > > The full documentation with the motivation and the solution details can be > > > > > > found in patch 14. > > > > > > > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > > > > based on the current version of IPE can be provided. > > > > > > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > > > > work, but historically LSMs have provided some form of access control, > > > > > measurement, or other traditional security service. A digest cache, > > > > > while potentially useful for a variety of security related > > > > > applications, is not a security service by itself, it is simply a file > > > > > digest storage mechanism. > > > > > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM > > > > infrastructure: > > > > > > I understand that, but as I said previously, I don't believe that we > > > want to support a LSM which exists solely to provide a file digest > > > cache. LSMs should be based around the idea of some type of access > > > control, security monitoring, etc. > > > > > > Including a file digest cache in IMA, or implementing it as a > > > standalone piece of kernel functionality, are still options. If you > > > want to pursue this, I would suggest that including the digest cache > > > as part of IMA would be the easier of the two options; if it proves to > > > be generally useful outside of IMA, it can always be abstracted out to > > > a general kernel module/subsystem. > > > > Ok. I thought about IPE and eBPF as potential users. But if you think > > that adding as part of IMA would be easier, I could try to pursue that. > > It isn't clear to me how this would interact with IPE and/or eBPF, but > if you believe there is value there I would encourage you to work with > those subsystem maintainers. If the consensus is that a general file > digest cache is useful then you should pursue the digest cache as a > kernel subsystem, just not a LSM. Making it a kernel subsystem would likely mean replicating what the LSM infrastructure is doing, inode (security) blob and being notified about file/directory changes. I guess I will go for the IMA route... Roberto
On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > Making it a kernel subsystem would likely mean replicating what the LSM > infrastructure is doing, inode (security) blob and being notified about > file/directory changes. Just because the LSM framework can be used for something, perhaps it even makes the implementation easier, it doesn't mean the framework should be used for everything.
On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > infrastructure is doing, inode (security) blob and being notified about > > file/directory changes. > > Just because the LSM framework can be used for something, perhaps it > even makes the implementation easier, it doesn't mean the framework > should be used for everything. It is supporting 3 LSMs: IMA, IPE and BPF LSM. That makes it a clear target for the security subsystem, and as you suggested to start for IMA, if other kernel subsystems require them, we can make it as an independent subsystem. Starting from IMA means that we are mixing two different things in the inode security blob, and I'm not sure that it is more straightforward than making the digest_cache LSM require the space it needs and be notified about security events. Thanks Roberto
On Thu, 2024-06-20 at 11:12 +0200, Roberto Sassu wrote: > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > infrastructure is doing, inode (security) blob and being notified about > > > file/directory changes. > > > > Just because the LSM framework can be used for something, perhaps it > > even makes the implementation easier, it doesn't mean the framework > > should be used for everything. > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > That makes it a clear target for the security subsystem, and as you > suggested to start for IMA, if other kernel subsystems require them, we If other kernel subsystems require the same functionality, Roberto > can make it as an independent subsystem. > > Starting from IMA means that we are mixing two different things in the > inode security blob, and I'm not sure that it is more straightforward > than making the digest_cache LSM require the space it needs and be > notified about security events. > > Thanks > > Roberto >
On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > infrastructure is doing, inode (security) blob and being notified about > > > file/directory changes. > > > > Just because the LSM framework can be used for something, perhaps it > > even makes the implementation easier, it doesn't mean the framework > > should be used for everything. > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > That makes it a clear target for the security subsystem, and as you > suggested to start for IMA, if other kernel subsystems require them, we > can make it as an independent subsystem. Have you discussed the file digest cache functionality with either the IPE or BPF LSM maintainers? While digest_cache may support these LSMs, I don't recall seeing any comments from the other LSM developers; if you are going to advocate for this as something outside of IMA, it would be good to see a show of support for the other LSMs.
On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > infrastructure is doing, inode (security) blob and being notified about > > > > file/directory changes. > > > > > > Just because the LSM framework can be used for something, perhaps it > > > even makes the implementation easier, it doesn't mean the framework > > > should be used for everything. > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > That makes it a clear target for the security subsystem, and as you > > suggested to start for IMA, if other kernel subsystems require them, we > > can make it as an independent subsystem. > > Have you discussed the file digest cache functionality with either the > IPE or BPF LSM maintainers? While digest_cache may support these Well, yes. I was in a discussion since long time ago with Deven and Fan. The digest_cache LSM is listed in the Use Case section of the IPE cover letter: https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ I also developed an IPE module back in the DIGLIM days: https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ As for eBPF, I just need to make the digest_cache LSM API callable by eBPF programs, very likely not requiring any change on the eBPF infrastructure itself. As an example of the modification needed, you could have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/bpf_trace.c?h=v6.10-rc4#n1381 Once the digest_cache LSM API is exposed in eBPF, you could write a simple file integrity check (taken from my DIGLIM eBPF), not tested: SEC("lsm.s/bprm_creds_for_exec") int BPF_PROG(exec, struct linux_binprm *bprm) { u8 digest[MAX_DIGEST_SIZE] = { 0 }; digest_cache_found_t found; struct digest_cache; int algo; algo = bpf_ima_file_hash(bprm->file, digest, sizeof(digest)); if (algo < 0) return -EPERM; digest_cache = bpf_digest_cache_get(bprm->file->f_path.dentry); if (!digest_cache) return -EPERM; found = bpf_digest_cache_lookup(bprm->file->f_path.dentry, digest_cache, digest, algo); bpf_digest_cache_put(digest_cache); return found ? 0 : -EPERM; } Roberto > LSMs, I don't recall seeing any comments from the other LSM > developers; if you are going to advocate for this as something outside > of IMA, it would be good to see a show of support for the other LSMs. >
On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > file/directory changes. > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > even makes the implementation easier, it doesn't mean the framework > > > > should be used for everything. > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > That makes it a clear target for the security subsystem, and as you > > > suggested to start for IMA, if other kernel subsystems require them, we > > > can make it as an independent subsystem. > > > > Have you discussed the file digest cache functionality with either the > > IPE or BPF LSM maintainers? While digest_cache may support these > > Well, yes. I was in a discussion since long time ago with Deven and > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > cover letter: > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ I would hope to see more than one sentence casually mentioning that there might be some integration in the future. > I also developed an IPE module back in the DIGLIM days: > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ That looks like more of an fs-verity integration to me. Yes, of course there would be IPE changes to accept a signature/digest from a digest cache, but that should be minor. > As for eBPF, I just need to make the digest_cache LSM API callable by > eBPF programs, very likely not requiring any change on the eBPF > infrastructure itself. That's great, but it would be good to hear from KP and any other BPF LSM devs that this would be desirable. I still believe that this is something that should live as a service outside of the LSM.
On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > file/directory changes. > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > should be used for everything. > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > can make it as an independent subsystem. > > > > > > Have you discussed the file digest cache functionality with either the > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > Well, yes. I was in a discussion since long time ago with Deven and > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > cover letter: > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ > > I would hope to see more than one sentence casually mentioning that > there might be some integration in the future. Sure, I can work more with Fan to do a proper integration. > > I also developed an IPE module back in the DIGLIM days: > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ > > That looks like more of an fs-verity integration to me. Yes, of > course there would be IPE changes to accept a signature/digest from a > digest cache, but that should be minor. True, but IPE will also benefit from not needing to specify every digest in the policy. Also, the design choice of attaching the digest cache to the inode helps LSMs like IPE that don't have a per inode cache on their own. Sure, IPE would have to do a digest lookup every time, but at least on an already populated hash table. > > As for eBPF, I just need to make the digest_cache LSM API callable by > > eBPF programs, very likely not requiring any change on the eBPF > > infrastructure itself. > > That's great, but it would be good to hear from KP and any other BPF > LSM devs that this would be desirable. Yes, I would also like to know their opinion. They already support getting a file digest from IMA. Adding support for the digest_cache LSM is a nice complement, to make security decisions based on an authenticated source of reference digests (signature verification was not shown in the example). > I still believe that this is something that should live as a service > outside of the LSM. It will not cost me too much to plug to IMA rather than the LSM infrastructure, but I would rather prefer the second. I'm not aware of equivalent facilities in the kernel that would make the digest_cache LSM work in the same way, so making it as an independent kernel subsystem seems a too big jump for me. Roberto
On Wed, Jun 19, 2024 at 06:37:49PM +0200, Roberto Sassu wrote: Good morning Roberto, I hope your week is going well, greetings to everyone copied else as well. > On Wed, 2024-06-19 at 12:34 -0400, Paul Moore wrote: > > On Wed, Jun 19, 2024 at 11:55???AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote: > > > > On Wed, Jun 19, 2024 at 3:59???AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > > > > > On Mon, Apr 15, 2024 at 10:25???AM Roberto Sassu > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > > > > > Integrity detection and protection has long been a desirable feature, to > > > > > > > reach a large user base and mitigate the risk of flaws in the software > > > > > > > and attacks. > > > > > > > > > > > > > > However, while solutions exist, they struggle to reach the large user > > > > > > > base, due to requiring higher than desired constraints on performance, > > > > > > > flexibility and configurability, that only security conscious people are > > > > > > > willing to accept. > > > > > > > > > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > > > > > additional support for new and existing integrity solutions, to make > > > > > > > them faster and easier to deploy. > > > > > > > > > > > > > > The full documentation with the motivation and the solution details can be > > > > > > > found in patch 14. > > > > > > > > > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > > > > > based on the current version of IPE can be provided. > > > > > > > > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > > > > > work, but historically LSMs have provided some form of access control, > > > > > > measurement, or other traditional security service. A digest cache, > > > > > > while potentially useful for a variety of security related > > > > > > applications, is not a security service by itself, it is simply a file > > > > > > digest storage mechanism. > > > > > > > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM > > > > > infrastructure: > > > > > > > > I understand that, but as I said previously, I don't believe that we > > > > want to support a LSM which exists solely to provide a file digest > > > > cache. LSMs should be based around the idea of some type of access > > > > control, security monitoring, etc. > > > > > > > > Including a file digest cache in IMA, or implementing it as a > > > > standalone piece of kernel functionality, are still options. If you > > > > want to pursue this, I would suggest that including the digest cache > > > > as part of IMA would be the easier of the two options; if it proves to > > > > be generally useful outside of IMA, it can always be abstracted out to > > > > a general kernel module/subsystem. > > > > > > Ok. I thought about IPE and eBPF as potential users. But if you think > > > that adding as part of IMA would be easier, I could try to pursue that. > > > > It isn't clear to me how this would interact with IPE and/or eBPF, but > > if you believe there is value there I would encourage you to work with > > those subsystem maintainers. If the consensus is that a general file > > digest cache is useful then you should pursue the digest cache as a > > kernel subsystem, just not a LSM. > Making it a kernel subsystem would likely mean replicating what the LSM > infrastructure is doing, inode (security) blob and being notified about > file/directory changes. > > I guess I will go for the IMA route... This thread brings up an issue that we have been thinking about but has been on the back burner. Roberto, I'm assuming you have seen our TSEM submissions go by. Our V4 release will be immediately after the Fourth of July holiday week here in the states. Since TSEM implements a generic security modeling framework for the kernel, it ends up implementing a superset of IMA functionality. That required us to implement our own file digest generation and cacheing infrastructure. Given the trajectory that things are on with respect to security, there is only going to be more demand for file digests and their associated cacheing. Doesn't seem like it makes a lot of sense to have multiple teams replicating what is largely the same functionality. If your group would have interest, we would certainly be willing to entertain conversations on how we could collaborate to brew up something that would be of mutual benefit to everyone who has a need for this type of infrastructure. As you noted, consumers of the BPF LSM would also be a clear candidate for generic infrastructure. One of the issues blocking a BPF based integrity implementation is that BPF itself is not going to be able generate digests on its own. So it would seem to make sense to have whatever gets built have a kfunc accessible API. Plenty of other additional warts on that front as well but getting access to digests is the necessary starting point. Given what we have seen with IMA's challenge with respect to overlayfs issues and file versioning issues in general, it would seem to be of profit to have all these issues addressed uniformally and in one place. Since virtually everything that is accessing this infrastructure is going to be an LSM, we would envision API's out of a common infrastructure, invoked by the event handlers of the various LSM's interested in integrity information, driving the cache generation and maintenance. That would seem to have all of the benefits of being implemented by the LSM infrastructure without necessarily being an 'LSM' in and of itself. We assume that everyone would want to maintain the O(1) lookup characteristics of what the LSM inode blob mechanism provides. We would presume that a common cacheing architecture would return a pointer to the structure that the digest cache maintains describing the various digests associated with the contents of a file, as there will be a need for multiple digest support, when an LSM hands the cache an inode referencing a file. An LSM could then place that pointer in its own inode blob for future reference. Either that, probably better, stick a pointer into the inode structure itself that references it's digest cache object and it would get populated by the first event that opens the associated file. > Roberto So an open invitation to anyone that would want to discuss requirements around a common implementation. Have a good weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project
On Thu, Jun 20, 2024 at 12:31 PM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > > file/directory changes. > > > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > > should be used for everything. > > > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > > can make it as an independent subsystem. > > > > > > > > Have you discussed the file digest cache functionality with either the > > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > > > Well, yes. I was in a discussion since long time ago with Deven and > > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > > cover letter: > > > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ > > > > I would hope to see more than one sentence casually mentioning that > > there might be some integration in the future. > > Sure, I can work more with Fan to do a proper integration. That seems like a good pre-requisite for turning digest_cache into a general purpose subsystem. > > > I also developed an IPE module back in the DIGLIM days: > > > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ > > > > That looks like more of an fs-verity integration to me. Yes, of > > course there would be IPE changes to accept a signature/digest from a > > digest cache, but that should be minor. > > True, but IPE will also benefit from not needing to specify every > digest in the policy. Sure, but that isn't really that important from a code integration perspective, that's an admin policy issue. I expect there would be much more integration work with fs-verity than with IPE, and I think the fs-verity related work might be a challenge. > Also, the design choice of attaching the digest cache to the inode > helps LSMs like IPE that don't have a per inode cache on their own. > Sure, IPE would have to do a digest lookup every time, but at least on > an already populated hash table. Just because you need to attach some state to an inode does not mean a file digest cache must be a LSM. It could be integrated into the VFS or it could be a separate subsystem; either way it could provide an API (either through well defined data structures or functions) that could be used by various LSMs and filesystems that provide integrity protection.
On Thu, 2024-06-20 at 11:32 -0500, Dr. Greg wrote: > On Wed, Jun 19, 2024 at 06:37:49PM +0200, Roberto Sassu wrote: > > Good morning Roberto, I hope your week is going well, greetings to > everyone copied else as well. > > > On Wed, 2024-06-19 at 12:34 -0400, Paul Moore wrote: > > > On Wed, Jun 19, 2024 at 11:55???AM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote: > > > > > On Wed, Jun 19, 2024 at 3:59???AM Roberto Sassu > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote: > > > > > > > On Mon, Apr 15, 2024 at 10:25???AM Roberto Sassu > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > > > > > > > > > Integrity detection and protection has long been a desirable feature, to > > > > > > > > reach a large user base and mitigate the risk of flaws in the software > > > > > > > > and attacks. > > > > > > > > > > > > > > > > However, while solutions exist, they struggle to reach the large user > > > > > > > > base, due to requiring higher than desired constraints on performance, > > > > > > > > flexibility and configurability, that only security conscious people are > > > > > > > > willing to accept. > > > > > > > > > > > > > > > > This is where the new digest_cache LSM comes into play, it offers > > > > > > > > additional support for new and existing integrity solutions, to make > > > > > > > > them faster and easier to deploy. > > > > > > > > > > > > > > > > The full documentation with the motivation and the solution details can be > > > > > > > > found in patch 14. > > > > > > > > > > > > > > > > The IMA integration patch set will be introduced separately. Also a PoC > > > > > > > > based on the current version of IPE can be provided. > > > > > > > > > > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would > > > > > > > work, but historically LSMs have provided some form of access control, > > > > > > > measurement, or other traditional security service. A digest cache, > > > > > > > while potentially useful for a variety of security related > > > > > > > applications, is not a security service by itself, it is simply a file > > > > > > > digest storage mechanism. > > > > > > > > > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM > > > > > > infrastructure: > > > > > > > > > > I understand that, but as I said previously, I don't believe that we > > > > > want to support a LSM which exists solely to provide a file digest > > > > > cache. LSMs should be based around the idea of some type of access > > > > > control, security monitoring, etc. > > > > > > > > > > Including a file digest cache in IMA, or implementing it as a > > > > > standalone piece of kernel functionality, are still options. If you > > > > > want to pursue this, I would suggest that including the digest cache > > > > > as part of IMA would be the easier of the two options; if it proves to > > > > > be generally useful outside of IMA, it can always be abstracted out to > > > > > a general kernel module/subsystem. > > > > > > > > Ok. I thought about IPE and eBPF as potential users. But if you think > > > > that adding as part of IMA would be easier, I could try to pursue that. > > > > > > It isn't clear to me how this would interact with IPE and/or eBPF, but > > > if you believe there is value there I would encourage you to work with > > > those subsystem maintainers. If the consensus is that a general file > > > digest cache is useful then you should pursue the digest cache as a > > > kernel subsystem, just not a LSM. > > > Making it a kernel subsystem would likely mean replicating what the LSM > > infrastructure is doing, inode (security) blob and being notified about > > file/directory changes. > > > > I guess I will go for the IMA route... > > This thread brings up an issue that we have been thinking about but > has been on the back burner. > > Roberto, I'm assuming you have seen our TSEM submissions go by. Our > V4 release will be immediately after the Fourth of July holiday week > here in the states. > > Since TSEM implements a generic security modeling framework for the > kernel, it ends up implementing a superset of IMA functionality. That > required us to implement our own file digest generation and cacheing > infrastructure. > > Given the trajectory that things are on with respect to security, > there is only going to be more demand for file digests and their > associated cacheing. Doesn't seem like it makes a lot of sense to > have multiple teams replicating what is largely the same > functionality. > > If your group would have interest, we would certainly be willing to > entertain conversations on how we could collaborate to brew up > something that would be of mutual benefit to everyone who has a need > for this type of infrastructure. Hi Greg sure, I would be happy to give you more details on how the digest_cache LSM works and how you could make use of it. > As you noted, consumers of the BPF LSM would also be a clear candidate > for generic infrastructure. One of the issues blocking a BPF based > integrity implementation is that BPF itself is not going to be able > generate digests on its own. So it would seem to make sense to have > whatever gets built have a kfunc accessible API. Plenty of other > additional warts on that front as well but getting access to digests > is the necessary starting point. Yes, adding a few kfuncs is what I had in mind. > Given what we have seen with IMA's challenge with respect to overlayfs > issues and file versioning issues in general, it would seem to be of > profit to have all these issues addressed uniformally and in one > place. > > Since virtually everything that is accessing this infrastructure is > going to be an LSM, we would envision API's out of a common > infrastructure, invoked by the event handlers of the various LSM's > interested in integrity information, driving the cache generation and > maintenance. That would seem to have all of the benefits of being > implemented by the LSM infrastructure without necessarily being an > 'LSM' in and of itself. Yes, this is exactly how it works. There is a generic API for users to get a digest cache and query it. The LSM infrastructure is needed for attaching data to an inode and for being notified of file backend changes. The digest_cache LSM makes it transparent for its users the process of retrieving the reference digest for a given file whose integrity should be checked, and allows those users to simply query the calculated file digest. > We assume that everyone would want to maintain the O(1) lookup > characteristics of what the LSM inode blob mechanism provides. We > would presume that a common cacheing architecture would return a > pointer to the structure that the digest cache maintains describing > the various digests associated with the contents of a file, as there > will be a need for multiple digest support, when an LSM hands the > cache an inode referencing a file. An LSM could then place that > pointer in its own inode blob for future reference. That was what initially thought and implemented. But I realized that pinning the digest cache to other inode security blobs makes it more difficult to free the digest cache (when its reference count goes to zero). I opted instead for releasing a digest cache when not in use, and for introducing a notification mechanism, similar to what LSMs use to notify about policy changes, which reports when the file backend changes, so that LSMs can invalidate their decision based on the affected digest cache. This mechanism is already working in IMA: https://lore.kernel.org/linux-integrity/20240415161044.2572438-10-roberto.sassu@huaweicloud.com/ > Either that, probably better, stick a pointer into the inode structure > itself that references it's digest cache object and it would get > populated by the first event that opens the associated file. Yes, the digest cache pointer is stored both in the inode that should be verified with the digest cache, and in the inode the digest cache was created from. The first reference avoids retrieving the link file- package every time a digest cache is requested for that inode. > > Roberto > > So an open invitation to anyone that would want to discuss > requirements around a common implementation. > > Have a good weekend. Thanks, the same to you. Roberto > As always, > Dr. Greg > > The Quixote Project - Flailing at the Travails of Cybersecurity > https://github.com/Quixote-Project
On Thu, 2024-06-20 at 12:51 -0400, Paul Moore wrote: > On Thu, Jun 20, 2024 at 12:31 PM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > > > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > > > file/directory changes. > > > > > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > > > should be used for everything. > > > > > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > > > can make it as an independent subsystem. > > > > > > > > > > Have you discussed the file digest cache functionality with either the > > > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > > > > > Well, yes. I was in a discussion since long time ago with Deven and > > > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > > > cover letter: > > > > > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ > > > > > > I would hope to see more than one sentence casually mentioning that > > > there might be some integration in the future. > > > > Sure, I can work more with Fan to do a proper integration. > > That seems like a good pre-requisite for turning digest_cache into a > general purpose subsystem. > > > > > I also developed an IPE module back in the DIGLIM days: > > > > > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ > > > > > > That looks like more of an fs-verity integration to me. Yes, of > > > course there would be IPE changes to accept a signature/digest from a > > > digest cache, but that should be minor. > > > > True, but IPE will also benefit from not needing to specify every > > digest in the policy. > > Sure, but that isn't really that important from a code integration > perspective, that's an admin policy issue. I expect there would be > much more integration work with fs-verity than with IPE, and I think > the fs-verity related work might be a challenge. Uhm, not sure what you mean, but I don't plan to touch fsverity. There was already work to get the fsverity digest. All I would need to do from my side is to request a digest cache for the inode being verified by IPE and to query the fsverity digest. Of course IPE should also capture kernel reads and verify the file containing the reference digests, used to build the digest cache. > > Also, the design choice of attaching the digest cache to the inode > > helps LSMs like IPE that don't have a per inode cache on their own. > > Sure, IPE would have to do a digest lookup every time, but at least on > > an already populated hash table. > > Just because you need to attach some state to an inode does not mean a > file digest cache must be a LSM. It could be integrated into the VFS > or it could be a separate subsystem; either way it could provide an > API (either through well defined data structures or functions) that > could be used by various LSMs and filesystems that provide integrity > protection. Given that IMA solved the same problem after 15 years, when it became an LSM, I'm not super optimistic on that. But if VFS people or other subsystem maintainers would be open for such alternative, I can give it a try. Roberto
On Thu, Jun 20, 2024 at 1:06 PM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Thu, 2024-06-20 at 12:51 -0400, Paul Moore wrote: > > On Thu, Jun 20, 2024 at 12:31 PM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > > > > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > > > > file/directory changes. > > > > > > > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > > > > should be used for everything. > > > > > > > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > > > > can make it as an independent subsystem. > > > > > > > > > > > > Have you discussed the file digest cache functionality with either the > > > > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > > > > > > > Well, yes. I was in a discussion since long time ago with Deven and > > > > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > > > > cover letter: > > > > > > > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ > > > > > > > > I would hope to see more than one sentence casually mentioning that > > > > there might be some integration in the future. > > > > > > Sure, I can work more with Fan to do a proper integration. > > > > That seems like a good pre-requisite for turning digest_cache into a > > general purpose subsystem. > > > > > > > I also developed an IPE module back in the DIGLIM days: > > > > > > > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ > > > > > > > > That looks like more of an fs-verity integration to me. Yes, of > > > > course there would be IPE changes to accept a signature/digest from a > > > > digest cache, but that should be minor. > > > > > > True, but IPE will also benefit from not needing to specify every > > > digest in the policy. > > > > Sure, but that isn't really that important from a code integration > > perspective, that's an admin policy issue. I expect there would be > > much more integration work with fs-verity than with IPE, and I think > > the fs-verity related work might be a challenge. > > Uhm, not sure what you mean, but I don't plan to touch fsverity. There > was already work to get the fsverity digest. All I would need to do > from my side is to request a digest cache for the inode being verified > by IPE and to query the fsverity digest. So your proposed file digest cache wouldn't be used as a replacement for the fs-verity digest? Hmm. I'll leave this up to you and Fan (current IPE maintainer), but I'm not sure how much value this would have for IPE, especially since I believe IPE's fs-verity support is mostly around fs-verity signatures. > Of course IPE should also capture kernel reads and verify the file > containing the reference digests, used to build the digest cache. > > > > Also, the design choice of attaching the digest cache to the inode > > > helps LSMs like IPE that don't have a per inode cache on their own. > > > Sure, IPE would have to do a digest lookup every time, but at least on > > > an already populated hash table. > > > > Just because you need to attach some state to an inode does not mean a > > file digest cache must be a LSM. It could be integrated into the VFS > > or it could be a separate subsystem; either way it could provide an > > API (either through well defined data structures or functions) that > > could be used by various LSMs and filesystems that provide integrity > > protection. > > Given that IMA solved the same problem after 15 years, when it became > an LSM, I'm not super optimistic on that. But if VFS people or other > subsystem maintainers would be open for such alternative, I can give it > a try. I think you should, because I'm not currently supportive of digest_cache as a standalone LSM.
On Thu, 2024-06-20 at 13:13 -0400, Paul Moore wrote: > On Thu, Jun 20, 2024 at 1:06 PM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > On Thu, 2024-06-20 at 12:51 -0400, Paul Moore wrote: > > > On Thu, Jun 20, 2024 at 12:31 PM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > > > > > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > > > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > > > > > file/directory changes. > > > > > > > > > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > > > > > should be used for everything. > > > > > > > > > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > > > > > can make it as an independent subsystem. > > > > > > > > > > > > > > Have you discussed the file digest cache functionality with either the > > > > > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > > > > > > > > > Well, yes. I was in a discussion since long time ago with Deven and > > > > > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > > > > > cover letter: > > > > > > > > > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/ > > > > > > > > > > I would hope to see more than one sentence casually mentioning that > > > > > there might be some integration in the future. > > > > > > > > Sure, I can work more with Fan to do a proper integration. > > > > > > That seems like a good pre-requisite for turning digest_cache into a > > > general purpose subsystem. > > > > > > > > > I also developed an IPE module back in the DIGLIM days: > > > > > > > > > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/ > > > > > > > > > > That looks like more of an fs-verity integration to me. Yes, of > > > > > course there would be IPE changes to accept a signature/digest from a > > > > > digest cache, but that should be minor. > > > > > > > > True, but IPE will also benefit from not needing to specify every > > > > digest in the policy. > > > > > > Sure, but that isn't really that important from a code integration > > > perspective, that's an admin policy issue. I expect there would be > > > much more integration work with fs-verity than with IPE, and I think > > > the fs-verity related work might be a challenge. > > > > Uhm, not sure what you mean, but I don't plan to touch fsverity. There > > was already work to get the fsverity digest. All I would need to do > > from my side is to request a digest cache for the inode being verified > > by IPE and to query the fsverity digest. > > So your proposed file digest cache wouldn't be used as a replacement > for the fs-verity digest? Hmm. I'll leave this up to you and Fan > (current IPE maintainer), but I'm not sure how much value this would > have for IPE, especially since I believe IPE's fs-verity support is > mostly around fs-verity signatures. The digest_cache (LSM) would store fsverity digests in the hash table. At the moment, there is no available source for those, but they could be included in RPM headers like regular digests. IPE will compare the digest from fsverity with the digest queried on the digest cache. Roberto > > Of course IPE should also capture kernel reads and verify the file > > containing the reference digests, used to build the digest cache. > > > > > > Also, the design choice of attaching the digest cache to the inode > > > > helps LSMs like IPE that don't have a per inode cache on their own. > > > > Sure, IPE would have to do a digest lookup every time, but at least on > > > > an already populated hash table. > > > > > > Just because you need to attach some state to an inode does not mean a > > > file digest cache must be a LSM. It could be integrated into the VFS > > > or it could be a separate subsystem; either way it could provide an > > > API (either through well defined data structures or functions) that > > > could be used by various LSMs and filesystems that provide integrity > > > protection. > > > > Given that IMA solved the same problem after 15 years, when it became > > an LSM, I'm not super optimistic on that. But if VFS people or other > > subsystem maintainers would be open for such alternative, I can give it > > a try. > > I think you should, because I'm not currently supportive of > digest_cache as a standalone LSM. >
From: Roberto Sassu <roberto.sassu@huawei.com> Integrity detection and protection has long been a desirable feature, to reach a large user base and mitigate the risk of flaws in the software and attacks. However, while solutions exist, they struggle to reach the large user base, due to requiring higher than desired constraints on performance, flexibility and configurability, that only security conscious people are willing to accept. This is where the new digest_cache LSM comes into play, it offers additional support for new and existing integrity solutions, to make them faster and easier to deploy. The full documentation with the motivation and the solution details can be found in patch 14. The IMA integration patch set will be introduced separately. Also a PoC based on the current version of IPE can be provided. v3: - Rewrite documentation, and remove the installation instructions since they are now included in the README of digest-cache-tools - Add digest cache event notifier - Drop digest_cache_was_reset(), and send instead to asynchronous notifications - Fix digest_cache LSM Kconfig style issues (suggested by Randy Dunlap) - Propagate digest cache reset to directory entries - Destroy per directory entry mutex - Introduce RESET_USER bit, to clear the dig_user pointer on set/removexattr - Replace 'file content' with 'file data' (suggested by Mimi) - Introduce per digest cache mutex and replace verif_data_lock spinlock - Track changes of security.digest_list xattr - Stop tracking file_open and use file_release instead also for file writes - Add error messages in digest_cache_create() - Load/unload testing kernel module automatically during execution of test - Add tests for digest cache event notifier - Add test for ftruncate() - Remove DIGEST_CACHE_RESET_PREFETCH_BUF command in test and clear the buffer on read instead v2: - Include the TLV parser in this patch set (from user asymmetric keys and signatures) - Move from IMA and make an independent LSM - Remove IMA-specific stuff from this patch set - Add per algorithm hash table - Expect all digest lists to be in the same directory and allow changing the default directory - Support digest lookup on directories, when there is no security.digest_list xattr - Add seq num to digest list file name, to impose ordering on directory iteration - Add a new data type DIGEST_LIST_ENTRY_DATA for the nested data in the tlv digest list format - Add the concept of verification data attached to digest caches - Add the reset mechanism to track changes on digest lists and directory containing the digest lists - Add kernel selftests v1: - Add documentation in Documentation/security/integrity-digest-cache.rst - Pass the mask of IMA actions to digest_cache_alloc() - Add a reference count to the digest cache - Remove the path parameter from digest_cache_get(), and rely on the reference count to avoid the digest cache disappearing while being used - Rename the dentry_to_check parameter of digest_cache_get() to dentry - Rename digest_cache_get() to digest_cache_new() and add digest_cache_get() to set the digest cache in the iint of the inode for which the digest cache was requested - Add dig_owner and dig_user to the iint, to distinguish from which inode the digest cache was created from, and which is using it; consequently it makes the digest cache usable to measure/appraise other digest caches (support not yet enabled) - Add dig_owner_mutex and dig_user_mutex to serialize accesses to dig_owner and dig_user until they are initialized - Enforce strong synchronization and make the contenders wait until dig_owner and dig_user are assigned to the iint the first time - Move checking IMA actions on the digest list earlier, and fail if no action were performed (digest cache not usable) - Remove digest_cache_put(), not needed anymore with the introduction of the reference count - Fail immediately in digest_cache_lookup() if the digest algorithm is not set in the digest cache - Use 64 bit mask for IMA actions on the digest list instead of 8 bit - Return NULL in the inline version of digest_cache_get() - Use list_add_tail() instead of list_add() in the iterator - Copy the digest list path to a separate buffer in digest_cache_iter_dir() - Use digest list parsers verified with Frama-C - Explicitly disable (for now) the possibility in the IMA policy to use the digest cache to measure/appraise other digest lists - Replace exit(<value>) with return <value> in manage_digest_lists.c Roberto Sassu (14): lib: Add TLV parser security: Introduce the digest_cache LSM digest_cache: Add securityfs interface digest_cache: Add hash tables and operations digest_cache: Populate the digest cache from a digest list digest_cache: Parse tlv digest lists digest_cache: Parse rpm digest lists digest_cache: Add management of verification data digest_cache: Add support for directories digest cache: Prefetch digest lists if requested digest_cache: Reset digest cache on file/directory change digest_cache: Notify digest cache events selftests/digest_cache: Add selftests for digest_cache LSM docs: Add documentation of the digest_cache LSM Documentation/security/digest_cache.rst | 763 ++++++++++++++++ Documentation/security/index.rst | 1 + MAINTAINERS | 16 + include/linux/digest_cache.h | 117 +++ include/linux/kernel_read_file.h | 1 + include/linux/tlv_parser.h | 28 + include/uapi/linux/lsm.h | 1 + include/uapi/linux/tlv_digest_list.h | 72 ++ include/uapi/linux/tlv_parser.h | 59 ++ include/uapi/linux/xattr.h | 6 + lib/Kconfig | 3 + lib/Makefile | 3 + lib/tlv_parser.c | 214 +++++ lib/tlv_parser.h | 17 + security/Kconfig | 11 +- security/Makefile | 1 + security/digest_cache/Kconfig | 33 + security/digest_cache/Makefile | 11 + security/digest_cache/dir.c | 252 ++++++ security/digest_cache/htable.c | 268 ++++++ security/digest_cache/internal.h | 290 +++++++ security/digest_cache/main.c | 570 ++++++++++++ security/digest_cache/modsig.c | 66 ++ security/digest_cache/notifier.c | 135 +++ security/digest_cache/parsers/parsers.h | 15 + security/digest_cache/parsers/rpm.c | 223 +++++ security/digest_cache/parsers/tlv.c | 299 +++++++ security/digest_cache/populate.c | 163 ++++ security/digest_cache/reset.c | 235 +++++ security/digest_cache/secfs.c | 87 ++ security/digest_cache/verif.c | 119 +++ security/security.c | 3 +- tools/testing/selftests/Makefile | 1 + .../testing/selftests/digest_cache/.gitignore | 3 + tools/testing/selftests/digest_cache/Makefile | 24 + .../testing/selftests/digest_cache/all_test.c | 815 ++++++++++++++++++ tools/testing/selftests/digest_cache/common.c | 78 ++ tools/testing/selftests/digest_cache/common.h | 135 +++ .../selftests/digest_cache/common_user.c | 47 + .../selftests/digest_cache/common_user.h | 17 + tools/testing/selftests/digest_cache/config | 1 + .../selftests/digest_cache/generators.c | 248 ++++++ .../selftests/digest_cache/generators.h | 19 + .../selftests/digest_cache/testmod/Makefile | 16 + .../selftests/digest_cache/testmod/kern.c | 564 ++++++++++++ .../selftests/lsm/lsm_list_modules_test.c | 3 + 46 files changed, 6047 insertions(+), 6 deletions(-) create mode 100644 Documentation/security/digest_cache.rst create mode 100644 include/linux/digest_cache.h create mode 100644 include/linux/tlv_parser.h create mode 100644 include/uapi/linux/tlv_digest_list.h create mode 100644 include/uapi/linux/tlv_parser.h create mode 100644 lib/tlv_parser.c create mode 100644 lib/tlv_parser.h create mode 100644 security/digest_cache/Kconfig create mode 100644 security/digest_cache/Makefile create mode 100644 security/digest_cache/dir.c create mode 100644 security/digest_cache/htable.c create mode 100644 security/digest_cache/internal.h create mode 100644 security/digest_cache/main.c create mode 100644 security/digest_cache/modsig.c create mode 100644 security/digest_cache/notifier.c create mode 100644 security/digest_cache/parsers/parsers.h create mode 100644 security/digest_cache/parsers/rpm.c create mode 100644 security/digest_cache/parsers/tlv.c create mode 100644 security/digest_cache/populate.c create mode 100644 security/digest_cache/reset.c create mode 100644 security/digest_cache/secfs.c create mode 100644 security/digest_cache/verif.c create mode 100644 tools/testing/selftests/digest_cache/.gitignore create mode 100644 tools/testing/selftests/digest_cache/Makefile create mode 100644 tools/testing/selftests/digest_cache/all_test.c create mode 100644 tools/testing/selftests/digest_cache/common.c create mode 100644 tools/testing/selftests/digest_cache/common.h create mode 100644 tools/testing/selftests/digest_cache/common_user.c create mode 100644 tools/testing/selftests/digest_cache/common_user.h create mode 100644 tools/testing/selftests/digest_cache/config create mode 100644 tools/testing/selftests/digest_cache/generators.c create mode 100644 tools/testing/selftests/digest_cache/generators.h create mode 100644 tools/testing/selftests/digest_cache/testmod/Makefile create mode 100644 tools/testing/selftests/digest_cache/testmod/kern.c