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 <[email protected]> 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 > >
