RFC New configuration parameter to strengthen native executables

[Foivos Zakkak]

Hello all,

As reported in https://github.com/quarkusio/quarkus/issues/33524 there
are cases where people are willing to trade some performance for
increased security and Quarkus seems to get in the way.

I am thinking about introducing a `quarkus.native.hardening` option to
enable users to do this. This option would initially replace
`--no-pie` with `--pie` and would possibly add further parameters in
the future.

I am not sure though whether that would be a good idea. What if a user
needs a different hardening configuration than the Quarkus'
opinionated hardening configuration?

Should we instead (or in addition to the above) introduce an
"advanced" mode where Quarkus doesn't pass any parameters
automatically and gives full control to the user?

WDYT?

Regards
--
Foivos Zakkak
Senior Software Engineer, R&D Product Middleware
Red Hat
7B4069D929BAAE91C0B3220A0846BFD103F04EA1

[Georgios Andrianakis]

Why don't we just create a Quarkus configuration option for that specific GraalVM flag instead of introducing something that is overloaded and requires explanation (and while also opening the door for adding further GraalVM flags in the future which would be even more confusing)?

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CA%2BXL9jFGCh25MQq-mOXYXB5z%2B%3DsOVom91%2Bvcya10H7Aro%2BviAQ%40mail.gmail.com.

[Foivos Zakkak]

AFAIK Quarkus' strategy is to avoid as much as possible configuration
options specific to a GraalVM flags.
The reason for this is that non-public GraalVM flags (like the ones
starting with `-H:` change overtime and we would thus prefer Quarkus
configuration options to be more generic so that they remain relevant
over time, i.e., the way we do the hardening might change overtime,
but hardening is a concept that won't go away.

[Max Rydahl Andersen]

AFAIK Quarkus' strategy is to avoid as much as possible configuration
options specific to a GraalVM flags.
The reason for this is that non-public GraalVM flags (like the ones
starting with `-H:` change overtime and we would thus prefer Quarkus
configuration options to be more generic so that they remain relevant
over time, i.e., the way we do the hardening might change overtime,
but hardening is a concept that won't go away.

So you are thinking for this specific case we could have a config for pie which is default 'falseand users can toggle totrue` and
we could then do the "right thing" over time?

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CA%2BXL9jGhu7quDSaKxO5iSjXyagC6F5XZmczxo1jqRhFiwUc%3DWQ%40mail.gmail.com.

[Foivos Zakkak]

On Thu, May 25, 2023 at 1:31 PM Max Rydahl Andersen <mand...@redhat.com> wrote:
>
> AFAIK Quarkus' strategy is to avoid as much as possible configuration
> options specific to a GraalVM flags.
> The reason for this is that non-public GraalVM flags (like the ones
> starting with `-H:` change overtime and we would thus prefer Quarkus
> configuration options to be more generic so that they remain relevant
> over time, i.e., the way we do the hardening might change overtime,
> but hardening is a concept that won't go away.
>
> So you are thinking for this specific case we could have a config for pie which is default 'falseand users can toggle totrue` and
> we could then do the "right thing" over time?
>

Correct, there is no intention to do a hardening research and add all
possible flags at the moment. For now it would be just `pie` vs
`no-pie`.

[Georgios Andrianakis]

On Thu, May 25, 2023, 14:51 Foivos Zakkak <fza...@redhat.com> wrote:

On Thu, May 25, 2023 at 1:31 PM Max Rydahl Andersen <mand...@redhat.com> wrote:
>
> AFAIK Quarkus' strategy is to avoid as much as possible configuration
> options specific to a GraalVM flags.
> The reason for this is that non-public GraalVM flags (like the ones
> starting with `-H:` change overtime and we would thus prefer Quarkus
> configuration options to be more generic so that they remain relevant
> over time, i.e., the way we do the hardening might change overtime,
> but hardening is a concept that won't go away.
>
> So you are thinking for this specific case we could have a config for pie which is default 'falseand users can toggle totrue` and
> we could then do the "right thing" over time?
>

Correct, there is no intention to do a hardening research and add all
possible flags at the moment. For now it would be just `pie` vs
`no-pie`.

I would personally only add this hardening flag when we come across another GraalVM flag that is related.

[Manyanda Chitimbo]

> I would personally only add this hardening flag when we come across another GraalVM flag that is related.

+1 from me on this point! 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3D96SsZZZB%2BXLrKP%2BDB0yiLkgVvi5_wXKaTqxH7-hhU4g%40mail.gmail.com.

--

Manyanda Chitimbo.

[Sergey Beryozkin]

Hi Everyone

If we want to pursue a Secure By Default strategy across multiple security related angles, not only some specific extensions, then enabling a hardening pie option by default should be seriously considered.

In the article linked to by Foivos, https://www.redhat.com/en/blog/position-independent-executable-pie-performance, last paragraph,

the opinion is, the performance side-effect is negligible (I'm hiding now, knowing how critical the performance is for Quarkus :-) )

Cheers Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANwCmXK6KYJBkBAGPd2s97R0Fe6x16VRichZyLE_b1NTVZSoqQ%40mail.gmail.com.