On 09/09/2019 14:28, Aleksa Sarai wrote:
> On 2019-09-09, Mickaël Salaün <mickael.salaun@xxxxxxxxxxx> wrote:
>> On 09/09/2019 12:12, James Morris wrote:
>>> On Mon, 9 Sep 2019, Mickaël Salaün wrote:
>>>> As I said, O_MAYEXEC should be ignored if it is not supported by the
>>>> kernel, which perfectly fit with the current open(2) flags behavior, and
>>>> should also behave the same with openat2(2).
>>>
>>> The problem here is programs which are already using the value of
>>> O_MAYEXEC, which will break. Hence, openat2(2).
>>
>> Well, it still depends on the sysctl, which doesn't enforce anything by
>> default, hence doesn't break existing behavior, and this unused flags
>> could be fixed/removed or reported by sysadmins or distro developers.
>
> Okay, but then this means that new programs which really want to enforce
> O_MAYEXEC (and know that they really do want this feature) won't be able
> to unless an admin has set the relevant sysctl. Not to mention that the
> old-kernel fallback will not cover the "it's disabled by the sysctl"
> case -- so the fallback handling would need to be:
>
> int fd = open("foo", O_MAYEXEC|O_RDONLY);
> if (!(fcntl(fd, F_GETFL) & O_MAYEXEC))
> fallback();
> if (!sysctl_feature_is_enabled)
> fallback();
>
> However, there is still a race here -- if an administrator enables
> O_MAYEXEC after the program gets the fd, then you still won't hit the
> fallback (and you can't tell that O_MAYEXEC checks weren't done).
I just replied to this concern here:
https://lore.kernel.org/lkml/70e4244e-4dfb-6e67-416b-445e383aa1b5@xxxxxxxxxxx/
>
> You could fix the issue with the sysctl by clearing O_MAYEXEC from
> f_flags if the sysctl is disabled. You could also avoid some of the
> problems with it being a global setting by making it a prctl(2) which
> processes can opt-in to (though this has its own major problems).
Security definition and enforcement should be manageable by sysadmins
and distro developers.
>
> Sorry, but I'm just really not a fan of this.
I guess there is some misunderstanding. I just replied to another thread
and I think it should answer your concerns (especially about the PDP and
PEP):
https://lore.kernel.org/lkml/70e4244e-4dfb-6e67-416b-445e383aa1b5@xxxxxxxxxxx/
--
Mickaël Salaün
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@xxxxxxxxxxxxx. 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@xxxxxxxxxxxxx. If you have received this message in error, we thank you for informing the sender and destroying the message.
