Hey peanut gallery!
-
Hey peanut gallery! systemd-appd explained in a few sentences: https://blog.sebastianwick.net/posts/so-peerpidfd-gets-more-useful/
I will not take questions.
-
Hey peanut gallery! systemd-appd explained in a few sentences: https://blog.sebastianwick.net/posts/so-peerpidfd-gets-more-useful/
I will not take questions.
@swick one thing I do like about dedicated sockets (like security-context-v1) is that they're kinda capability-shaped (in the proper sense not the silly linux caps sense) (very vaguely and weakly but still).. But yeah, a general "what sandbox is on the other end of the socket" API is a very practical need right now
-
@swick one thing I do like about dedicated sockets (like security-context-v1) is that they're kinda capability-shaped (in the proper sense not the silly linux caps sense) (very vaguely and weakly but still).. But yeah, a general "what sandbox is on the other end of the socket" API is a very practical need right now
@valpackett @swick IMO security-context is closer to appd than to capabilities as you mean them. It's all about attaching the app's identity to the socket connection. The compositor knows who the app is and this can enforce policy on it
appd is the same thing, but made generic. Instead of having N protocol-specific ways to attach an app's identity to a given socket connection, we build out a mechanism to query an app's identity given any connection
Thus they're fundamentally the same thing
-
@valpackett @swick IMO security-context is closer to appd than to capabilities as you mean them. It's all about attaching the app's identity to the socket connection. The compositor knows who the app is and this can enforce policy on it
appd is the same thing, but made generic. Instead of having N protocol-specific ways to attach an app's identity to a given socket connection, we build out a mechanism to query an app's identity given any connection
Thus they're fundamentally the same thing
@AdrianVovk @swick right, you can attach metadata in security-context, but that's sort-of optional in practice? Many compositors don't really care about app identity, e.g. in Sway the only policy is "if connected from security-context, then hide all 'privileged' protocols like layer-shell", nothing more complicated, so effectively that new socket is a strictly-reduced-capability one vs. the original connection
-
@AdrianVovk @swick right, you can attach metadata in security-context, but that's sort-of optional in practice? Many compositors don't really care about app identity, e.g. in Sway the only policy is "if connected from security-context, then hide all 'privileged' protocols like layer-shell", nothing more complicated, so effectively that new socket is a strictly-reduced-capability one vs. the original connection
@valpackett @swick Sounds like anti-capabilities :p. Holding the special socket takes away your capability to do privileged actions, rather than granting you the capability to do the actions
Anyway on a more practical note the Wayland compositor can do exactly the same thing with appd. Check if the incoming client is any sandboxed app, if yes hide the privileged protocols, if no don't. No need to look at all the metadata if you don't need it. But boy is it useful to have right there if you do
-
Hey peanut gallery! systemd-appd explained in a few sentences: https://blog.sebastianwick.net/posts/so-peerpidfd-gets-more-useful/
I will not take questions.
@swick This is confusing. The blog post does not even mention the name systemd-appd. But it mentions that the method does not depend on systemd, nevertheless you name it systemd-appd. Is there some repo where we can have a look at it?
-
R relay@relay.infosec.exchange shared this topic
