search

SimulPiscator / AirSane

Publish SANE scanners to MacOS, Android, and Windows via Apple AirScan.
GNU General Public License v3.0
247 stars 26 forks source link

over unix socket for better security #66

Closed bastien-roucaries closed 3 years ago

bastien-roucaries commented 3 years ago

Hi,

The only stuff what you could do for improving the security if you use stunnel is instead of listening over a localhost port is to listening over a unix socket.

It is a minor bug but it is better for a security point of view

bastien-roucaries commented 3 years ago

This will only need to decouple the avahi notification from you server.

Could you document the needed avahi file like here https://wiki.archlinux.org/title/avahi#AirPrint_from_Mobile_Devices ?

This file could be generated by systemd using a little shell wrapper when your daemon start and reduce the attack surface of your app

SimulPiscator commented 3 years ago

It is a minor bug but it is better for a security point of view

Sorry, I don't understand. What exactly do you consider a bug and why? Is it about a missing feature (unix socket)?

This will only need to decouple the avahi notification from you server.

I don't think this is possible. The AirSane daemon auto-detects devices as they are plugged in, and removes them when unplugged. I also don't understand why the avahi API is now considered a security hole.

bastien-roucaries commented 3 years ago

It is a minor bug but it is better for a security point of view

Sorry, I don't understand. What exactly do you consider a bug and why?

openning a socket on localhost:6000 allow a local user to sniff your http stuff. It could be hardened by using docker (but you need to be a root user or a docker user to do that, and docker user is in fact root), but is it is better to use an unix socket and unix right restriction for the stunnel process. Therefore only the stunnel process with group sanetunnel could acess to the insecure socket. Better than local user (think if we use https with user certificate for auth).

This will only need to decouple the avahi notification from you server.

I don't think this is possible. The AirSane daemon auto-detects devices as they are plugged in, and removes them when >unplugged. I also don't understand why the avahi API is now considered a security hole. zeroconf could be considered as a security bug (annoucing on network the type of hardware) and may be disable at wish by admin using a flag (will open a bug for this)

No the problem is if you use unix socket for tunnel providing, the avahiport is unknown. But if I read the spec correctly (p9) you could have more than one scanner to the same port. You only need to read on your side the server name and redirect to the right name. You could even if I read the spec correctly change the root attrbute of the txt file per scanner avoiding therefore to use more port per scanner.

So it is is really safe to use only one port

SimulPiscator commented 3 years ago

OK, I begin to understand your security concerns in the context of a "freedom box", but I fail to understand the problem with zeroconf inside a local network.

SimulPiscator commented 3 years ago

So in the ssltunneled case, the avahi announcement should not contain real hardware information, just generic one? Otherwise, what would be the mechanism to update the avahi service file (and cause the avahi daemon to reload service files)?

bastien-roucaries commented 3 years ago

So in the ssltunneled case, the avahi announcement should not contain real hardware information, just generic one? >Otherwise, what would be the mechanism to update the avahi service file (and cause the avahi daemon to reload service files)? @SimulPiscator no if the rs could change depending of the scanner we could send real avahi path using rs and using uscans instead of uscan. It is up to the user to run in this case stunnel. But we are on the safe side, because if you do not run stunnel the port is not open (we use an unix socket)

bastien-roucaries commented 3 years ago

OK, I begin to understand your security concerns in the context of a "freedom box", but I fail to understand the problem with >zeroconf inside a local network.

In hardening context zeroconf should be disabled (it allow an attaker to discover the network). Thus no zero conf in this case an admin will need on the client to pass secretuid/reproductiblepathtoscaner as rs. It work but it need manual work

SimulPiscator commented 3 years ago

OK, there is a unix socket option now.