Remote Leo Files - Security Issues

56 views
Skip to first unread message

tbp1...@gmail.com

unread,
Mar 12, 2022, 5:00:34 PM3/12/22
to leo-editor
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.

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.

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.

Viktor Ransmayr

unread,
Mar 14, 2022, 1:14:02 AM3/14/22
to leo-editor
Hello Thomas,

tbp1...@gmail.com 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

tbp1...@gmail.com

unread,
Mar 14, 2022, 9:01:33 AM3/14/22
to leo-editor
Thanks for the helpful thoughts, @viktor.  Here is a StackOverFlow page I found that seems useful for getting wss working in Python:

I'd forgotten about the need to generate a self-signed certificate.  I've only done that a few times, using java tools IIRC. It was a pain, and learning what to do was even more so.

For use on a (my) my LAN, I don't think I want to get into authentication.  I suppose that if one were ever going to allow communications from outside the LAN that would be a different story.  If the ws(s) server is able to discover the IP address of a request, it could be configured  to disallow any connections apart from specific ones.  That would probably be a good move.  Or one could just leave that to the system firewall.

Félix

unread,
Mar 15, 2022, 12:21:00 AM3/15/22
to leo-editor
Hello Thomas and Viktor :)

This is an interesting subject!

To get more serious about network connections onto leoservers, some https (ssl) could be setup. (Has to be supported by clients optionally to i guess)

 Also, like Viktor suggested, some user/password authorisation scheme could be implemented relatively easily on the server in the near future. 

I've opened and issue for that matter : https://github.com/boltex/leointeg/issues/249 to get things started on my end 

I really appreciate your input and hope to hear more suggestions, or documentations links like the one Thomas provided from you! 

Thanks! 
--
Félix



Reply all
Reply to author
Forward
0 new messages