* Greg KH <gre...@linuxfoundation.org> wrote:
> On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote:
> > So what I'd love to see is to have a kernel option that re-introduces some
> > historic root (and other) holes that can be exploited deterministically -
> > obviously default disabled.
>
> Ick, I don't want to have to support nasty #ifdefs for
> "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+
> years, do you?
I'd write it in C, not CPP, so it would be an 'if', but yeah, it would be extra
code otherwise.
So I'd restrict this strictly to cases:
- Where the maintainer absolutely agrees to carry it.
- Where it's still easy to do technically - for example a single unobtrusive
'if' condition or so, in cases where the current upstream code still has a
similar structure conductive to the re-introducion of the bug. Such testcases
can be dropped the moment they interfere with active development.
- Plus an additional approach could be that some of the typical holes can be
reproduced in completely separate code that is not seen by anyone who
doesn't
want to see it.
I doubt many bugs have 20 years life times in face of frequent code
reorganization
- and if code is static for 20 years then there won't be much extra maintenance
overhead, right?
> > I'd restrict this to reasonably 'deterministic' holes, and the exploits
> > themselves
> > could be somewhere in tools/. (Obviously only where the maintainers agree
> > to host
> > the code.) They wouldn't give a root shell, they'd only test whether they
> > reached
> > uid0 (or some other elevated privilege).
>
> Having exploits in tools/ would be good, I would like to see that, as
> then we can ensure that we don't ever introduce old problems that we
> have fixed again in the future. That I have no objection to.
Heh, I actually guessed that this would be the more contentious part of my
suggestion - go figure! ;-)
Thanks,
Ingo
