I tried to come up with a one websocket per machine solution. But
couldn't come up with an option that wouldn't be fairly trivial to bypass.
We can't rely on different cookies with different cookie paths because
if the machine pages make a request for a different machines websocket
path the browser will happily include the cookie along for that path.
The only other identifying header we get for a websocket request is
Origin but doesn't contain any information about the path the connecting
Anything else we do, custom headers init messages, are pretty easy to
for machine pages to fake.
The only other option I can think of is that we add something to the
open payload. We keep the rest of the restrictions, ei no websockets
allow for non-localhost pages but instead of having the shell disallow
things we have cockpit.js add a value to all open commands when running
in iframe mode on a different machine. cockpit-ws can make access
decisions based on that. I'm not really sold on that idea though, it's
provide the info that cockpit-ws is using to make a access decision.
Hopefully I'm missing something and someone else has a better idea.
On 09/20/2017 11:02 PM, Stef Walter wrote:
On 21.09.2017 01:55, Peter wrote:
> I started putting together a plan on how we might be able to implement
> machine isolation in cockpit building off the somewhat stalled sandbox
> work that Stef started.
> I'd appreciate any comments or suggestions anyone might have.
access control (as did my WIP pull request). That is to say, it is a
channels to host A.
Do we have any options where we that access control happens in
options? How do they impact the user interface and backwards compatibility?
> cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org