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