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

[Johannes Meixner]

Hello,

On 2022-04-06 06:03, David Ward wrote (excerpts):
> As suggested, soliciting comments on this issue:
> https://gitlab.com/sane-project/backends/-/issues/588
...
> The user authorization handling in the net backend is insecure
...
> 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

I assume you are talking about /etc/sane.d/saned.users
that - if exists - contains lines of the form
   user:password:backend
to restrict access to a local SANE backend on a saned server
for users who access this backend from remote clients there
via their net backends via network and the saned on the server.

First and foremost:
I never used that myself and I never noticed a user question
about it so I guess in practice it is perhaps not used
or it is actually used and "just works OK for everybody"
(but I doubt the latter is true ;-)

I wonder if scanning frontend programs that are used
on nowadays Linux desktops support a user password dialog
when a /etc/sane.d/saned.users exists on a saned server?

If nowadays (graphical) end-user scanning programs
do not support /etc/sane.d/saned.users then I think
it is probably best to drop support for it in SANE,
ideally in a reasonably fail-safe way as described in
https://gitlab.com/sane-project/backends/-/issues/588

In contrast when nowadays end-user scanning programs
support /etc/sane.d/saned.users then I think even
the current weak user authorization still has a valid
purpose in particular within trusted internal networks.

Reasoning:

In network environments the admin should be able to set up
rules what network scanners are available for the users
so plain networking rules (e.g. based on IP addresses or so)
can't provide that - those rules must be based on user IDs.

In trusted internal networks such a setup does not need
to be really secure.

Assume in a trusted internal network there are two scanners
and the admin does not want that one is accessible by all users
of that network (e.g. one is reserved only for certain users).

In a trusted internal network there is no need to setup
strong security stuff for that. Just some simple thing
is sufficient that denies unwanted user access.

Of course it is only "security by obscurity" when an
experienced user could still access something manually
(e.g. via some hack or arbitrary self-written programs).

Nevertheless I think in practice it makes a difference
if any "unwanted" network scanner access would be
"just possible for all users" versus when the user
must do special actions to get access.

There could be even a legal difference when prohibited
access is "just possible" (even accidentally) versus
when prohibited access is impossible by "usual means".


FYI cf. my posting at
https://github.com/apple/cups/issues/5011#issuecomment-304825279


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Ivo Totev