ArmyCyberInstitute / cmgr

CTF Challenge Manager
Apache License 2.0
18 stars 9 forks source link

Interface not being honored. #18

Closed h00die closed 3 years ago

h00die commented 3 years ago

https://github.com/ArmyCyberInstitute/cmgr/blob/master/cmgr/types.go#L17 shows CMGR_INTERFACE

https://github.com/ArmyCyberInstitute/cmgr/blob/master/README.md#configuration shows CMGR_IFACE

However, neither seem to actually be honored.

ubuntu@ubuntu2004:~/challenges$ sudo echo $CMGR_IFACE
192.168.0.5
ubuntu@ubuntu2004:~/challenges$ sudo echo $CMGR_INTERFACE
192.168.0.5
ubuntu@ubuntu2004:~/challenges$ sudo cmgr playtest example/example/example
challenge running at: http://localhost:4242/
jrolli commented 3 years ago

Thanks for the issue. The documentation is out-of-date and CMGR_INTERFACE is the correct environment variable and I'll update that today.

For the playtest portal itself, I'm updating it to use CMGR_INTERFACE as well, but I also want to state that the playtest really only intended for local testing and has some rough edges when using the variable. In particular, Docker does not emit any errors if you request to bind to a non-existent interface and instead silently binds only on loopback (which will break the displayed links).

jrolli commented 3 years ago

Behavior updated in v0.8.7.

h00die commented 3 years ago

I'm a little confused still. I've tried setting an actual interface, as well as the IP to that interface. Neither seemed to make a difference with 0.8.7.

interface

ubuntu@ubuntu2004:~/challenges$ ip addr show ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether REDACTED brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.5/24 brd 192.168.0.255 scope global dynamic ens160
       valid_lft 53138sec preferred_lft 53138sec
    inet6 REDACTED/64 scope link
       valid_lft forever preferred_lft forever
ubuntu@ubuntu2004:~/challenges$ CMGR_INTERFACE=ens160
ubuntu@ubuntu2004:~/challenges$ sudo echo $CMGR_INTERFACE
ens160
ubuntu@ubuntu2004:~/challenges$ sudo cmgr playtest example/example/example
challenge information available at: http://localhost:4242/

ip

ubuntu@ubuntu2004:~/challenges$ CMGR_INTERFACE=192.168.0.5
ubuntu@ubuntu2004:~/challenges$ sudo echo $CMGR_INTERFACE
192.168.0.5
ubuntu@ubuntu2004:~/challenges$ sudo cmgr playtest example/example/example
challenge information available at: http://localhost:4242/
jrolli commented 3 years ago

I think the issue you are seeing now is that you are only setting the variable in the shell (bash) and not the actual environment (if you replace your echo $CMGR_LOGGING with env | grep CMGR_LOGGING I suspect you won't get anything). Since the variable is not a proper environment variable, it is not get replicated into child process environments (like the call to cmgr).

Either of the following two setups should work. The main difference is that in the first example, all subsequent calls to cmgr will continue to see the environment variable (unless you explicitly use unset) whereas the second one did not affect the current shells environment at all.

Exporting the variable to child processes

CMGR_INTERFACE=192.168.0.5
export CMGR_INTERFACE
sudo cmgr playtest [...]

The additional export command tells the shell to add the variable to the environment which child processes inherit. Note: bash supports a condensed form of export CMGR_INTERFACE=192.168.0.5, but this is not required by POSIX and is not supported by some minimal shells.

Adding the variable directly to the child processes environment

CMGR_INTERFACE=192.168.0.5 sudo cmgr playtest [...]

This explicitly adds an environment variable to the child process' environment (technically, it is added to sudo's environment which is then copied to cmgr's environment when it is forked off).