It seems if you do it that way - you get all or nothing. Meaning if you have access to the socket - you can issue any command that is registered, and also start/stop any service with no further access controls.
Still, I looked at the code you referenced, and if you look at the caller here https://github.com/canonical/pebble/blob/727a82ae61756dca123d4e3a4b5d99b78f6e4bd8/internal/daemon/daemon.go#L221 It appears the user will always be nil - as userFromRequest() always returns nil - and no user authorization or access checking will be attempted. Unless I am missing something? Maybe the github source browser isn’t cross referencing as I would expect. I would be very careful using a service orchestration system that hasn’t had a full security audit - there are almost backdoors lurking that can be exposed. > On Nov 23, 2022, at 4:19 PM, Ben Hoyt <benh...@gmail.com> wrote: > > I presume you're referring to API access? I wasn't around when the initial > API and access control stuff was designed (it's inherited from snapd), but > here's my understanding of how it works. The bulk of the API is exposed using > HTTP-over-unix-socket, so is only accessible if you have permission to access > the unix socket file. The access control handling code is at > https://github.com/canonical/pebble/blob/727a82ae61756dca123d4e3a4b5d99b78f6e4bd8/internal/daemon/daemon.go#L153 > > <https://github.com/canonical/pebble/blob/727a82ae61756dca123d4e3a4b5d99b78f6e4bd8/internal/daemon/daemon.go#L153> > > There are a couple of API endpoints exposed via ordinary HTTP-over-TCP if you > specify the "-http" command line arg, but those are very narrow, basically > the "health" endpoint which returns true/false. See the two "GuestOK: true" > endpoints here: > https://github.com/canonical/pebble/blob/727a82ae61756dca123d4e3a4b5d99b78f6e4bd8/internal/daemon/api.go#L27 > > <https://github.com/canonical/pebble/blob/727a82ae61756dca123d4e3a4b5d99b78f6e4bd8/internal/daemon/api.go#L27> > > We use Pebble mostly in a Kubernetes context with a sidecar container in the > pod talking to Pebble in another container in the same pod. This is done via > the unix socket file in the Pebble container which is mounted in the sidecar > container. People outside the pod can only access the GuestOK health endpoint > (we use this for Kubernetes probes). > > Thanks for taking a look. We may well be missing something! > > -Ben > > > On Thu, Nov 24, 2022 at 10:41 AM Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > I took a look at Pebble. I don’t see anything related to auth and credentials > and it seems like a huge back door security hole. > > Did I miss something? > >> On Nov 23, 2022, at 3:20 PM, ben...@gmail.com <mailto:ben...@gmail.com> >> <benh...@gmail.com <mailto:benh...@gmail.com>> wrote: >> >> >> Part of my day job is working on Canonical's "Pebble" >> (https://github.com/canonical/pebble <https://github.com/canonical/pebble>), >> a simple service manager written in Go. Unique features: layered >> configuration, and an HTTP-over-unix-socket API. It's GPLv3 licensed. >> >> -Ben > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAL9jXCEYnaZtuZFJC%3Da0mUXo6dU3ze6j89MEKGHWuvk3HEhC6g%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAL9jXCEYnaZtuZFJC%3Da0mUXo6dU3ze6j89MEKGHWuvk3HEhC6g%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/76EE0DA4-52E4-43B5-98ED-3C566747206E%40ix.netcom.com.
