<div dir="ltr">How difficult would it be to replace the current sane.users scheme with a pam integration and a modern cypher? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 7, 2022 at 5:17 AM Johannes Meixner <<a href="mailto:jsmeix@suse.de">jsmeix@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hello,<br>
<br>
On 2022-04-06 06:03, David Ward wrote (excerpts):<br>
> As suggested, soliciting comments on this issue:<br>
> <a href="https://gitlab.com/sane-project/backends/-/issues/588" rel="noreferrer" target="_blank">https://gitlab.com/sane-project/backends/-/issues/588</a><br>
...<br>
> The user authorization handling in the net backend is insecure<br>
...<br>
> I believe this handling in its current form should simply be removed.<br>
> In an environment where user authorization is necessary, system<br>
> administrators need to find their own way to support this that meets<br>
> their requirements. Using an insecure solution built into SANE should<br>
> not be provided as an option<br>
<br>
I assume you are talking about /etc/sane.d/saned.users<br>
that - if exists - contains lines of the form<br>
   user:password:backend<br>
to restrict access to a local SANE backend on a saned server<br>
for users who access this backend from remote clients there<br>
via their net backends via network and the saned on the server.<br>
<br>
First and foremost:<br>
I never used that myself and I never noticed a user question<br>
about it so I guess in practice it is perhaps not used<br>
or it is actually used and "just works OK for everybody"<br>
(but I doubt the latter is true ;-)<br>
<br>
I wonder if scanning frontend programs that are used<br>
on nowadays Linux desktops support a user password dialog<br>
when a /etc/sane.d/saned.users exists on a saned server?<br>
<br>
If nowadays (graphical) end-user scanning programs<br>
do not support /etc/sane.d/saned.users then I think<br>
it is probably best to drop support for it in SANE,<br>
ideally in a reasonably fail-safe way as described in<br>
<a href="https://gitlab.com/sane-project/backends/-/issues/588" rel="noreferrer" target="_blank">https://gitlab.com/sane-project/backends/-/issues/588</a><br>
<br>
In contrast when nowadays end-user scanning programs<br>
support /etc/sane.d/saned.users then I think even<br>
the current weak user authorization still has a valid<br>
purpose in particular within trusted internal networks.<br>
<br>
Reasoning:<br>
<br>
In network environments the admin should be able to set up<br>
rules what network scanners are available for the users<br>
so plain networking rules (e.g. based on IP addresses or so)<br>
can't provide that - those rules must be based on user IDs.<br>
<br>
In trusted internal networks such a setup does not need<br>
to be really secure.<br>
<br>
Assume in a trusted internal network there are two scanners<br>
and the admin does not want that one is accessible by all users<br>
of that network (e.g. one is reserved only for certain users).<br>
<br>
In a trusted internal network there is no need to setup<br>
strong security stuff for that. Just some simple thing<br>
is sufficient that denies unwanted user access.<br>
<br>
Of course it is only "security by obscurity" when an<br>
experienced user could still access something manually<br>
(e.g. via some hack or arbitrary self-written programs).<br>
<br>
Nevertheless I think in practice it makes a difference<br>
if any "unwanted" network scanner access would be<br>
"just possible for all users" versus when the user<br>
must do special actions to get access.<br>
<br>
There could be even a legal difference when prohibited<br>
access is "just possible" (even accidentally) versus<br>
when prohibited access is impossible by "usual means".<br>
<br>
<br>
FYI cf. my posting at<br>
<a href="https://github.com/apple/cups/issues/5011#issuecomment-304825279" rel="noreferrer" target="_blank">https://github.com/apple/cups/issues/5011#issuecomment-304825279</a><br>
<br>
<br>
Kind Regards<br>
Johannes Meixner<br>
-- <br>
SUSE Software Solutions Germany GmbH<br>
Maxfeldstr. 5 - 90409 Nuernberg - Germany<br>
(HRB 36809, AG Nuernberg) GF: Ivo Totev<br>
<br>
</blockquote></div>