[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201013170515.GS17637@brightrain.aerifal.cx>
Date: Tue, 13 Oct 2020 13:05:15 -0400
From: Rich Felker <dalias@...c.org>
To: Alexey Izbyshev <izbyshev@...ras.ru>
Cc: musl@...ts.openwall.com
Subject: Re: Calling setxid() in a vfork()-child
On Tue, Oct 13, 2020 at 07:52:28PM +0300, Alexey Izbyshev wrote:
> On 2020-10-12 23:30, Alexey Izbyshev wrote:
> >...However, thinking about it
> >more, I see that dropping privileges could open the child to new ways
> >of interaction from outside of the app in a window before execve(),
> >so, if, say, another unprivileged process can ptrace it at the right
> >moment, bad things could happen.
> >
> Alexander Monakov pointed out to me that this particular naive
> attack is not possible (unless "/proc/sys/fs/suid_dumpable" is
> changed or the application resets "dumpable" bit via prctl() after
> setxid()):
> https://elixir.bootlin.com/linux/v5.9/source/kernel/cred.c#L466
Yes, the underlying idea here is that suid programs will often open a
privileged resource to perform limited operations on it, and while the
outcome of giving the user unrestricted access to that resource might
not be catastrophic, it's likely at least disruptive (think ping and
raw sockets). Also it may still have privileged data (like private
keys or remnants thereof) in its memory. So the user is not allowed to
debug/trace/seize control of such a process unless it explicitly opts
in.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
