On Wed, Jul 10, 2024 at 12:41 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 7/10/2024 9:20 AM, Paul Moore wrote:
...
> > However, I have always thought we should add some better
> > structure/typing to these opaque LSM blobs both to get away from the
> > raw pointer math and add a marginal layer of safety. I've envisioned
> > doing something like this:
> >
> > struct lsm_blob_inode {
> > struct selinux_blob_inode selinux;
> > struct smack_blob_inode smack;
> > struct aa_blob_inode apparmor;
> > ...
> > struct rcu_head rcu;
> > }
>
> I have considered doing this as part of the stacking effort for quite
> some time. I've already done it for the lsmblob structure that will replace
> most uses of the u32 secid in the LSM APIs. I am concerned that there would
> be considerable gnashing of teeth over the potential increase in the blob
> sizes for kernels compiled with LSMs that aren't active.
Yes, that's a fair point and something that needs to be considered.
> I have been frantically
> avoiding anything that might slow the stacking effort further. If this would
> help moving this along I'll include it in v40.
No, don't worry about this as part of improving the multi-LSM support,
this is something that can be done independently, if at all.
--
paul-moore.com
