* Tycho Andersen:
On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
quoted
On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
quoted
On 2019-09-06, Mickaël Salaün [off-list ref] wrote:
quoted
On 06/09/2019 17:56, Florian Weimer wrote:
quoted
Let's assume I want to add support for this to the glibc dynamic loader,
while still being able to run on older kernels.
Is it safe to try the open call first, with O_MAYEXEC, and if that fails
with EINVAL, try again without O_MAYEXEC?
The kernel ignore unknown open(2) flags, so yes, it is safe even for
older kernel to use O_MAYEXEC.
Depends on your definition of "safe" -- a security feature that you will
silently not enable on older kernels doesn't sound super safe to me.
Unfortunately this is a limitation of open(2) that we cannot change --
which is why the openat2(2) proposal I've been posting gives -EINVAL for
unknown O_* flags.
There is a way to probe for support (though unpleasant), by creating a
test O_MAYEXEC fd and then checking if the flag is present in
/proc/self/fdinfo/$n.
Which Florian said they can't do for various reasons.
It is a major painpoint if there's no easy way for userspace to probe
for support. Especially if it's security related which usually means
that you want to know whether this feature works or not.
What about just trying to violate the policy via fexecve() instead of
looking around in /proc? Still ugly, though.
How would we do this? This is about opening the main executable as part
of an explicit loader invocation. Typically, an fexecve will succeed
and try to run the program, but with the wrong dynamic loader.
Thanks,
Florian
On Fri, Sep 06, 2019 at 08:27:31PM +0200, Florian Weimer wrote:
* Tycho Andersen:
quoted
On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
quoted
On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
quoted
On 2019-09-06, Mickaël Salaün [off-list ref] wrote:
quoted
On 06/09/2019 17:56, Florian Weimer wrote:
quoted
Let's assume I want to add support for this to the glibc dynamic loader,
while still being able to run on older kernels.
Is it safe to try the open call first, with O_MAYEXEC, and if that fails
with EINVAL, try again without O_MAYEXEC?
The kernel ignore unknown open(2) flags, so yes, it is safe even for
older kernel to use O_MAYEXEC.
Depends on your definition of "safe" -- a security feature that you will
silently not enable on older kernels doesn't sound super safe to me.
Unfortunately this is a limitation of open(2) that we cannot change --
which is why the openat2(2) proposal I've been posting gives -EINVAL for
unknown O_* flags.
There is a way to probe for support (though unpleasant), by creating a
test O_MAYEXEC fd and then checking if the flag is present in
/proc/self/fdinfo/$n.
Which Florian said they can't do for various reasons.
It is a major painpoint if there's no easy way for userspace to probe
for support. Especially if it's security related which usually means
that you want to know whether this feature works or not.
What about just trying to violate the policy via fexecve() instead of
looking around in /proc? Still ugly, though.
How would we do this? This is about opening the main executable as part
of an explicit loader invocation. Typically, an fexecve will succeed
and try to run the program, but with the wrong dynamic loader.
Yeah, fexecve() was a think-o, sorry, you don't need to go that far. I
was thinking do what the tests in this series do: create a tmpfs with
MS_NOEXEC, put an executable file in it, and try and open it with
O_MAYEXEC. If that works, the kernel doesn't support the flag, and it
should give you -EACCES if the kernel does support the flag.
Still a lot of work, though. Seems better to just use openat2.
Tycho