I agree with the desire for a secure, built-in authorization solution.
But looking at how it works now, what we're really talking about here is
not making improvements to that, but rather fully replacing it out of
necessity. Keep in mind that changing the network protocol automatically
breaks compatibility with clients using an older version of SANE, so
preferably that should only happen once. It's not clear when or how long
it would take someone to implement the new approach.
I would suggest that simply disabling user authorization in its current
form is not mutually exclusive with adding a new solution whenever that
is ready.
There could be stronger language in the documentation, but honestly I
don't see any scenario where the current solution should be used. If you
have a network connected behind a firewall and you trust all the other
users (say at home or even in a small business), then you don't need an
authorization solution for your networked scanners in the first place;
you can simply run saned without configuring that. If that's not the
case, then this solution is not something you should be using today.
There are many other things you can do instead at the network level in
the interim, depending on your needs (tunneling the port over SSH,
configuring firewall rules, etc.)
David
On 4/6/2022 4:25 PM, Steven Santos wrote:
Here is my thinking:
With the recent development of eSCL now being supported natively on
Windows, I think we will see SANE used as an integral part of central
scanning solutions more and more. I know at least one effort is
underway to create an eSCL "reflector" to make this process easier.
With these developments, I think in a short period of time, many
people will want some form of authentication baked in, especially if
it can be used with SAMBA or other directory and policy framework
(i.e. show this user or this machine this scanner based on these
policies. Set this default scanner based on these policies. Set the
scan directory to this based on these policies. You get the idea.).
So, my thought is that finding a way to support this is a better
direction than just deleting it.
On Wed, Apr 6, 2022 at 12:03 AM David Ward <[email protected]> wrote:
As suggested, soliciting comments on this issue:
https://gitlab.com/sane-project/backends/-/issues/588
The description is included below. Thanks!
------------------------------------------------------------------------
The user authorization handling in the net backend is insecure for at
least two reasons:
* it uses the MD5 cipher, which is cryptographically broken
* it provides no protection against a man-in-the-middle attack
I believe this handling in its current form should simply be
removed. In
an environment where user authorization is necessary, system
administrators need to find their own way to support this that meets
their requirements. Using an insecure solution built into SANE should
not be provided as an option; note that operating on a private
network
does not really diminish the issues with it.
The direct way to achieve this, without breaking the current
protocol,
is for sanei_authorize() to simply return SANE_STATUS_GOOD. (Code
that
is no longer used as a result can be removed, and documentation
can be
updated.) This change should of course be very apparent during
upgrades:
I would suggest that authorization unconditionally fail if a
<backend>.users file still exists, requiring the system
administrator to
understand this change and manually remove the file.
While it remains possible to implement user authorization with
stronger
ciphers and in a way that affords some protection against MITM
attacks,
this would necessarily change both the protocol and the file
format, so
it would still seem best to remove the existing handling.
