Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[MickaÃl SalaÃn]

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.

>
> 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@xxxxxxxxxxxxx/

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

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

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

>
>>> Do we need a different way for recognizing kernel support.  (Note that
>>> we cannot probe paths in /proc for various reasons.)
>>
>> There is no need to probe for kernel support.
>>
>>> Thanks,
>>> Florian
>>>
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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx If you have received this message in error, we thank you for informing the sender and destroying the message.