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

[Kelly Price]

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.

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
>


-- 
Kelly "STrRedWolf" Price
http://redwolf.ws