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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 8 Nov 2016 16:56:54 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Josh Triplett <josh@...htriplett.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 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.

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. :)

-Kees

-- 
Kees Cook
Nexus Security