[PATCH 0/3] integrity - Kernel

This is a discussion on [PATCH 0/3] integrity - Kernel ; On Fri, 2008-10-31 at 09:40 -0700, Dave Hansen wrote: > On Mon, 2008-10-13 at 13:17 -0400, Mimi Zohar wrote: > > Concern was raised on the lkml mailing list, about adding i_integrity > > to the inode structure. This patch ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: [PATCH 0/3] integrity

  1. Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

    On Fri, 2008-10-31 at 09:40 -0700, Dave Hansen wrote:
    > On Mon, 2008-10-13 at 13:17 -0400, Mimi Zohar wrote:
    > > Concern was raised on the lkml mailing list, about adding i_integrity
    > > to the inode structure. This patch adds a comment clarifying that
    > > i_integrity is only included in the inode if INTEGRITY is configured.

    >
    > Mimi, it is nice that you made this a config option. That definitely
    > helps the embedded folks and those compiling their own kernels. But, it
    > doesn't really help those who run distros.
    >
    > The distributions basically ship one kernel for everybody, and it has to
    > have CONFIG_KITCHEN_SINK=y in order to support everyone's individual
    > users. Although you provided a config option, in practice, this always
    > bloats distro kernels which are the vast majority of users.


    Thank you for giving a more fuller explanation as to why extending the
    inode is such an issue.

    > Is this even useful for filesystems like proc or sysfs? Should we bloat
    > those inodes for a feature which might not possibly apply there?


    Currently, we're not measuring proc or sysfs files.

    Mimi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

    On Fri, 2008-10-31 at 09:51 -0700, Dave Hansen wrote:
    > On Tue, 2008-10-14 at 09:28 -0400, Christoph Hellwig wrote:
    > > > --- a/include/linux/fs.h
    > > > +++ b/include/linux/fs.h
    > > > @@ -683,6 +683,9 @@ struct inode {
    > > > #ifdef CONFIG_SECURITY
    > > > void *i_security;
    > > > #endif
    > > > +#ifdef CONFIG_INTEGRITY
    > > > + void *i_integrity;
    > > > +#endif

    > >
    > > Sorry, but as said before bloating the inode for this is not an option.
    > > Please use something like the MRU approach I suggested in the last
    > > review round.


    I am working on using a radix tree to store the i_integrity information,
    as Christoph suggested. Initially the measurements were awful, but after
    fixing the locking and removing an unnecessary sychronize_rcu, I'm not
    seeing a major performance hit.

    > Why don't we just have a 'void *i_lots_of_bloat field', and let the
    > security folks stick whatever they want in it? They can trade their
    > i_security space for a new one. I know we want to conceptually separate
    > security from integrity, so let's separate it:
    >
    > struct i_bloat_inodes {
    > #ifdef CONFIG_SECURITY
    > void *i_security;
    > #endif
    > #ifdef CONFIG_INTEGRITY
    > void *i_integrity;
    > #endif
    > };


    I'm not sure that the LSM people would be too happy. If using the radix
    tree does not pan out, then we will have to look into this option.

    > By the way, if there's no TPM hardware, why would I want i_integrity
    > anyway?


    > -- Dave


    The integrity framework is for collecting, appraising, and storing
    integrity information. Integrity measurements today are mainly file
    measurements, but the framework allows for other types of integrity
    measurements. Some types of integrity measurements, might only require
    collecting and appraising, but not storing, so a TPM would not be
    required.

    Mimi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

    On Fri, 2008-10-31 at 15:35 -0400, Mimi Zohar wrote:
    > > Is this even useful for filesystems like proc or sysfs? Should we bloat
    > > those inodes for a feature which might not possibly apply there?

    >
    > Currently, we're not measuring proc or sysfs files.


    So, one of the points is that this "bloats" 'struct inode' for at least
    these two filesystems. It has no use there, so it does not help much to
    stick it in a common structure that those use.

    -- Dave

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

    Quoting Dave Hansen (dave@linux.vnet.ibm.com):
    > On Mon, 2008-10-13 at 13:17 -0400, Mimi Zohar wrote:
    > > Concern was raised on the lkml mailing list, about adding i_integrity
    > > to the inode structure. This patch adds a comment clarifying that
    > > i_integrity is only included in the inode if INTEGRITY is configured.

    >
    > Mimi, it is nice that you made this a config option. That definitely
    > helps the embedded folks and those compiling their own kernels. But, it
    > doesn't really help those who run distros.


    Ah, of course, that makes sense - thanks for the reminder. That answers
    my earlier stupid question.

    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2