[sane-devel] Remove user authorization support from net backend / saned frontend?

[David Ward]

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 <david.ward at gatech.edu> 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.
>