linux-kernel - Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

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 for Android: free password hash cracker in your pocket

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

Message-ID: <30B99B06-5CA3-4139-B092-76158A8E7A5A@joshtriplett.org>
Date:   Tue, 08 Nov 2016 17:08:54 -0800
From:   Josh Triplett <josh@...htriplett.org>
To:     Kees Cook <keescook@...omium.org>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        Thomas Garnier <thgarnie@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Zefan Li <lizefan@...wei.com>,
        Li Bin <huawei.libin@...wei.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Alex Thorlton <athorlton@....com>,
        Michal Hocko <mhocko@...e.com>,
        Mateusz Guzik <mguzik@...hat.com>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        John Stultz <john.stultz@...aro.org>,
        Al Viro <viro@...iv.linux.org.uk>, Zach Brown <zab@...hat.com>,
        Anna Schumaker <Anna.Schumaker@...app.com>,
        Dave Hansen <dave.hansen@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On November 8, 2016 4:56:54 PM PST, Kees Cook <keescook@...omium.org> wrote:
>On Tue, Nov 8, 2016 at 4:47 PM, Josh Triplett <josh@...htriplett.org>
>wrote:
>> On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote:
>>> On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett
><josh@...htriplett.org> wrote:
>>> > Some embedded systems can do without the prctl syscall, saving
>some
>>> > space.
>>> >
>>> > This also avoids regular increases in tinyconfig size as people
>add more
>>> > non-optional functionality to prctl (observed via the 0-day kernel
>>> > infrastructure).
>>> >
>>> > bloat-o-meter results:
>>> >
>>> > add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-2143 (-2143)
>>> > function                                     old     new   delta
>>> > offsets                                       23      12     -11
>>> > prctl_set_auxv                                97       -     -97
>>> > sys_prctl                                    794       -    -794
>>> > prctl_set_mm                                1241       -   -1241
>>> > Total: Before=1902583, After=1900440, chg -0.11%
>>> >
>>> > Signed-off-by: Josh Triplett <josh@...htriplett.org>
>>>
>>> I'm absolutely a fan of doing this, but I wonder how this interacts
>>> with the LSMs that define prctl hooks, etc. I wouldn't expect a
>system
>>> that didn't want prctl to want an LSM, but maybe the LSMs all need
>to
>>> depend on CONFIG_PRCTL now?
>>
>> I did think about that (as well as SECCOMP), but I did confirm that
>the
>> kernel builds fine with allyesconfig minus CONFIG_PRCTL.  An LSM that
>> wants to restrict access to some prctls should be fine with no
>process
>> having any access to prctl. :)  Beyond that, anything wanting
>> configuration via LSM (such as SECCOMP) still exists and functions,
>even
>> if you can't access it from outside the kernel.
>
>Okay, testing that is good, thanks.
>
>Seccomp can use the seccomp() syscall, so missing prctl isn't a big
>deal there.
>
>Things like Yama, though, are almost useless in the !PRCTL case. I
>think a "depends on PRCTL" should be added at least to Yama. All the
>other LSMs are configured in other ways, and they'll just have some
>dead code around their prctl hooks; no big deal.

OK, I'll add that dependency to Yama in v2.

>This does also beg the question about how to configure some process
>behaviors by default if PRCTL is disabled, but if people want those
>things, they can write patches, I would think. :)

Agreed.