> > My proposal (basically bsd's implementation) would also require adjusting
> > existing modules.
> >
> Is that the inode->i_security[my_index] way?
Right.
> What about something like
>
> /* manager internal lsm id, allocated on registration */
> typedef uchar lsm_id;
>
> struct sec_blob {
> uchar num_entries;
> lsm_id user1;
> lsm_id user2;
> lsm_id user3;
> void *blob1;
> void *blob2;
> void *blob3;
> };
>
> On alloc, lsm's get to say whether they want to copy the existing value,
> change it, or leave the slot empty. Any accesses need to go through a
> manager function (taking some sort of id), which would be in a position to
> implement copy on write, as well as expanding the blob array should need
> arise.
I was thinking of a simpler approach - when you call mod_reg_security(),
you get back an index, which is your index into the sec_blob array.
That array is now just
struct inode {
- void *i_security;
+ void *i_security[NUM_LSM_MODULES];
}
The first LSM, registered with register_security(), uses index 0 (or
ignores the index).
This way, changes to the rest of the kernel are very minimal. Change
some void * to void *[], and add a compile or boot-time option to set
NUM_LSM_MODULES.
> What are the current usage (alloc & update) patterns for the blobs?
You can't count on alloc and free. For instance, if an LSM was loaded
long after boot, and is asked to look at some inode on its alloc, then
it might want to add security information to that file's parent's inode,
which was alloc'd long ago.
This archive was generated by hypermail 2.1.3 : Wed Jul 07 2004 - 07:36:27 PDT