forked from cerc-io/plugeth
couple of fixes to docs in clef (#20900)
This commit is contained in:
parent
6a3daa2a4e
commit
671f22be38
@ -34,7 +34,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated
|
||||
|
||||
#### 1. Qubes Integrated
|
||||
|
||||
Qubes provdes a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request
|
||||
Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request
|
||||
to another qube. The OS then asks the user if the call is permitted.
|
||||
|
||||
![Example](qubes/qrexec-example.png)
|
||||
@ -48,7 +48,7 @@ This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented.
|
||||
|
||||
![Clef via qrexec](qubes/clef_qubes_qrexec.png)
|
||||
|
||||
On the `target` qubes, we need to define the rpc service.
|
||||
On the `target` qubes, we need to define the RPC service.
|
||||
|
||||
[qubes.Clefsign](qubes/qubes.Clefsign):
|
||||
|
||||
@ -135,11 +135,11 @@ $ cat newaccnt.json
|
||||
$ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign
|
||||
```
|
||||
|
||||
This should pop up first a dialog to allow the IPC call:
|
||||
A dialog should pop up first to allow the IPC call:
|
||||
|
||||
![one](qubes/qubes_newaccount-1.png)
|
||||
|
||||
Followed by a GTK-dialog to approve the operation
|
||||
Followed by a GTK-dialog to approve the operation:
|
||||
|
||||
![two](qubes/qubes_newaccount-2.png)
|
||||
|
||||
@ -169,7 +169,7 @@ However, it comes with a couple of drawbacks:
|
||||
- The `Origin` header must be forwarded
|
||||
- Information about the remote ip must be added as a `X-Forwarded-For`. However, Clef cannot always trust an `XFF` header,
|
||||
since malicious clients may lie about `XFF` in order to fool the http server into believing it comes from another address.
|
||||
- Even with a policy in place to allow rpc-calls between `caller` and `target`, there will be several popups:
|
||||
- Even with a policy in place to allow RPC calls between `caller` and `target`, there will be several popups:
|
||||
- One qubes-specific where the user specifies the `target` vm
|
||||
- One clef-specific to approve the transaction
|
||||
|
||||
@ -177,7 +177,7 @@ However, it comes with a couple of drawbacks:
|
||||
#### 2. Network integrated
|
||||
|
||||
The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible
|
||||
form other qubes.
|
||||
from other qubes.
|
||||
|
||||
![Clef via http](qubes/clef_qubes_http.png)
|
||||
|
||||
@ -193,6 +193,6 @@ to your computer. Over this new network interface, you can SSH into the device.
|
||||
Running Clef off a USB armory means that you can use the armory as a very versatile offline computer, which only
|
||||
ever connects to a local network between your computer and the device itself.
|
||||
|
||||
Needless to say, the while this model should be fairly secure against remote attacks, an attacker with physical access
|
||||
Needless to say, while this model should be fairly secure against remote attacks, an attacker with physical access
|
||||
to the USB Armory would trivially be able to extract the contents of the device filesystem.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user