Support a NOP run mode beyond virtual chalking

[nettrino]

Description

There are cases where for whatever reason a chalk bug could be affecting the build or execution of an image / binary etc. While we can do our best to safeguard against errors (see #188 and similar issues), we should offer a well-tested, robust nop mode of execution, where chalk only passes execution to the underlying command (e.g., if doing chalk docker build <args> to just do docker build <args>). This will be different than standard chalk operations like virtual chalking, in the sense that there will be

• no con4m related initialization or code executing
• no requirement for setup/env etc.
• no chalk flag like trace etc. respected

This will offer an easy escape path for users in case of critical bugs, as well as a quick debug flag to pinpoint whether an issue is related to chalk's side effects vs not.

Result

Define an environment variable (e.g., __CHALK_NOP), which, when set, will result in a completely separate path of execution, which is dependency free, and only calls execve with the underlying arguments passed to chalk.

[viega]

Well, before too long, the con4m code will always be pre-executed, except for the command line flag parsing, the user's config and a few other very minor things.

We could potentially skip user config loading there, but not the command line parsing.

And, if people want to disable across an entire machine, it seems like we'd WANT to respect that in the config file? The config file can (e.g., through a parameterized module) implement the environment variable semantics, but also let people just hardcode it off without worrying about the environment if necessary.

That to me seems like the best overall approach; using the info can happen before any other docker-related stuff happens (where bugs that need to be worked around are likely to be).

On Wed, Feb 28, 2024 at 4:18 AM Theofilos Petsios @.***> wrote:

Description

There are cases where for whatever reason a chalk bug could be affecting the build or execution of an image / binary etc. While we can do our best to safeguard against errors (see #188 https://github.com/crashappsec/chalk/issues/188 and similar issues), we should offer a well-tested, robust nop mode of execution, where chalk only passes execution to the underlying command (e.g., if doing chalk docker build to just do docker build ). This will be different than standard chalk operations like virtual chalking, in the sense that there will be

• no con4m related initialization or code executing
• no requirement for setup/env etc.
• no chalk flag like trace etc. respected

This will offer an easy escape path for users in case of critical bugs, as well as a quick debug flag to pinpoint whether an issue is related to chalk's side effects vs not. Result

Define an environment variable (e.g., __CHALK_NOP), which, when set, will result in a completely separate path of execution, which is dependency free, and only calls execve with the underlying arguments passed to chalk.

— Reply to this email directly, view it on GitHub https://github.com/crashappsec/chalk/issues/224, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABELGQKNDGKUSBHTDI7V2SLYV3Y65AVCNFSM6AAAAABD5UHD7CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2TQNBXHE3TSNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[nettrino]

You mean that con4m code will always be pre-executed before anything else in chalk? The DoD for this request was to completely bypass as much as possibly from the con4m or chalk codebase

[viega]

100%. 99% of the con4m code is data structure setup that can all run statically, and then be frozen in memory until needed basically.

My point is that it soon will not be bypassing much actual work to bypass the con4m execution, and it's unclear there are benefits from doing so, since that's currently responsible for the user interface for options like this...

It's very easy to avoid all of the work Chalk would do though, so I see it as very reasonable to add a bypass mode, I just am not convinced that it should bypass the core con4m load.

I think for skipping the user-defined con4m config load, what's in place already would also suffice. So for me, bypass mode would be about bypassing all chalk processing.

[miki725]

right, with con4m v2 it will remove a lot of the loading complexity.

for now I guess we can def add support for some env var to bypass things like loading custom configs, sinks/etc. basically with that env var chalk should not do anything error-prone such as doing network calls/etc

once we have v2 I think we can make the bypass a lot more comprehensive

[viega]

Is it critical to address before we migrate???

On Thu, Feb 29, 2024 at 2:22 PM Miroslav Shubernetskiy < @.***> wrote:

right, with con4m v2 it will remove a lot of the loading complexity.

for now I guess we can def add support for some env var to bypass things like loading custom configs, sinks/etc. basically with that env var chalk should not do anything error-prone such as doing network calls/etc

once we have v2 I think we can make the bypass a lot more comprehensive

— Reply to this email directly, view it on GitHub https://github.com/crashappsec/chalk/issues/224#issuecomment-1971809262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABELGQK2DGYLCJEC5ZFHE5LYV57XVAVCNFSM6AAAAABD5UHD7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRHAYDSMRWGI . You are receiving this because you commented.Message ID: @.***>