fix env bug

[ningmingxiao]

export  _LIBCONTAINER_INITPIPE=1111
root@LIN-FB738BFD367 runc]# runc list
FATAL: could not inform the parent we are past initial setup: Bad file descriptor

[root@LIN-FB738BFD367 runc]# ./runc -v
FATAL: could not inform the parent we are past initial setup: Bad file descriptor

[root@LIN-FB738BFD367 mycontainer]# ./runc run  test001
FATAL: could not inform the parent we are past initial setup: Bad file descriptor

[ningmingxiao]

can this assign a cve ?

[cyphar]

This PR just makes it so that setting _LIBCONTAINER_INIT will cause the same issue you are describing. Why do you need to set environment variables with the name _LIBCONTAINER_? Those environment variables are reserved for our use...

can this assign a cve ?

As far as I can see, this isn't a security issue:

1. If you can modify the environment of a root process, you can also use LD_PRELOAD to run code with the privileges of the binary. An attacker being able to arbitrarily modify the environment of a root process is outside of the threat model of most Linux programs (there is an exception for setuid binaries, but runc is not a setuid binary).
2. I don't see a security issue that could be triggered by changing the file descriptor used for the init pipe. You could modify the configuration used by the container, but if you have the ability to modify the environment of runc you probably also have enough privileges to configure containers.

Also, if wish to report a security issue, please send a mail to [email protected].

[ningmingxiao]

This PR just makes it so that setting _LIBCONTAINER_INIT will cause the same issue you are describing. Why do you need to set environment variables with the name _LIBCONTAINER_?

can this assign a cve ?

As far as I can see, this isn't a security issue:

1. If you can modify the environment of a root process, you can also use LD_PRELOAD to run code with the privileges of the binary. An attacker being able to arbitrarily modify the environment of a root process is outside of the threat model of most Linux programs (there is an exception for setuid binaries, but runc is not a setuid binary).
2. I don't see a security issue that could be triggered by changing the file descriptor used for the init pipe. You could modify the configuration used by the container, but if you have the ability to modify the environment of runc you probably also have enough privileges to configure containers.

Also, if wish to report a security issue, please send a mail to [email protected].

yes ,you are rignt but if use this pr I can just let shim or containerd use os.Unsetenv("_LIBCONTAINER_INIT") to clear env ,so children runc will not inherit env _LIBCONTAINER_INIT, runc will work well, otherwise I have to clear many env like _LIBCONTAINER_INITPIPE _LIBCONTAINER_LOGPIPE _LIBCONTAINER_LOGLEVEL and so on. I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

[cyphar]

I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

You could use /proc/self/cmdline to get argv. I'm not a huge fan of the idea, but I don't see how it could cause issues (we always use /proc/self/exe init to spawn the init, and as long as we ignore argv[0] it should be fine).

[cyphar]

Also, this isn't a golang issue -- our usage of __attribute__((constructor)) is something Go doesn't really like supporting, so opening issues against the Go repo won't get a positive reaction IMHO.

[kolyshkin]

yes ,you are rignt but if use this pr I can just let shim or containerd use os.Unsetenv("_LIBCONTAINER_INIT") to clear env ,so children runc will not inherit env _LIBCONTAINER_INIT, runc will work well, otherwise I have to clear many env like _LIBCONTAINER_INITPIPE _LIBCONTAINER_LOGPIPE _LIBCONTAINER_LOGLEVEL and so on. I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

This is not a good enough motivation. See, nsenter can be easily modified to

• only depend on _LIBCONTAINER_INITPIPE to continue;
• ignore all errors from not being able to parse it.

and you will only have to unset _LIBCONTAINER_INITPIPE.

In general, though, runc reserves all environment variables that start with _LIBCONTAINER_, and those are not supposed to be set.

[ningmingxiao]

yes ,you are rignt but if use this pr I can just let shim or containerd use os.Unsetenv("_LIBCONTAINER_INIT") to clear env ,so children runc will not inherit env _LIBCONTAINER_INIT, runc will work well, otherwise I have to clear many env like _LIBCONTAINER_INITPIPE _LIBCONTAINER_LOGPIPE _LIBCONTAINER_LOGLEVEL and so on. I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

This is not a good enough motivation. See, nsenter can be easily modified to

• only depend on _LIBCONTAINER_INITPIPE to continue;
• ignore all errors from not being able to parse it.

and you will only have to unset _LIBCONTAINER_INITPIPE.

In general, though, runc reserves all environment variables that start with _LIBCONTAINER_, and those are not supposed to be set.

how about my new pr? following code have high-priority than custom env

cmd.Env = append(cmd.Env,
		"_LIBCONTAINER_INITPIPE="+strconv.Itoa(stdioFdCount+len(cmd.ExtraFiles)-1),
	)

we just need check whether we are in init is ok, by reading "/proc/self/cmdline".

[ningmingxiao]

This PR just makes it so that setting _LIBCONTAINER_INIT will cause the same issue you are describing. Why do you need to set environment variables with the name _LIBCONTAINER_?

can this assign a cve ?

As far as I can see, this isn't a security issue:

1. If you can modify the environment of a root process, you can also use LD_PRELOAD to run code with the privileges of the binary. An attacker being able to arbitrarily modify the environment of a root process is outside of the threat model of most Linux programs (there is an exception for setuid binaries, but runc is not a setuid binary).
2. I don't see a security issue that could be triggered by changing the file descriptor used for the init pipe. You could modify the configuration used by the container, but if you have the ability to modify the environment of runc you probably also have enough privileges to configure containers.

Also, if wish to report a security issue, please send a mail to [email protected].

If mount /etc/profile into container, user can change profile. maybe it is dangerous.

[cyphar]

@ningmingxiao Modifying the config.json to allow host access is not a security issue, it's a misconfiguration. You can also bind-mount the entire host filesystem into the container if you really want to. I would recommend not doing that.

[ningmingxiao]

how about my new pr ? I try to get args from cmdline .Thank you @cyphar @kolyshkin

[rata]

yes ,you are rignt but if use this pr I can just let shim or containerd use os.Unsetenv("_LIBCONTAINER_INIT") to clear env ,so children runc will not inherit env _LIBCONTAINER_INIT, runc will work well, otherwise I have to clear many env like _LIBCONTAINER_INITPIPE _LIBCONTAINER_LOGPIPE _LIBCONTAINER_LOGLEVEL and so on. I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

I'm unsure what you mean here. What is the issue exactly? Is it that you see those env vars when you don't expect them to be set? How are you running and where is exactly that you see them?

[ningmingxiao]

yes ,you are rignt but if use this pr I can just let shim or containerd use os.Unsetenv("_LIBCONTAINER_INIT") to clear env ,so children runc will not inherit env _LIBCONTAINER_INIT, runc will work well, otherwise I have to clear many env like _LIBCONTAINER_INITPIPE _LIBCONTAINER_LOGPIPE _LIBCONTAINER_LOGLEVEL and so on. I try to let nsexec receive args, but I can't find any way, because args must received in main func in c code.

I'm unsure what you mean here. What is the issue exactly? Is it that you see those env vars when you don't expect them to be set? How are you running and where is exactly that you see them?

I study runc code ,I find runc command will run c(nsexec.c) code every time(like runc version runc --help ). nsexec.c is designed just for runc-init. I find custom env will cause runc err. another pr I split runc-init from runc. https://github.com/opencontainers/runc/pull/4343 will use less memeory and run more quickly than before,

[rata]

Thanks for the clarification.

[kolyshkin]

I tried fixing the same bug (#4340) in #4342 but in there we decided it's not worth it. Same about this one.