linux-kernel - Re: [RFC][PATCH 7/7] kref: Implement using refcount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Nov 2016 10:07:37 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        David Windsor <dave@...gbits.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t


* Greg KH <gregkh@...uxfoundation.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