Why do we limit the messages that can be sent to the conmon socket.

[rhatdan]

containers/buildah#5125 (comment)

A customer wants to be able to send messages other then the two that are allowed and would like to be able to define their own.

If we allow general messages through, does this cause a security risk?

If so then we could add a mechanism for the caller of conmon to pass down valid messages to be allowed to pass.

Thoughts?

[rhatdan]

@mrunalp @haircommander @vrothberg @alexlarsson @giuseppe WDYT?

[vrothberg]

Is there an issue/customer case to get some more context?

[rhatdan]

No, just came from a meeting with a customer, that would like to track via dbus other messages. In the original commit for this code, it was mentioned that this could be extended.

commit 59c2817b70746e78d5957d3c275e6385697224d1
Author: Joseph Gooch <mrwizard@dok.org>
Date:   Mon Aug 17 23:25:05 2020 +0000

    Refactor I/O and add SD_NOTIFY proxy support
    
    Refactored all the conn_sock functionality to be more generic. It can deal
    with different types of sockets, stream vs dgram, and reuses all the same
    callbacks, shutdown and async functionality.
    
    Conmon creates a notify socket which podman bind-mounts into the container,
    and passes in via the spec's environment variables.  Conmon relays the
    READY=1 signal.  This is similar to what runc and crun do, but doing it in
    conmon and NOT passing NOTIFY_SOCKET to the OCI runtime allows us to start
    up properly without runc and crun blocking on the "start" command.
    
    It would also be trivial to add more proxied sockets, i.e. the /dev/log
    proof of concept I did would now be super easy, if we wanted to revisit that.
    
    Signed-off-by: Joseph Gooch <mrwizard@dok.org>

[rhatdan]

They want to send messages like
CO_CONN_WAIT=1
CO_CONN_READY=1

I guess. Where CO is based on the company name.

[alexlarsson]

I think also outside of this particular customer, it would be nice to be able to use other standardized messages from https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#Description. For example STOPPING=1 or STATUS=Completed 66% of file system check..

[giuseppe]

I don't know the details, but when I added this logic to runc/crun/conmon, I asked Lennart if there are potential risks with doing so, and he told me that READY is safe. In fact systemd-nspawn is doing the same: https://github.com/systemd/systemd/blob/main/src/nspawn/nspawn.c#L4225-L4235

I see there that the STATUS= from the container is rewritten to "STATUS=Container running: %s", ...., we could do the same.

Not sure about the others. We can probably enable more of them if we think of the consequences of a rogue container that can forge that messages.

[alexlarsson]

STOPPING seems quite safe to me at least, and its been brought up by the customer.

[alexlarsson]

RELOADING, ERRNO, BUSERROR, MONOTONIC_USEC, EXTEND_TIMEOUT_USEC seems safe too

[giuseppe]

can EXTEND_TIMEOUT_USEC be abused to cause the container to run longer than it is supposed to do?

[alexlarsson]

@giuseppe Yeah, possibly... Maybe best to not include that, at least without some opt-in.

[rhatdan]

Yes lets eliminate that.