linux-kernel - Re: [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users

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]

Message-ID: <87o8594jlq.fsf@email.froward.int.ebiederm.org>
Date:   Tue, 21 Dec 2021 17:35:29 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Willy Tarreau <w@....eu>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Waiman Long <longman@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Laurent Vivier <laurent@...ier.eu>,
        YunQiang Su <ysu@...ecomp.com>, Helge Deller <deller@....de>
Subject: Re: [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users

Willy Tarreau <w@....eu> writes:

> On Tue, Dec 21, 2021 at 09:56:35PM +0100, Willy Tarreau wrote:
>> > As it is all done within the kernel, there is no need to
>> > change any userspace code. We may need to add a flag bit in the task
>> > structure to indicate using the suid_dumpable setting so that it can be
>> > inherited across fork/exec.
>> 
>> Depending on what we change there can be some subtly visible changes.
>> In one of my servers I explicitly re-enable dumpable before setsid()
>> when a core dump is desired for debugging. But other deamons could do
>> the exact opposite. If setsid() systematically restores suid_dumpable,
>> a process that explicitly disables it before calling setsid() would
>> see it come back. But if we have a special "suid_in_progress" flag
>> to mask suid_dumpable and that's reset by setsid() and possibly
>> prctl(PR_SET_DUMPABLE) then I think it could even cover that unlikely
>> case.
>
> Would there be any interest in pursuing attempts like the untested patch
> below ? The intent is to set a new MMF_NOT_DUMPABLE on exec on setuid or
> setgid bit, but clear it on setrlimit(RLIMIT_CORE), prctl(SET_DUMPABLE),
> and setsid(). This flag makes get_dumpable() return SUID_DUMP_DISABLED
> when set. I think that in the spirit it could maintain the info that a
> suidexec happened and was not reset, without losing any tuning made by
> the application. I never feel at ease touching all this and I certainly
> did some mistakes but for now it's mostly to have a base to discuss
> around, so do not hesitate to suggest or criticize.

Yes.  This looks like a good place to start the conversation.

We need to do something like you are doing to separate dumpability
changes due to privilege gains during exec and dumpability changes due
to privilege shuffling with setresuid.

As long as we only impact processes descending from a binary that has
gained privileges during exec (like this patch) I think we have a lot
of latitude in how we make this happen.  Basically we only need to
test su and sudo and verify that whatever we do works reasonably
well for them.

On the one hand I believe of gaining privileges during exec while
letting the caller control some aspect of our environment is a dangerous
design flaw and I would love to remove gaining privileges during exec
entirely.

On the other hand we need to introduces as few regressions as possible
and make gaining privileges during exec as safe as possible.

I do agree that RLIMIT_CORE and prctl(SET_DUMPABLE) are good places
to clear the flag.

I don't know if setsid is the proper key to re-enabling dumpability.

I ran a quick test and simply doing "su" and then running a shell
as root does not change the session, nor does "su -" (which creates
a login shell).  Also "sudo -s" does not create a new session.

So session creation does not happen naturally.

Still setsid is part of the standard formula for starting a daemon,
so I don't think system services that run as daemons will be affected.

I don't think anything we do matters for systemd.  As I understand
it "systemctl start ..." causes pid 1 to fork and exec services,
which will ensure the started processes are not descendants of
the binary the gained privileges during exec.

Eric