Making it possible to enable --preserve-env by default

[jandubois]

I think I would like to have --preserve-env enabled by default, but have it block variables that commonly include credentials.

More complex patterns

The first thing it would need is to extend the wildcard mechanism to allow a leading * as well, so we can write something like

export LIMA_SHELLENV_BLOCK=+*AUTH*,*TOKEN*,…

I would probably add all of these patterns to my list:

*API*
*AUTH*
*CRED*
*DATABASE*
*ENCR*
*KEY*
*PASS*
*PRIVATE*
*SECRET*
*SIGNING*
*TOKEN*

Let me know if I missed anything commonly used!

Enabling --preserve-env by default

For now I can define limactl-sh with the new alias feature that would set my extended block list and then invokes limactl shell --preserve-env "$@". That way I can use limactl sh FOO printenv and it would include most of my host environment.

If we want to offer this as a built-in feature, then we would need a better mechanism to enable it (maybe with another env variable). Not sure this is needed, but this is why I made this a discussion and not an issue. 😄

Using the allow list to create exceptions for the block list

Right now if LIMA_SHELLENV_ALLOW is defined, the block list is ignored. Anything not defined in the allow list is blocked.

But with my new more aggressive block list I may want to just allow a specific credential to pass though, e.g. GITHUB_TOKEN or OPENAI_API_KEY, together with my regular env variables, but still block all other credentials.

I haven't come up with a good mechanism to do this yet. Ideas so far:

• Use yet another env variable: LIMA_SHELLENV_BLOCK_NOT=GITHUB_TOKEN

  Name needs bike shedding. Not happy about explosion of env variables.

• Add a prefix to LIMA_SHELLENV_ALLOW similar how we have the + prefix option on LIMA_SHELLENV_BLOCK: LIMA_SHELLENV_ALLOW=+GITHUB_TOKEN.

  It is breaking the concept that everything not explicitly allowed is blocked. The + has a different meaning here than on the block list, may need a different special character.

• Allow another prefix in the block list: LIME_SHELLENV_BLOCK=-GITHUB_TOKEN,+*TOKEN*

  All variables in the - list would not be blocked, even if they match a pattern in the + list. Could be used to also remove single entries from the default block list.
  Turns the setting into a mini-language that might be hard to understand.

All options feel too complicated to me, but I haven't been able to come up with something simpler that is still flexible enough.

[jandubois]

But with my new more aggressive block list I may want to just allow a specific credential to pass though

Another way would be to add another option: limactl shell --preserve-env --add-env GITHUB_TOKEN $INSTANCE gh …

Variables specified in --add-env would never be blocked by the blocklist.

Could use some bike-shedding for the option name, but this is probably easiest to understand for the user (compared to adding more env variables, or turning their values into mini-languages).

[jandubois]

Random thought (probably should sleep on it):

Rename LIMA_SHELLENV_ALLOW into LIMA_SHELLENV_ONLY to make it clear that only the variables specified here are preserved.

And then we can use --preserve-env --allow-env GITHUB_TOKEN to specify exceptions to the block list, without confusing it with the "only" list specified by the env variable.

• If LIMA_SHELLENV_ONLY is set then the --allow-env is added to the list.
• If it is not set, then --allow-env will not be filtered by the block list.

Right now I think this is my best suggestion so far.

[cruatta]

Hey @jandubois thanks first and foremost for working on Lima. I'm a user and I love it.

I want to share my thoughts specifically on enabling --preserve-env by default. I think this would be a step backwards in Lima being secure by default and also make it difficult to configure Lima for my use case.

I use Lima to create isolated development and sandbox environments. I disable the default read only home directory mount for every VM because my home directory contains Documents, Pictures, Videos, etc that have no bearing being in my development environment. I only mount in exactly what I need. I feel the same way about environment variables. --preserve-env by default will cause other users like me to forward environment variables to their VMs where they don't need to propagate.

With --preserve-env on by default, it's not clear to me how to configure my host environment to forward nothing at all to each VM when I shell in. Will I need LIMA_SHELLENV_BLOCK="*" in my host environment at all times? While I'm also sure while the blacklist will cover many use cases, it will not catch everything for everyone.

I hope I get you to reconsider making this a default. Otherwise I'd ask you to consider making it easy for me to disable this behavior via the config for each of my VMs.

[jandubois]

@cruatta I've probably not worded things carefully enough; there would always be some kind of opt-in mechanism required to enabled --preserve-env "by default".

What I'm looking for was/is some way to specify a more extensive blocklist that would block all the typical secrets. And by specifying that this extended block list should be used, I would signal that --preserve-env should become the default.

Since we don't really have any app config settings, this most likely would have to be an environment variable.

To complicate this further, because the block list would be so exhaustive, I would need a mechanism to explicitly allow one of the blocked variables, but just for this invocation. The allow list doesn't work for it, because it does not define an exception to the block list, but provides the comprehensive list of allowed variables, everything else is blocked.

That's why I suggested to rename the current "allow" list to an "only" list, to make the term "allow" available to specify exceptions.

But this still does not answer how you specify the extended block list. Maybe use another prefix character:

# use extended block list and enable --preserve-env by default
export LIMA_SHELLENV_BLOCK=!

# Add additional entries on top of the extended block list and enable --preserve-env by default
export LIMA_SHELLENV_BLOCK=!FOO*

# Add additional entries to regular block list, does not enable --preserve-env by default
export LIMA_SHELLENV_BLOCK=+FOO*

# Replace block list with custom list, does not enable --preserve-env by default
export LIMA_SHELLENV_BLOCK=FOO*

Maybe we should redefine LIMA_SHELLENV_ALLOW to just defines exceptions to the block list. The current behaviour would still be available by setting LIMA_SHELLENV_BLOCK=*, blocking everything.

I think this is my new favourite suggestion because it keeps the number of variables down to 2.

I'll see what kind of feedback I get here. If I don't get any, and still think this is a good idea tomorrow, or later this week, then I'll turn it into an issue. 😄

---

The suggestion is still a bit irregular: there is no way to replace the extended block list completely and still enable --preserve-env by default.

If we wanted this, do we then also need a way to just replace the extended patterns, but keep the default blocks? This quickly becomes too complicated.

And the user can just add the pattern to LIMA_SHELLENV_ALLOW to effectively remove it from the block list.

[jandubois]

I have added the change requests that are hopefully uncontroversial to #4036 and hope we can still add them before the 2.0 release.

The remaining ideas, like the extended block lists and triggering an automatic --preserve-env based on env settings can then be implemented later without breaking backwards compatibility. I don't think these ideas should be squeezed in before the 2.0 release, but may need some more time to "ripen"...

[cruatta]

@jandubois I just wanted to say thanks for the explanation. I definitely just misunderstood the proposed change.