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

[Thierry Huchard]

Le 2022-04-08 13:04, Kelly Price a écrit :
> I think there's two issues here:  The authentication and the
> at-the-wire security.
> 
> The latter first, as I think it's more important.  If I set up a saned
> server with scanner, load up a set of financial documents to scan,
> walk away to my PC, and then trigger the scanning... can someone on
> another computer, same network, sniff the traffic going by and get all
> those documents?
> 
> If that connection to saned isn't encrypted over the network, then any
> authentication is useless.  Once the connection is secure, we can
> check credentials.
> 
> Now the first issue, and I'll pose a question:  How are we
> communicating control over saned?  Is it a home-grown protocol, or is
> it something over an HTTP analogue?   Having it match against a UNIX
> user is an implementation issue, but then if some rogue actor has root
> control over a server, it's game over no matter what.   Having folks
> get asked for a username/password will prevent the curious.  The rogue
> actor will heavily jam something home-grown and exploit any holes we
> forgot about.
> 
> That said, if we need to replace the entire protocol, we should check
> if any other protocol that we implement (like eSCL) is more secure.
sane-escl prefers https connections, but does not check certificates 
(this could be enabled)
> 
> On Fri, Apr 8, 2022 at 6:06 AM Johannes Meixner <jsmeix at suse.de> wrote:
>> 
>> 
>> Hello,
>> 
>> On 2022-04-08 09:06, David Ward wrote (excerpt):
>> > On 4/7/2022 5:00 AM, Johannes Meixner wrote:
>> >>
>> >> 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.
>> ...
>> >  * 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?
>> 
>> The meaning of trusted internal network is that
>> one trusts all users in that network.
>> 
>> If there is an attacker within a trusted internal network
>> all is lost within that network.
>> 
>> Denying unwanted access of trusted users
>> is not meant as protection against attackers
>> because attackers are no trusted users.
>> 
>> To deny unwanted access of trusted users
>> a notification "this is not for you" would be
>> sufficient because trusted users obey the rules.
>> 
>> Think about simple door plates at unlocked doors
>> in a trusted environment that tell who is allowed
>> to enter and/or who should not enter.
>> The most common example are door plates at toilets.
>> In case of emergency one can even use a wrong toilet.
>> 
>> For saned access within a trusted environment
>> the existing weak user password functionality
>> can be OK to deny unwanted access of trusted users
>> in particular to deny accidental access by users.
>> 
>> If stronger security is needed (think about locked doors
>> within a trusted environment) the existing weak user
>> password functionality is insufficient to reliably
>> lock out unwanted saned access.
>> 
>> 
>> Kind Regards
>> Johannes Meixner
>> --
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5 - 90409 Nuernberg - Germany
>> (HRB 36809, AG Nuernberg) GF: Ivo Totev
>>