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

David Ward david.ward at gatech.edu
Fri Apr 8 08:06:35 BST 2022


On 4/7/2022 5:00 AM, Johannes Meixner wrote:
> On 2022-04-06 06:03, David Ward wrote:
>> As suggested, soliciting comments on this issue:
>> https://gitlab.com/sane-project/backends/-/issues/588
> 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.

Yes.


> 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 ;-)

Exactly. This is something I am trying to identify: does anyone 
*actually* use this feature?


> ...
>
> 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.

To clarify: I'm not saying it needs to be "really secure". I'm saying 
that what is implemented today is "very insecure", by standards many 
years ago.


> 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.
There are two problems with that.

  * The first issue is the term "trusted internal network". Attacks do
    not have to come from the internet. If I cannot put a scanner on the
    network without needing a password to access it, then how much do I
    really trust the users of the network?

    I may be missing the context here. I assume that the scanner is
    normally empty, except when it is actively in use: I walk up to it,
    put my document inside, go to my desk, click "scan", then come back
    and retrieve my document.

    I suppose it's possible to get distracted and leave my document in
    the scanner. But then don't I need to worry about someone just as
    easily taking the document out of it physically?

  * The second issue is one that I cannot emphasize enough.

    If simply observing the network traffic between the SANE client and
    server is enough to allow someone to obtain their password without
    much difficulty — then what is that password good for? Is it only
    for accessing the scanner?

    Or, more likely: is that the same password the individual uses to
    log into their system? Or to access their e-mail? Or (hopefully not)
    their bank account?

    That is why it is actually better to use no authentication, than to
    allow weak authentication.


> 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".

Did the user log in to their system, and/or connect to the network, with a secure username and password? Is access being logged centrally?



To me, I'm having trouble seeing how this scenario cannot be solved another way that does not involve SANE's authentication, and how it outweighs the risk involved by enabling that.



Thanks,

David




More information about the sane-devel mailing list