Machines Isolation

[Peter]

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.

https://github.com/cockpit-project/cockpit/wiki/Machine-isolation

I'd appreciate any comments or suggestions anyone might have.

[Stef Walter]

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.
>
> https://github.com/cockpit-project/cockpit/wiki/Machine-isolation
>
> I'd appreciate any comments or suggestions anyone might have.

This seems to rely on javascript in the shell component for implementing
access control (as did my WIP pull request). That is to say, it is a
javascript component that prevents host B's javascript from opening
channels to host A.

Do we have any options where we that access control happens in
cockpit-ws and not in javascript? If so, how complicated are those
options? How do they impact the user interface and backwards compatibility?

Cheers,

Stef
> cockpit-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Peter]

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 
javascript was running on.

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 
still relying on a javascript component rather than the browser to 
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.
> >
> > https://github.com/cockpit-project/cockpit/wiki/Machine-isolation
> >
> > I'd appreciate any comments or suggestions anyone might have.
>
> This seems to rely on javascript in the shell component for implementing
> access control (as did my WIP pull request). That is to say, it is a
> javascript component that prevents host B's javascript from opening
> channels to host A.
>
> Do we have any options where we that access control happens in
> cockpit-ws and not in javascript? If so, how complicated are those
> options? How do they impact the user interface and backwards compatibility?
>
> Cheers,
>
> Stef
> > cockpit-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Martin Pitt]

Hello Peter,

Peter [2017-09-20 16:55 -0700]:
> 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.
>
> https://github.com/cockpit-project/cockpit/wiki/Machine-isolation

I don't understand the "packages can never have the same checksum" implication.
Is that because our checksum → package map is global and it would load the
files from (potentially) the wrong machine?

Using the exact same cockpit RPMs on multiple machines is certainly a common
use case. Can the checksum map be prefixed with the host name, assuming
"localhost" if the prefix is empty (for protocol backwards compatibility)?

Martin