Open evilaliv3 opened 9 years ago
related to this there is still a possibility that a not so experienced user use the public ip addess of the globaleaks server to configure the local SMTP. this would work like a charm leading to deanonimization of the setup. shall we prevent this somehow? if yes how?
We can also simply do the following procedure: IF smtp_server = ("localhost" || 127.0.0.1) ; then NO_TOR
i agree on adding this simple check clientside on validation and serverside on saving.
obviusly the check its not complet leaving tons of possibilities (127.0.0.2), but it solve the more common situations.
we can add a strings in /etc/defaults/globaleaks called "ip address where local server is checked if you enable the option above: 127.0.0.1" and the option above is: "enable local mailserver: [some option ?]"
I'm adding security = 'disabled' as an option to sendmail() to my fork, it would make local smtp usage easier to configure
mmm @origliante security as variable name here does not have a clear meaning. using a local sendmail account does not mean that the local sendmail cannot be torified (e.g. being launched with "torify sendmail").
so i think that simply we should have a setting: "torify mail notifications" with a default True and a warning on the case the user chose to disable it that should say: "Warning: This way Globaleaks would not automagically torify mail notifications and this could bla bla... in order to use a torified local mail server read bla bla [wiki reference]"
Sorry I try to clear it up. There are two variables, one controlling the use of tor socks vs tcp4: GLSetting.tor_socks_enable
And another one controlling the use of SSL/TLS: security=GLSetting.memory_copy.notif_security
What can be done to make it simpler to use a local SMTP is to: 1) add another GLSetting variable about using tor for notifications 2) add a security='disabled' state to tell sendmail() to not use TLS nor SSL
I added 2) in my fork while testing sendmail() error corners and exception messages (another topic), and that could be also useful for local SMTP configurations.
Please consider that network sandboxing with automatic iptables tor redirection will prevent all those modifications from working, unless we modify the way sandboxing is applied by having a special exception for 127.0.0.0/8 network.
yep sure @fpietrosanti, and we already discussed the possible idea of removing this things from the init script and doing them from the daemon in order to make possible controlling them at runtimem by configuration. but let's do not think to them right now.
@origliante: for 2) i'm a little critig. people will end using unencrypted smtp servers for local networks and eventually also for remote ones. and it's not so easy discern between the two so for now eventually let's rewrite the code so that is more easy testable if you have this need, but not rely on adding that configuration possibility.
@evilaliv3 we need to do it anyway, just now, if we want to allow globaleaks to talk to 127.0.0.1 without disabling NETWORK_SANDBOXING
I'd like to better understand what risks are involved in using a local SMTP server here.
My use case for globaleaks is about Corporate Compliance, and in this context I don't see any associated risk in knowing that a particular host is running a globaleaks instance (indeed my host is wholly reachable on regular internet). Am I missing something? Is this risk documented in the "Security" section of the docs? Because I read all of it and I can't associate this risk to any of the ones highlighted there.
We should evaluate the possiblity to support the use of a local postfix, or eventually denied its configuration.
Currently in fact this is not problem but it's only not prevented so that users (jpleaks) tried to configure a local postfix in order to solve issue https://github.com/globaleaks/GlobaLeaks/issues/1179.
We should take a decision on: 1) allowing local smtp server usage; this would lead to deanonymization of the server so that an attacker can have a try on the public ip of the SMTP server in order to see if also globaleaks is there and sometimes find it there. 2) not allowing this possibility by recognizing local ip addresses. it would important globaleaks is able to detect if the inserted configuration is valid (eventually giving a try on the configuration an provide some feedback to the user).