* IMA policy search speedup
@ 2012-09-18 9:44 Kasatkin, Dmitry
2012-09-19 4:21 ` James Morris
0 siblings, 1 reply; 6+ messages in thread
From: Kasatkin, Dmitry @ 2012-09-18 9:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fsdevel, linux-security-module, LKML, Al Viro, Mimi Zohar,
James Morris
Hello Linus,
I have asked this question already 2 times in fsdevel but have not got
any single response.
Certain file system types and partitions will never be measured or
appraised depending on the IMA policy.
For example, pseudo file systems are not measured and appraised.
In upstream IMA implementation policy will be checked again and again
for every inode in the filesystem.
It happens thousands times per second. That is absolute waste of CPU
and may be batter resources.
To overcome such issue I would like to have a flag in super block data structure
which can be set once if IMA does not need to measure anything from a partition.
The flag might be tested by ima hooks to return without doing anything.
I looked to <linux/fs.h> and found that there is a possibility to to
add additional flag for sb->s_flags.
For example
#define MS_NOT_IMA (1<<25) /* NOT_IMA */
#define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
Another way is to add additional dedicated integrity related member to
the sb structure.
struct super_block {
...
#ifdef CONFIG_INTEGRITY
int s_integrity;
#endif
};
Obviously there are only few super blocks in the system and few bytes
will not harm.
Can you please advice about this?
Thanks,
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IMA policy search speedup
2012-09-18 9:44 IMA policy search speedup Kasatkin, Dmitry
@ 2012-09-19 4:21 ` James Morris
2012-09-19 4:46 ` Al Viro
2012-09-19 10:25 ` Kasatkin, Dmitry
0 siblings, 2 replies; 6+ messages in thread
From: James Morris @ 2012-09-19 4:21 UTC (permalink / raw)
To: Kasatkin, Dmitry
Cc: Linus Torvalds, linux-fsdevel, linux-security-module, LKML,
Al Viro, Mimi Zohar
On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
> I looked to <linux/fs.h> and found that there is a possibility to to
> add additional flag for sb->s_flags.
> For example
>
> #define MS_NOT_IMA (1<<25) /* NOT_IMA */
> #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
>
>
> Another way is to add additional dedicated integrity related member to
> the sb structure.
> struct super_block {
> ...
> #ifdef CONFIG_INTEGRITY
> int s_integrity;
> #endif
> };
>
> Obviously there are only few super blocks in the system and few bytes
> will not harm.
The flag seems better than adding a new struct member. Why would you need
an int for this?
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IMA policy search speedup
2012-09-19 4:21 ` James Morris
@ 2012-09-19 4:46 ` Al Viro
2012-09-19 10:50 ` Kasatkin, Dmitry
2012-09-19 10:25 ` Kasatkin, Dmitry
1 sibling, 1 reply; 6+ messages in thread
From: Al Viro @ 2012-09-19 4:46 UTC (permalink / raw)
To: James Morris
Cc: Kasatkin, Dmitry, Linus Torvalds, linux-fsdevel,
linux-security-module, LKML, Mimi Zohar
On Wed, Sep 19, 2012 at 02:21:56PM +1000, James Morris wrote:
> On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
>
> > I looked to <linux/fs.h> and found that there is a possibility to to
> > add additional flag for sb->s_flags.
> > For example
> >
> > #define MS_NOT_IMA (1<<25) /* NOT_IMA */
> > #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
> >
> >
> > Another way is to add additional dedicated integrity related member to
> > the sb structure.
> > struct super_block {
> > ...
> > #ifdef CONFIG_INTEGRITY
> > int s_integrity;
> > #endif
> > };
> >
> > Obviously there are only few super blocks in the system and few bytes
> > will not harm.
>
> The flag seems better than adding a new struct member. Why would you need
> an int for this?
Per-superblock bit would be a bit better, but I really hate the way we have
them mixed up between superblock ->s_flags bits and mount(2) action weirdly
encoded into flags thing. If we are going to touch that thing, how about
separate S_... bits, with MS_... crap left only for mount(2) decoding? Mapped
to S_... when needed.
The really messy part is that right now we silently ignore all the unknown
bits in mount(2) flags argument ;-/ It's *not* a widely used syscall, but
still - changing that in a non-trivial way is potential userland breakage.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IMA policy search speedup
2012-09-19 4:46 ` Al Viro
@ 2012-09-19 10:50 ` Kasatkin, Dmitry
0 siblings, 0 replies; 6+ messages in thread
From: Kasatkin, Dmitry @ 2012-09-19 10:50 UTC (permalink / raw)
To: Al Viro
Cc: James Morris, Linus Torvalds, linux-fsdevel,
linux-security-module, LKML, Mimi Zohar
On Wed, Sep 19, 2012 at 7:46 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Wed, Sep 19, 2012 at 02:21:56PM +1000, James Morris wrote:
>> On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
>>
>> > I looked to <linux/fs.h> and found that there is a possibility to to
>> > add additional flag for sb->s_flags.
>> > For example
>> >
>> > #define MS_NOT_IMA (1<<25) /* NOT_IMA */
>> > #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
>> >
>> >
>> > Another way is to add additional dedicated integrity related member to
>> > the sb structure.
>> > struct super_block {
>> > ...
>> > #ifdef CONFIG_INTEGRITY
>> > int s_integrity;
>> > #endif
>> > };
>> >
>> > Obviously there are only few super blocks in the system and few bytes
>> > will not harm.
>>
>> The flag seems better than adding a new struct member. Why would you need
>> an int for this?
>
> Per-superblock bit would be a bit better, but I really hate the way we have
> them mixed up between superblock ->s_flags bits and mount(2) action weirdly
> encoded into flags thing. If we are going to touch that thing, how about
> separate S_... bits, with MS_... crap left only for mount(2) decoding? Mapped
> to S_... when needed.
>
> The really messy part is that right now we silently ignore all the unknown
> bits in mount(2) flags argument ;-/ It's *not* a widely used syscall, but
> still - changing that in a non-trivial way is potential userland breakage.
Indeed it is quite messy.
My understanding is that S_ flags are inode->i_flags. Would it be also
a bit confusing?
Do you suggest to add additional superblock flags attribute? What
could be moved there?
- Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IMA policy search speedup
2012-09-19 4:21 ` James Morris
2012-09-19 4:46 ` Al Viro
@ 2012-09-19 10:25 ` Kasatkin, Dmitry
2012-09-19 20:07 ` J. Bruce Fields
1 sibling, 1 reply; 6+ messages in thread
From: Kasatkin, Dmitry @ 2012-09-19 10:25 UTC (permalink / raw)
To: James Morris
Cc: Linus Torvalds, linux-fsdevel, linux-security-module, LKML,
Al Viro, Mimi Zohar
On Wed, Sep 19, 2012 at 7:21 AM, James Morris <jmorris@namei.org> wrote:
> On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
>
>> I looked to <linux/fs.h> and found that there is a possibility to to
>> add additional flag for sb->s_flags.
>> For example
>>
>> #define MS_NOT_IMA (1<<25) /* NOT_IMA */
>> #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
>>
>>
>> Another way is to add additional dedicated integrity related member to
>> the sb structure.
>> struct super_block {
>> ...
>> #ifdef CONFIG_INTEGRITY
>> int s_integrity;
>> #endif
>> };
>>
>> Obviously there are only few super blocks in the system and few bytes
>> will not harm.
>
> The flag seems better than adding a new struct member. Why would you need
> an int for this?
>
int is not really needed. It may be char. I just thought that normally
we have around 10 super blocks
and it 10 or 40 bytes does not really mater...
Actually there is more severe case. IMA cache objects "iint" per inode
have following members:
enum integrity_status ima_status;
enum integrity_status evm_status;
And it is only 5 values per each or 10 values per 8 bytes.
8 bytes can be easily replaced by 1 byte.
Should we improve it?
>
>
> - James
> --
> James Morris
> <jmorris@namei.org>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: IMA policy search speedup
2012-09-19 10:25 ` Kasatkin, Dmitry
@ 2012-09-19 20:07 ` J. Bruce Fields
0 siblings, 0 replies; 6+ messages in thread
From: J. Bruce Fields @ 2012-09-19 20:07 UTC (permalink / raw)
To: Kasatkin, Dmitry
Cc: James Morris, Linus Torvalds, linux-fsdevel,
linux-security-module, LKML, Al Viro, Mimi Zohar
On Wed, Sep 19, 2012 at 01:25:26PM +0300, Kasatkin, Dmitry wrote:
> On Wed, Sep 19, 2012 at 7:21 AM, James Morris <jmorris@namei.org> wrote:
> > On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
> >
> >> I looked to <linux/fs.h> and found that there is a possibility to to
> >> add additional flag for sb->s_flags.
> >> For example
> >>
> >> #define MS_NOT_IMA (1<<25) /* NOT_IMA */
> >> #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA)
> >>
> >>
> >> Another way is to add additional dedicated integrity related member to
> >> the sb structure.
> >> struct super_block {
> >> ...
> >> #ifdef CONFIG_INTEGRITY
> >> int s_integrity;
> >> #endif
> >> };
> >>
> >> Obviously there are only few super blocks in the system and few bytes
> >> will not harm.
> >
> > The flag seems better than adding a new struct member. Why would you need
> > an int for this?
> >
>
> int is not really needed. It may be char. I just thought that normally
> we have around 10 super blocks
> and it 10 or 40 bytes does not really mater...
Maybe not, but if you use something more generic
unsigned int s_feature_flags
#define SF_IMA_ENABLED
then there'd be more uses for that field.
(Two that nfsd would use:
- does this filesystem support a changeattribute? (currently a
mount flag but that doesn't really make sense in general)
- is this filesystem case-insensitive? (whatever that means)
)
--b.
>
> Actually there is more severe case. IMA cache objects "iint" per inode
> have following members:
> enum integrity_status ima_status;
> enum integrity_status evm_status;
>
> And it is only 5 values per each or 10 values per 8 bytes.
> 8 bytes can be easily replaced by 1 byte.
>
> Should we improve it?
>
> >
> >
> > - James
> > --
> > James Morris
> > <jmorris@namei.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-19 20:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-18 9:44 IMA policy search speedup Kasatkin, Dmitry
2012-09-19 4:21 ` James Morris
2012-09-19 4:46 ` Al Viro
2012-09-19 10:50 ` Kasatkin, Dmitry
2012-09-19 10:25 ` Kasatkin, Dmitry
2012-09-19 20:07 ` J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).