Hello Thomas, [email protected] schrieb am Samstag, 12. März 2022 um 23:00:34 UTC+1:
> Since we are looking at getting Leo to work with files on a remote > computer, we should discuss the security aspect. I think there are > basically two kinds of things we'd like to prevent. My terminology here is > that the "host" computer is the one that contains a Leo file that we'd like > to work on in an instance of Leo running on a different computer; The > "remote" computer is the one where we want to be able have Leo open that > host file. > > 1) Exfiltration of arbitrary files from the host computer. We don't want > someone to use our host's leoserver to retrieve any arbitrary file by > pretending to be a remote Leo instance. > > 2) Replacement or corruption of arbitrary files - or even just Leo files - > on the host computer. > > Now, I realize that I've been picturing this remote usage as being > entirely within the local LAN, and even then you'd have to get the firewall > on the host machine to let our webchannel connections through. Even so, I > think we should be thinking about the issues. > Definitely it should be done now / in parallel - and - not as an afterthought. > > I don't have a general solution to suggest here. And I don't know much > about how the Windows firewall can be configured (not for Linux, either, > but I think at least there one can do almost anything). But here are some > measures that could be done, probably for not too much effort: > > a. Get the firewall to only allow connections from the one specific > IP:port combination you want to use for the remote computer; > b. Have leoserver only send and receive Leo outlines; > b1. Have leoserver validate that a file really is a proper Leo file; > c. Have leoserver only save files from the remote that it had previously > sent to the remote. > d. Have leoserver only send and receive files that have been specified in > a config file. > I think those are the bare minimal measures to get the implementation started - and - are needed as soon as leo-client 'leaves' localhost in real life usage. I believe that transport layer security (e.g. support & usage of wss:// instead of only ws://) - as well as - proper authentication (e.g. login (w/ 2FA?)) should be taken into account as well. IMO both authentication & encryption should be made available, at least as opt-in extensions, for the leo-server environment on the host machine. > Yes, it's true, someone could modify the leoserver python file to get > around these kinds of restrictions. But to do that, they would have to > have local access already, and if that is the case they would already be > able to drop or retrieve any files they want anywhere on the machine. So I > don't think we need to worry much about this particular possibility. > Agreed. Looking forward to hear what Edward & Felix think about this topic. With kind regards, Viktor -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/2e88a390-25e9-406c-adae-434e31d4933bn%40googlegroups.com.
