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

[Steven Santos]

How difficult would it be to replace the current sane.users scheme with a
pam integration and a modern cypher?

On Thu, Apr 7, 2022 at 5:17 AM Johannes Meixner <jsmeix at suse.de> wrote:

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20220407/1dd8cc5f/attachment.htm>