* Re: Why add the general notification queue and its sources
From: Linus Torvalds @ 2019-09-06 17:07 UTC (permalink / raw)
To: Steven Whitehouse
Cc: David Howells, Ray Strode, Greg Kroah-Hartman, Nicolas Dichtel,
raven, keyrings, linux-usb, linux-block, Christian Brauner,
LSM List, linux-fsdevel, Linux API, Linux List Kernel Mailing,
Al Viro, Ray, Debarshi, Robbie Harwood
In-Reply-To: <8e60555e-9247-e03f-e8b4-1d31f70f1221@redhat.com>
On Fri, Sep 6, 2019 at 9:12 AM Steven Whitehouse <swhiteho@redhat.com> wrote:
>
> The events are generally not independent - we would need ordering either
> implicit in the protocol or explicit in the messages.
Note that pipes certainly would never re-order messages. It's just
that _if_ you have two independent and concurrent readers of the same
pipe, they could read one message each, and you couldn't tell which
was first in user space.
Of course, I would suggest that anything that actually has
non-independent messages should always use a sequence number or
something like that in the message anyway. But then it would have to
be on a protocol level.
And it's not clear that all notifications need it. If it's just a
random "things changed" notification, mnaybe that doesn't need a
sequence number or anything else. So being on a protocol/data stream
level might be the right thing regardless.
Another possibility is to just say "don't do that then". If you want
multiple concurrent readers, open multiple pipes for them and use
separate events, and be happy in the knowledge that you don't have any
complicated cases.
> We also need to
> know in case messages are dropped too - doesn't need to be anything
> fancy, just some idea that since we last did a read, there are messages
> that got lost, most likely due to buffer overrun.
Pipes don't have that, but another flag certainly wouldn't be _hard_ to add.
But one problem (and this is fundamental) is that while O_DIRECT works
today (and works with kernels going back years), any new features like
overflow notification would obviously not work with legacy kernels.
On the user write side, with an O_NONBLOCK pipe, you currently just
get an -EAGAIN, so you _see_ the drop happening. But (again) there's
no sticky flag for it anywhere else, and there's no clean automatic
way for the reader to see "ok, the writer overflowed".
That's not a problem for any future extensions - the feature sounds
like a new flag and a couple of lines to do it - but it's a problem
for the whole "prototype in user space using existing pipe support"
that I personally find so nice, and which I think is such a good way
to prove the user space _need_ for anything like this.
But if people are ok with the pipe model in theory, _that_ kind of
small and directed feature I have absolutely no problem with adding.
It's just whole new untested character mode drivers with odd semantics
that I find troublesome.
Hmm. Maybe somebody can come up with a good legacy signaling solution
(and "just use another pipe for error notification and OOB data" for
the first one may _work_, but that sounds pretty hacky and just not
very convenient).
Linus
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Christian Brauner @ 2019-09-06 17:20 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906170739.kk3opr2phidb7ilb@yavin.dot.cyphar.com>
On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> >
> > On 06/09/2019 17:56, Florian Weimer wrote:
> > > 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.
Christian
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Mickaël Salaün @ 2019-09-06 17:24 UTC (permalink / raw)
To: Christian Brauner, Aleksa Sarai
Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906172050.v44f43psd6qc6awi@wittgenstein>
On 06/09/2019 19:20, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>>>
>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>> 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.
I used "safe" deliberately (not "secure" which didn't make sense in this
sentence). According to the threat model, if the kernel doesn't support
the feature, it should be ignored by userland. In this case, it fit well
with the current behavior of open(2). I agree that the openat2(2)
behavior handling flags is the good way to do it (whitelisting), but the
O_MAYEXEC flag should not change the userland behavior on its own,
because it depend on a global policy. Even being able to probe for
O_MAYEXEC support does not make sense because it would not be enough to
know the system policy (either this flag is enforced or not…).
Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Tycho Andersen @ 2019-09-06 17:40 UTC (permalink / raw)
To: Christian Brauner
Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906172050.v44f43psd6qc6awi@wittgenstein>
On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> > >
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > 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.
Tycho
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Florian Weimer @ 2019-09-06 18:27 UTC (permalink / raw)
To: Tycho Andersen
Cc: Christian Brauner, Aleksa Sarai, Mickaël Salaün,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906174041.GH7627@cisco>
* Tycho Andersen:
> On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
>> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
>> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
>> > >
>> > > On 06/09/2019 17:56, Florian Weimer wrote:
>> > > > 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
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Jeff Layton @ 2019-09-06 18:38 UTC (permalink / raw)
To: Mickaël Salaün, Florian Weimer,
Mickaël Salaün
Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Steve Grubb, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <1fbf54f6-7597-3633-a76c-11c4b2481add@ssi.gouv.fr>
On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
> On 06/09/2019 18:48, Jeff Layton wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > 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.
> > >
> >
> > Well...maybe. What about existing programs that are sending down bogus
> > open flags? Once you turn this on, they may break...or provide a way to
> > circumvent the protections this gives.
>
> Well, I don't think we should nor could care about bogus programs that
> do not conform to the Linux ABI.
>
But they do conform. The ABI is just undefined here. Unknown flags are
ignored so we never really know if $random_program may be setting them.
> > Maybe this should be a new flag that is only usable in the new openat2()
> > syscall that's still under discussion? That syscall will enforce that
> > all flags are recognized. You presumably wouldn't need the sysctl if you
> > went that route too.
>
> Here is a thread about a new syscall:
> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>
> I don't think it fit well with auditing nor integrity. Moreover using
> the current open(2) behavior of ignoring unknown flags fit well with the
> usage of O_MAYEXEC (because it is only a hint to the kernel about the
> use of the *opened* file).
>
The fact that open and openat didn't vet unknown flags is really a bug.
Too late to fix it now, of course, and as Aleksa points out, we've
worked around that in the past. Now though, we have a new openat2
syscall on the horizon. There's little need to continue these sorts of
hacks.
New open flags really have no place in the old syscalls, IMO.
> > Anyone that wants to use this will have to recompile anyway. If the
> > kernel doesn't support openat2 or if the flag is rejected then you know
> > that you have no O_MAYEXEC support and can decide what to do.
>
> If we want to enforce a security policy, we need to either be the system
> administrator or the distro developer. If a distro ship interpreters
> using this flag, we don't need to recompile anything, but we need to be
> able to control the enforcement according to the mount point
> configuration (or an advanced MAC, or an IMA config). I don't see why an
> userspace process should check if this flag is supported or not, it
> should simply use it, and the sysadmin will enable an enforcement if it
> makes sense for the whole system.
>
A userland program may need to do other risk mitigation if it sets
O_MAYEXEC and the kernel doesn't recognize it.
Personally, here's what I'd suggest:
- Base this on top of the openat2 set
- Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
- Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
That works around a whole pile of potential ABI headaches. Note that
we'd need to make that decision before the openat2 patches are merged.
Even better would be to declare the new flag in some openat2-only flag
space, so there's no confusion about it being supported by legacy open
calls.
If glibc wants to implement an open -> openat2 wrapper in userland
later, it can set that flag in the wrapper implicitly to emulate the old
behavior.
Given that you're going to have to recompile software to take advantage
of this anyway, what's the benefit to changing legacy syscalls?
> > > > Or do I risk disabling this security feature if I do that?
> > >
> > > It is only a security feature if the kernel support it, otherwise it is
> > > a no-op.
> > >
> >
> > With a security feature, I think we really want userland to aware of
> > whether it works.
>
> If userland would like to enforce something, it can already do it
> without any kernel modification. The goal of the O_MAYEXEC flag is to
> enable the kernel, hence sysadmins or system designers, to enforce a
> global security policy that makes sense.
>
I don't see how this helps anything if you can't tell whether the kernel
recognizes the damned thing. Also, our track record with global sysctl
switches like this is pretty poor. They're an administrative headache as
well as a potential attack vector.
I think your idea is a good one, but it could stand to have fewer moving
parts.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Andy Lutomirski @ 2019-09-06 18:41 UTC (permalink / raw)
To: Jeff Layton
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <5a59b309f9d0603d8481a483e16b5d12ecb77540.camel@kernel.org>
> On Sep 6, 2019, at 11:38 AM, Jeff Layton <jlayton@kernel.org> wrote:
>
>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>> On 06/09/2019 18:48, Jeff Layton wrote:
>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>> 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.
>>>>
>>>
>>> Well...maybe. What about existing programs that are sending down bogus
>>> open flags? Once you turn this on, they may break...or provide a way to
>>> circumvent the protections this gives.
>>
>> Well, I don't think we should nor could care about bogus programs that
>> do not conform to the Linux ABI.
>>
>
> But they do conform. The ABI is just undefined here. Unknown flags are
> ignored so we never really know if $random_program may be setting them.
>
>>> Maybe this should be a new flag that is only usable in the new openat2()
>>> syscall that's still under discussion? That syscall will enforce that
>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>> went that route too.
>>
>> Here is a thread about a new syscall:
>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>>
>> I don't think it fit well with auditing nor integrity. Moreover using
>> the current open(2) behavior of ignoring unknown flags fit well with the
>> usage of O_MAYEXEC (because it is only a hint to the kernel about the
>> use of the *opened* file).
>>
>
> The fact that open and openat didn't vet unknown flags is really a bug.
>
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little need to continue these sorts of
> hacks.
>
> New open flags really have no place in the old syscalls, IMO.
>
>>> Anyone that wants to use this will have to recompile anyway. If the
>>> kernel doesn't support openat2 or if the flag is rejected then you know
>>> that you have no O_MAYEXEC support and can decide what to do.
>>
>> If we want to enforce a security policy, we need to either be the system
>> administrator or the distro developer. If a distro ship interpreters
>> using this flag, we don't need to recompile anything, but we need to be
>> able to control the enforcement according to the mount point
>> configuration (or an advanced MAC, or an IMA config). I don't see why an
>> userspace process should check if this flag is supported or not, it
>> should simply use it, and the sysadmin will enable an enforcement if it
>> makes sense for the whole system.
>>
>
> A userland program may need to do other risk mitigation if it sets
> O_MAYEXEC and the kernel doesn't recognize it.
>
> Personally, here's what I'd suggest:
>
> - Base this on top of the openat2 set
> - Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
>
> That works around a whole pile of potential ABI headaches. Note that
> we'd need to make that decision before the openat2 patches are merged.
>
> Even better would be to declare the new flag in some openat2-only flag
> space, so there's no confusion about it being supported by legacy open
> calls.
>
> If glibc wants to implement an open -> openat2 wrapper in userland
> later, it can set that flag in the wrapper implicitly to emulate the old
> behavior.
>
> Given that you're going to have to recompile software to take advantage
> of this anyway, what's the benefit to changing legacy syscalls?
>
>>>>> Or do I risk disabling this security feature if I do that?
>>>>
>>>> It is only a security feature if the kernel support it, otherwise it is
>>>> a no-op.
>>>>
>>>
>>> With a security feature, I think we really want userland to aware of
>>> whether it works.
>>
>> If userland would like to enforce something, it can already do it
>> without any kernel modification. The goal of the O_MAYEXEC flag is to
>> enable the kernel, hence sysadmins or system designers, to enforce a
>> global security policy that makes sense.
>>
>
> I don't see how this helps anything if you can't tell whether the kernel
> recognizes the damned thing. Also, our track record with global sysctl
> switches like this is pretty poor. They're an administrative headache as
> well as a potential attack vector.
I tend to agree. The sysctl seems like it’s asking for trouble. I can see an ld.so.conf option to turn this thing off making sense.
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Florian Weimer @ 2019-09-06 18:44 UTC (permalink / raw)
To: Jeff Layton
Cc: Mickaël Salaün, Mickaël Salaün, linux-kernel,
Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Steve Grubb, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <5a59b309f9d0603d8481a483e16b5d12ecb77540.camel@kernel.org>
* Jeff Layton:
> Even better would be to declare the new flag in some openat2-only flag
> space, so there's no confusion about it being supported by legacy open
> calls.
Isn't that desirable anyway because otherwise fcntl with F_GETFL will
give really confusing results?
> If glibc wants to implement an open -> openat2 wrapper in userland
> later, it can set that flag in the wrapper implicitly to emulate the old
> behavior.
I see us rather doing the opposite, i.e. implement openat2 with
non-exotic flags using openat. But we've bitten by this in the past, so
maybe that's not such a great idea. It's tempting to make the same
mistake again for every new system call.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Tycho Andersen @ 2019-09-06 18:46 UTC (permalink / raw)
To: Florian Weimer
Cc: Christian Brauner, Aleksa Sarai, Mickaël Salaün,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <87v9u5cmb0.fsf@oldenburg2.str.redhat.com>
On Fri, Sep 06, 2019 at 08:27:31PM +0200, Florian Weimer wrote:
> * Tycho Andersen:
>
> > On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote:
> >> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote:
> >> > On 2019-09-06, Mickaël Salaün <mickael.salaun@ssi.gouv.fr> wrote:
> >> > >
> >> > > On 06/09/2019 17:56, Florian Weimer wrote:
> >> > > > 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
^ permalink raw reply
* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
From: Steve Grubb @ 2019-09-06 18:50 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Aleksa Sarai, Alexei Starovoitov, Al Viro,
Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
Florian Weimer, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906152455.22757-1-mic@digikod.net>
On Friday, September 6, 2019 11:24:50 AM EDT Mickaël Salaün wrote:
> The goal of this patch series is to control script interpretation. A
> new O_MAYEXEC flag used by sys_open() is added to enable userspace
> script interpreter to delegate to the kernel (and thus the system
> security policy) the permission to interpret/execute scripts or other
> files containing what can be seen as commands.
The problem is that this is only a gentleman's handshake. If I don't tell the
kernel that what I'm opening is tantamount to executing it, then the security
feature is never invoked. It is simple to strip the flags off of any system
call without needing privileges. For example:
#define _GNU_SOURCE
#include <link.h>
#include <fcntl.h>
#include <string.h>
unsigned int
la_version(unsigned int version)
{
return version;
}
unsigned int
la_objopen(struct link_map *map, Lmid_t lmid, uintptr_t *cookie)
{
return LA_FLG_BINDTO | LA_FLG_BINDFROM;
}
typedef int (*openat_t) (int dirfd, const char *pathname, int flags, mode_t mode);
static openat_t real_openat = 0L;
int my_openat(int dirfd, const char *pathname, int flags, mode_t mode)
{
flags &= ~O_CLOEXEC;
return real_openat(dirfd, pathname, flags, mode);
}
uintptr_t
la_symbind64(Elf64_Sym *sym, unsigned int ndx, uintptr_t *refcook,
uintptr_t *defcook, unsigned int *flags, const char *symname)
{
if (real_openat == 0L && strcmp(symname, "openat") == 0) {
real_openat = (openat_t) sym->st_value;
return (uintptr_t) my_openat;
}
return sym->st_value;
}
gcc -c -g -Wno-unused-parameter -W -Wall -Wundef -O2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fPIC test.c
gcc -o strip-flags.so.0 -shared -Wl,-soname,strip-flags.so.0 -ldl test.o
Now, let's make a test program:
#include <stdio.h>
#include <dirent.h>
#include <fcntl.h>
#include <unistd.h>
int main(void)
{
int dir_fd, fd;
DIR *d = opendir("/etc");
dir_fd = dirfd(d);
fd = openat(dir_fd, "passwd", O_RDONLY|O_CLOEXEC);
close (fd);
closedir(d);
return 0;
}
gcc -g -W -Wall -Wundef test.c -o test
OK, let's see what happens.
$ strace ./test 2>&1 | grep passwd
openat(3, "passwd", O_RDONLY|O_CLOEXEC) = 4
Now with LD_AUDIT
$ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | grep passwd
openat(3, "passwd", O_RDONLY) = 4
No O_CLOEXEC flag.
-Steve
^ permalink raw reply
* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
From: Florian Weimer @ 2019-09-06 18:57 UTC (permalink / raw)
To: Steve Grubb
Cc: Mickaël Salaün, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <2989749.1YmIBkDdQn@x2>
* Steve Grubb:
> Now with LD_AUDIT
> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | grep passwd
> openat(3, "passwd", O_RDONLY) = 4
>
> No O_CLOEXEC flag.
I think you need to explain in detail why you consider this a problem.
With LD_PRELOAD and LD_AUDIT, you can already do anything, including
scanning other loaded objects for a system call instruction and jumping
to that (in case a security module in the kernel performs a PC check to
confer additional privileges).
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: James Morris @ 2019-09-06 19:03 UTC (permalink / raw)
To: Jeff Layton
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
Daniel Borkmann, Eric Chiang, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <5a59b309f9d0603d8481a483e16b5d12ecb77540.camel@kernel.org>
On Fri, 6 Sep 2019, Jeff Layton wrote:
> The fact that open and openat didn't vet unknown flags is really a bug.
>
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little need to continue these sorts of
> hacks.
>
> New open flags really have no place in the old syscalls, IMO.
Agree here. It's unfortunate but a reality and Linus will reject any such
changes which break existing userspace.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
From: Steve Grubb @ 2019-09-06 19:07 UTC (permalink / raw)
To: Florian Weimer
Cc: Mickaël Salaün, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Al Viro, Andy Lutomirski, Christian Heimes,
Daniel Borkmann, Eric Chiang, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Thibaut S autereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <87mufhckxv.fsf@oldenburg2.str.redhat.com>
On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> * Steve Grubb:
> > Now with LD_AUDIT
> > $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> > 2>&1 | grep passwd openat(3, "passwd", O_RDONLY) = 4
> >
> > No O_CLOEXEC flag.
>
> I think you need to explain in detail why you consider this a problem.
Because you can strip the O_MAYEXEC flag from being passed into the kernel.
Once you do that, you defeat the security mechanism because it never gets
invoked. The issue is that the only thing that knows _why_ something is being
opened is user space. With this mechanism, you can attempt to pass this
reason to the kernel so that it may see if policy permits this. But you can
just remove the flag.
-Steve
> With LD_PRELOAD and LD_AUDIT, you can already do anything, including
> scanning other loaded objects for a system call instruction and jumping
> to that (in case a security module in the kernel performs a PC check to
> confer additional privileges).
>
> Thanks,
> Florian
^ permalink raw reply
* Re: [PATCH v2 0/5] Add support for O_MAYEXEC
From: Andy Lutomirski @ 2019-09-06 19:26 UTC (permalink / raw)
To: Steve Grubb
Cc: Florian Weimer, Mickaël Salaün, linux-kernel,
Aleksa Sarai, Alexei Starovoitov, Al Viro, Andy Lutomirski,
Christian Heimes, Daniel Borkmann, Eric Chiang, James Morris,
Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook, Matthew Garrett,
Matthew Wilcox, Michael Kerrisk, Mickaël Salaün,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Thibaut S autereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel
In-Reply-To: <1802966.yheqmZt8Si@x2>
> On Sep 6, 2019, at 12:07 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>
>> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
>> * Steve Grubb:
>>> Now with LD_AUDIT
>>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
>>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY) = 4
>>>
>>> No O_CLOEXEC flag.
>>
>> I think you need to explain in detail why you consider this a problem.
>
> Because you can strip the O_MAYEXEC flag from being passed into the kernel.
> Once you do that, you defeat the security mechanism because it never gets
> invoked. The issue is that the only thing that knows _why_ something is being
> opened is user space. With this mechanism, you can attempt to pass this
> reason to the kernel so that it may see if policy permits this. But you can
> just remove the flag.
I’m with Florian here. Once you are executing code in a process, you could just emulate some other unapproved code. This series is not intended to provide the kind of absolute protection you’re imagining.
What the kernel *could* do is prevent mmapping a non-FMODE_EXEC file with PROT_EXEC, which would indeed have a real effect (in an iOS-like world, for example) but would break many, many things.
^ permalink raw reply
* Re: Why add the general notification queue and its sources
From: Ray Strode @ 2019-09-06 19:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Greg Kroah-Hartman, Steven Whitehouse,
Nicolas Dichtel, raven, keyrings, linux-usb, linux-block,
Christian Brauner, LSM List, linux-fsdevel, Linux API,
Linux List Kernel Mailing, Al Viro, Ray, Debarshi, Robbie Harwood
In-Reply-To: <CAHk-=wjcsxQ8QB_v=cwBQw4pkJg7pp-bBsdWyPivFO_OeF-y+g@mail.gmail.com>
Hi,
On Thu, Sep 5, 2019 at 4:39 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> That is *way* too specific to make for any kind of generic
> notification mechanism.
Well from my standpoint, I just don't want to have to poll... I don't
have a strong opinion
about how it looks architecturally to reach that goal.
Ideally, at a higher level, I want the userspace api that gnome uses
to be something
like:
err = krb5_cc_watch (ctx, ccache, (krb5_cc_change_fct) on_cc_change ,
&watch_fd);
then a watch_fd would get handed back and caller could poll on it. if
it woke up poll(),
caller would do
krb5_cc_watch_update (ctx, ccache, watch_fd)
or so and it would trigger on_cc_change to get called (or something like that).
If under the hood, fd comes from opening /dev/watch_queue, and
krb5_cc_watch_update reads from some mmap'ed buffer to decide whether
or not to call on_cc_change, that's fine with me.
If under the hood, fd comes from a pipe fd returned from some ioctl or syscall,
and krb5_cc_watch_update reads messages directly from that fd to decide
whether or not to call on_cc_change, that's fine with me. too.
it could be an eventfd too, or whatever, too, just as long as its
something I can add
to poll() and don't have to intermittently poll ... :-)
> Also, what is the security model here? Open a special character
> device, and you get access to random notifications from random
> sources?
I guess dhowells answered this...
> And why would you do a broken big-key thing in the kernel in the first
> place? Why don't you just have a kernel key to indirectly encrypt
> using a key and "additional user space data". The kernel should simply
> not take care of insane 1MB keys.
🤷 dunno. I assume you're referencing the discussions from comment 0
on that 2013 bug. I wasn't involved in those discussions, I just chimed in
after they happened trying to avoid having to add polling :-)
I have no idea why a ticket would get that large. I assume it only is in weird
edge cases.
Anyway, gnome treats the tickets as opaque blobs. it doesn't do anything
with them other than tell the user when they need to get refreshed...
all the actual key manipulation happens from krb5 libraries.
of course, one advantage of having the tickets kernel side is nfs could
in theory access them directly, rather than up calling back to userspace...
--Ray
^ permalink raw reply
* Re: Why add the general notification queue and its sources
From: Ray Strode @ 2019-09-06 19:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Greg Kroah-Hartman, Steven Whitehouse,
Nicolas Dichtel, raven, keyrings, linux-usb, linux-block,
Christian Brauner, LSM List, linux-fsdevel, Linux API,
Linux List Kernel Mailing, Al Viro, Ray, Debarshi, Robbie Harwood
In-Reply-To: <CAKCoTu70E9cbVu=jVG4EiXnTNiG-znvri6Omh2t++1zRw+639Q@mail.gmail.com>
Hi,
On Fri, Sep 6, 2019 at 3:32 PM Ray Strode <rstrode@redhat.com> wrote:
> of course, one advantage of having the tickets kernel side is nfs could
> in theory access them directly, rather than up calling back to userspace...
No, that's not true actually, it's still going to need to go to
userspace to do hairy
context setup i guess...
so 🤷 dunno.
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Jeff Layton @ 2019-09-06 19:43 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906171335.d7mc3no5tdrcn6r5@yavin.dot.cyphar.com>
On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > 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.
> > >
> >
> > Well...maybe. What about existing programs that are sending down bogus
> > open flags? Once you turn this on, they may break...or provide a way to
> > circumvent the protections this gives.
>
> It should be noted that this has been a valid concern for every new O_*
> flag introduced (and yet we still introduced new flags, despite the
> concern) -- though to be fair, O_TMPFILE actually does have a
> work-around with the O_DIRECTORY mask setup.
>
> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> backwards compatible because empty path strings have always given ENOENT
> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
>
> > Maybe this should be a new flag that is only usable in the new openat2()
> > syscall that's still under discussion? That syscall will enforce that
> > all flags are recognized. You presumably wouldn't need the sysctl if you
> > went that route too.
>
> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> it, since I'd heard about this work through the grape-vine).
>
I rather like the idea of having openat2 fds be non-executable by
default, and having userland request it specifically via O_MAYEXEC (or
some similar openat2 flag) if it's needed. Then you could add an
UPGRADE_EXEC flag instead?
That seems like something reasonable to do with a brand new API, and
might be very helpful for preventing certain classes of attacks.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: Why add the general notification queue and its sources
From: Robbie Harwood @ 2019-09-06 19:53 UTC (permalink / raw)
To: Ray Strode, Linus Torvalds
Cc: David Howells, Greg Kroah-Hartman, Steven Whitehouse,
Nicolas Dichtel, raven, keyrings, linux-usb, linux-block,
Christian Brauner, LSM List, linux-fsdevel, Linux API,
Linux List Kernel Mailing, Al Viro, Ray, Debarshi
In-Reply-To: <CAKCoTu70E9cbVu=jVG4EiXnTNiG-znvri6Omh2t++1zRw+639Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3154 bytes --]
Ray Strode <rstrode@redhat.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> That is *way* too specific to make for any kind of generic
>> notification mechanism.
>
> Well from my standpoint, I just don't want to have to poll... I don't
> have a strong opinion about how it looks architecturally to reach that
> goal.
>
> Ideally, at a higher level, I want the userspace api that gnome uses
> to be something like:
>
> err = krb5_cc_watch (ctx, ccache, (krb5_cc_change_fct) on_cc_change ,
> &watch_fd);
>
> then a watch_fd would get handed back and caller could poll on it. if
> it woke up poll(), caller would do
>
> krb5_cc_watch_update (ctx, ccache, watch_fd)
>
> or so and it would trigger on_cc_change to get called (or something like that).
>
> If under the hood, fd comes from opening /dev/watch_queue, and
> krb5_cc_watch_update reads from some mmap'ed buffer to decide whether
> or not to call on_cc_change, that's fine with me.
>
> If under the hood, fd comes from a pipe fd returned from some ioctl or
> syscall, and krb5_cc_watch_update reads messages directly from that fd
> to decide whether or not to call on_cc_change, that's fine with
> me. too.
>
> it could be an eventfd too, or whatever, too, just as long as its
> something I can add to poll() and don't have to intermittently poll
> ... :-)
>
>
>> And why would you do a broken big-key thing in the kernel in the
>> first place? Why don't you just have a kernel key to indirectly
>> encrypt using a key and "additional user space data". The kernel
>> should simply not take care of insane 1MB keys.
>
> 🤷 dunno. I assume you're referencing the discussions from comment 0
> on that 2013 bug. I wasn't involved in those discussions, I just
> chimed in after they happened trying to avoid having to add polling
> :-)
>
> I have no idea why a ticket would get that large. I assume it only is
> in weird edge cases.
Sadly they're not weird, but yes. Kerberos tickets can get decently
large due to Microsoft's PACs (see MS-PAC and MS-KILE), which we need to
process, understand, and store for Active Directory interop. I'm not
sure if I've personally made one over 1MB, but it could easily occur
given enough claims (MS-ADTS).
> Anyway, gnome treats the tickets as opaque blobs. it doesn't do anything
> with them other than tell the user when they need to get refreshed...
>
> all the actual key manipulation happens from krb5 libraries.
>
> of course, one advantage of having the tickets kernel side is nfs
> could in theory access them directly, rather than up calling back to
> userspace...
Easy availability to filesystems is in fact the main theoretical
advantage of the keyring for us in krb5 (and, for whatever it's worth,
is why we're interested in namespaced keyrings for containers). Our
privilege separation mechanism (gssproxy) is cache-type agnostic, and we
do have other credential cache types (KCM and DIR/FILE) in the
implementation.
Thanks,
--Robbie
--
Robbie Harwood
Kerberos Development Lead
Security Engineering Team
Red Hat, Inc.
Boston, MA, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Andy Lutomirski @ 2019-09-06 20:06 UTC (permalink / raw)
To: Jeff Layton
Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <e1ac9428e6b768ac3145aafbe19b24dd6cf410b9.camel@kernel.org>
> On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
>
>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>> 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.
>>>>
>>>
>>> Well...maybe. What about existing programs that are sending down bogus
>>> open flags? Once you turn this on, they may break...or provide a way to
>>> circumvent the protections this gives.
>>
>> It should be noted that this has been a valid concern for every new O_*
>> flag introduced (and yet we still introduced new flags, despite the
>> concern) -- though to be fair, O_TMPFILE actually does have a
>> work-around with the O_DIRECTORY mask setup.
>>
>> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
>> backwards compatible because empty path strings have always given ENOENT
>> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
>>
>>> Maybe this should be a new flag that is only usable in the new openat2()
>>> syscall that's still under discussion? That syscall will enforce that
>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>> went that route too.
>>
>> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
>> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
>> it, since I'd heard about this work through the grape-vine).
>>
>
> I rather like the idea of having openat2 fds be non-executable by
> default, and having userland request it specifically via O_MAYEXEC (or
> some similar openat2 flag) if it's needed. Then you could add an
> UPGRADE_EXEC flag instead?
>
> That seems like something reasonable to do with a brand new API, and
> might be very helpful for preventing certain classes of attacks.
>
>
There are at least four concepts of executability here:
- Just check the file mode and any other relevant permissions. Return a normal fd. Makes sense for script interpreters, perhaps.
- Make the fd fexecve-able.
- Make the resulting fd mappable PROT_EXEC.
- Make the resulting fd upgradable.
I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Jeff Layton @ 2019-09-06 20:51 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <D2A57C7B-B0FD-424E-9F81-B858FFF21FF0@amacapital.net>
On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
> >
> > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > 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.
> > > > >
> > > >
> > > > Well...maybe. What about existing programs that are sending down bogus
> > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > circumvent the protections this gives.
> > >
> > > It should be noted that this has been a valid concern for every new O_*
> > > flag introduced (and yet we still introduced new flags, despite the
> > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > work-around with the O_DIRECTORY mask setup.
> > >
> > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > backwards compatible because empty path strings have always given ENOENT
> > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > >
> > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > syscall that's still under discussion? That syscall will enforce that
> > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > went that route too.
> > >
> > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > it, since I'd heard about this work through the grape-vine).
> > >
> >
> > I rather like the idea of having openat2 fds be non-executable by
> > default, and having userland request it specifically via O_MAYEXEC (or
> > some similar openat2 flag) if it's needed. Then you could add an
> > UPGRADE_EXEC flag instead?
> >
> > That seems like something reasonable to do with a brand new API, and
> > might be very helpful for preventing certain classes of attacks.
> >
> >
>
> There are at least four concepts of executability here:
>
> - Just check the file mode and any other relevant permissions. Return a normal fd. Makes sense for script interpreters, perhaps.
>
> - Make the fd fexecve-able.
>
> - Make the resulting fd mappable PROT_EXEC.
>
> - Make the resulting fd upgradable.
>
> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
Good point. Upgradability is definitely orthogonal, though the idea
there is to alter the default behavior. If the default is NOEXEC then
UPGRADE_EXEC would make sense.
In any case, I was mostly thinking about the middle two in your list
above. After more careful reading of the patches, I now get get that
Mickaël is more interested in the first, and that's really a different
sort of use-case.
Most opens never result in the fd being fed to fexecve or mmapped with
PROT_EXEC, so having userland explicitly opt-in to allowing that during
the open sounds like a reasonable thing to do.
But I get that preventing execution via script interpreters of files
that are not executable might be something nice to have.
Perhaps we need two flags for openat2?
OA2_MAYEXEC : test that permissions allow execution and that the file
doesn't reside on a noexec mount before allowing the open
OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
was opened with this
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: Why add the general notification queue and its sources
From: David Howells @ 2019-09-06 21:19 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: dhowells, Linus Torvalds, Steven Whitehouse, Ray Strode,
Greg Kroah-Hartman, Nicolas Dichtel, raven, keyrings, linux-usb,
linux-block, Christian Brauner, LSM List, linux-fsdevel,
Linux API, Linux List Kernel Mailing, Al Viro, Ray, Debarshi,
Robbie Harwood
In-Reply-To: <20190906174102.GB2819@mit.edu>
Theodore Y. Ts'o <tytso@mit.edu> wrote:
> Something else which we should consider up front is how to handle the
> case where you have multiple userspace processes that want to
> subscribe to the same notification.
I have that.
> This also implies that we'll need to have some kind of standard header
> at the beginning to specify the source of a particular notification
> message.
That too.
David
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Andy Lutomirski @ 2019-09-06 21:27 UTC (permalink / raw)
To: Jeff Layton
Cc: Aleksa Sarai, Mickaël Salaün, Florian Weimer,
Mickaël Salaün, LKML, Alexei Starovoitov, Al Viro,
Andy Lutomirski, Christian Heimes, Daniel Borkmann, Eric Chiang,
James Morris, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Song Liu, Steve Dower, Steve Grubb, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, Kernel Hardening, Linux API,
LSM List, Linux FS Devel
In-Reply-To: <8dc59d585a133e96f9adaf0a148334e7f19058b9.camel@kernel.org>
> On Sep 6, 2019, at 1:51 PM, Jeff Layton <jlayton@kernel.org> wrote:
>
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
>
>> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
>
> Good point. Upgradability is definitely orthogonal, though the idea
> there is to alter the default behavior. If the default is NOEXEC then
> UPGRADE_EXEC would make sense.
>
> In any case, I was mostly thinking about the middle two in your list
> above. After more careful reading of the patches, I now get get that
> Mickaël is more interested in the first, and that's really a different
> sort of use-case.
>
> Most opens never result in the fd being fed to fexecve or mmapped with
> PROT_EXEC, so having userland explicitly opt-in to allowing that during
> the open sounds like a reasonable thing to do.
>
> But I get that preventing execution via script interpreters of files
> that are not executable might be something nice to have.
>
> Perhaps we need two flags for openat2?
>
> OA2_MAYEXEC : test that permissions allow execution and that the file
> doesn't reside on a noexec mount before allowing the open
>
> OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
> was opened with this
>
>
>
We could go one step farther and have three masks: check_perms,
fd_perms, and upgrade_perms. check_perms says “fail if I don’t have
these perms”. fd_perms is the permissions on the returned fd, and
upgrade_perms is the upgrade mask. (fd_perms & ~check_perms) != 0 is
an error. This makes it possible to say "I want to make sure the file
is writable, but I don't actually want to write to it", which could
plausibly be useful.
I would argue that these things should have new, sane bits, e.g.
FILE_READ, FILE_WRITE, and FILE_EXECUTE (or maybe FILE_MAP_EXEC and
FILE_EXECVE). And maybe there should be at least 16 bits for each
mask reserved. Windows has a lot more mode bits than Linux, and it's
not entirely nuts. We do *not* need any direct equivalent of O_RDWR
for openat2().
--Andy
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Aleksa Sarai @ 2019-09-06 22:05 UTC (permalink / raw)
To: Jeff Layton
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <e1ac9428e6b768ac3145aafbe19b24dd6cf410b9.camel@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > 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.
> > > >
> > >
> > > Well...maybe. What about existing programs that are sending down bogus
> > > open flags? Once you turn this on, they may break...or provide a way to
> > > circumvent the protections this gives.
> >
> > It should be noted that this has been a valid concern for every new O_*
> > flag introduced (and yet we still introduced new flags, despite the
> > concern) -- though to be fair, O_TMPFILE actually does have a
> > work-around with the O_DIRECTORY mask setup.
> >
> > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > backwards compatible because empty path strings have always given ENOENT
> > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> >
> > > Maybe this should be a new flag that is only usable in the new openat2()
> > > syscall that's still under discussion? That syscall will enforce that
> > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > went that route too.
> >
> > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > it, since I'd heard about this work through the grape-vine).
> >
>
> I rather like the idea of having openat2 fds be non-executable by
> default, and having userland request it specifically via O_MAYEXEC (or
> some similar openat2 flag) if it's needed. Then you could add an
> UPGRADE_EXEC flag instead?
>
> That seems like something reasonable to do with a brand new API, and
> might be very helpful for preventing certain classes of attacks.
In that case, maybe openat2(2) should default to not allowing any
upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.
However, I just noticed something else about this series -- if you do
O_PATH|O_MAYEXEC the new flag gets ignored. Given that you can do
fexecve(2) on an O_PATH (and O_PATHs have some other benefits), is this
something that we'd want to have?
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Aleksa Sarai @ 2019-09-06 22:12 UTC (permalink / raw)
To: Jeff Layton
Cc: Andy Lutomirski, Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <8dc59d585a133e96f9adaf0a148334e7f19058b9.camel@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5208 bytes --]
On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > > On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > > 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.
> > > > > >
> > > > >
> > > > > Well...maybe. What about existing programs that are sending down bogus
> > > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > > circumvent the protections this gives.
> > > >
> > > > It should be noted that this has been a valid concern for every new O_*
> > > > flag introduced (and yet we still introduced new flags, despite the
> > > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > > work-around with the O_DIRECTORY mask setup.
> > > >
> > > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > > backwards compatible because empty path strings have always given ENOENT
> > > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > >
> > > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > > syscall that's still under discussion? That syscall will enforce that
> > > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > > went that route too.
> > > >
> > > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > > it, since I'd heard about this work through the grape-vine).
> > > >
> > >
> > > I rather like the idea of having openat2 fds be non-executable by
> > > default, and having userland request it specifically via O_MAYEXEC (or
> > > some similar openat2 flag) if it's needed. Then you could add an
> > > UPGRADE_EXEC flag instead?
> > >
> > > That seems like something reasonable to do with a brand new API, and
> > > might be very helpful for preventing certain classes of attacks.
> > >
> > >
> >
> > There are at least four concepts of executability here:
> >
> > - Just check the file mode and any other relevant permissions. Return a normal fd. Makes sense for script interpreters, perhaps.
> >
> > - Make the fd fexecve-able.
> >
> > - Make the resulting fd mappable PROT_EXEC.
> >
> > - Make the resulting fd upgradable.
> >
> > I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
>
> Good point. Upgradability is definitely orthogonal, though the idea
> there is to alter the default behavior. If the default is NOEXEC then
> UPGRADE_EXEC would make sense.
>
> In any case, I was mostly thinking about the middle two in your list
> above. After more careful reading of the patches, I now get get that
> Mickaël is more interested in the first, and that's really a different
> sort of use-case.
>
> Most opens never result in the fd being fed to fexecve or mmapped with
> PROT_EXEC, so having userland explicitly opt-in to allowing that during
> the open sounds like a reasonable thing to do.
>
> But I get that preventing execution via script interpreters of files
> that are not executable might be something nice to have.
My first glance at the patch lead me to believe that this was about
blocking at fexecve()-time (which was what my first attempt at this
problem looked like) -- hence why I mentioned the upgrade_mask stuff
(because of the dances you can do with O_PATH, if blocking at
fexecve()-time was the goal then you seriously do need the upgrade_mask
and "O_PATH mask" in order for it to be even slightly secure).
But I also agree this is useful, and we can always add FMODE_EXEC,
FMODE_MAP_EXEC, and FMODE_UPGRADE_EXEC (and the related bits) at a later
date.
> Perhaps we need two flags for openat2?
>
> OA2_MAYEXEC : test that permissions allow execution and that the file
> doesn't reside on a noexec mount before allowing the open
>
> OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
> was opened with this
That seems reasonable to me. The only thing is that there currently
isn't any code to restrict fexecve() or PROT_EXEC in that fashion
(doubly so when you consider binfmt_script). So if we want to make
certain things default behaviour (such as disallowing exec by default)
we'd need to get the PROT_EXEC restriction work done first.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Aleksa Sarai @ 2019-09-06 22:18 UTC (permalink / raw)
To: Jeff Layton
Cc: Mickaël Salaün, Florian Weimer,
Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Al Viro, Andy Lutomirski, Christian Heimes, Daniel Borkmann,
Eric Chiang, James Morris, Jan Kara, Jann Horn, Jonathan Corbet,
Kees Cook, Matthew Garrett, Matthew Wilcox, Michael Kerrisk,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Song Liu, Steve Dower,
Steve Grubb, Thibaut Sautereau, Vincent Strubel,
Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel
In-Reply-To: <20190906220546.gkqxzm4y3ynevvtz@yavin.dot.cyphar.com>
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
On 2019-09-07, Aleksa Sarai <cyphar@cyphar.com> wrote:
> On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote:
> > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > 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.
> > > > >
> > > >
> > > > Well...maybe. What about existing programs that are sending down bogus
> > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > circumvent the protections this gives.
> > >
> > > It should be noted that this has been a valid concern for every new O_*
> > > flag introduced (and yet we still introduced new flags, despite the
> > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > work-around with the O_DIRECTORY mask setup.
> > >
> > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > backwards compatible because empty path strings have always given ENOENT
> > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > >
> > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > syscall that's still under discussion? That syscall will enforce that
> > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > went that route too.
> > >
> > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > it, since I'd heard about this work through the grape-vine).
> > >
> >
> > I rather like the idea of having openat2 fds be non-executable by
> > default, and having userland request it specifically via O_MAYEXEC (or
> > some similar openat2 flag) if it's needed. Then you could add an
> > UPGRADE_EXEC flag instead?
> >
> > That seems like something reasonable to do with a brand new API, and
> > might be very helpful for preventing certain classes of attacks.
>
> In that case, maybe openat2(2) should default to not allowing any
> upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
> UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.
Sorry, another issue is that there isn't a current way to really
restrict fexecve() permissions (from my [limited] understanding,
__FMODE_EXEC isn't the right thing to use) -- so we can't blanket block
exec through openat2() O_PATH descriptors and add UPGRADE_EXEC later.
We would have to implement FMODE_EXEC (and FMODE_MAP_EXEC as you
suggested) in order to implement FMODE_UPGRADE_EXEC before we could even
get a first version of openat2(2) in. Though, I do (a little
begrudgingly) agree that we should have a safe default if possible
(magical O_PATH reopening trickery is something that most people don't
know about and probably wouldn't want to happen if they did).
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox