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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]