Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > Maybe I'm just wrong... I definitely chosen bad example (grub) because
> > it is also bootloader...
> > 
> > > (iv) From then on, the IMA in the kernel is responsible for measuring 
> > > executables/modules before loading them and for maintaining the 
> > > measurement list and its TPM aggregate. 
> > 
> > Kernel does not know what is exacutable and what is data. Thanks to
> > buffer overflows, the line between executable and data is extremely
> > blury.
> > 
> > Now, to my argumentation. Imagine bootscripts containing
> > "show_etc_issue" command. (That shows /etc/issue). If there's buffer
> > overflow in "show_etc_issue" command, it is *not* security issue as of
> > now, because it only works on data provided by root. But it becomes
> > issue when IMA system is in use, because now /etc/issue can be used to
> > inject code into system; something that was not possible before.
> > 
> > OTOH buffer overrun in show_etc_issue is certainly bad thing, because
> > it is unexpected behaviour; and if IMA means such stuff is fixed...
> > 
> > It just seems like a lot of work. You are basically adding check at
> > every place where user can
> >  shoot_himself_in_the_foot^W^W^W^W^Wdo_something_stupid_to_system_security
> > . I suspect many config files can be used to compromise system
> > security...

> 
> Pavel, I cannot follow your argumentation. Could you please expand on how
> measuring a script file would affect existing buffer overflows at all?
> 
> Just to make sure we are in sync how user space measurements work, here
> a summary at the bash example:
> 
> (i) bash at point x opens "show_etc_issue" and holds file descriptor in 
>     fd_show
> 
> (ii) before bash reads the commands from fd_show, we insert a line of code
>     writing fd_show down into the kernel (this is a fixed size data 
>     structure)
> 
> (iii) IMA hook in the kernel now reads the whole file building a SHA1
>       (there is no interpretation of any content of any file here)
> 
> (iv)  IMA decides whether the measurement of the file must be stored or 
>       whether it is already in the measurement list etc.
> 
> (v)   writing fd_show returns to bash
> 
> (vi) bash reads the commands and executes them
> 
> If I understand you, then you are claiming that steps (ii) to (v) 
> introduce buffer overflows in bash or show_etc_issue. How?

No, I'm not claiming that. You are certainly *not* introducing any new
problems.

But some problems that used to be harmless (buffer overrun in
show_etc_issue command) are not harmless any more.
								Pavel