Looking for Special Challenge-Response Auth PAM Module, or Similar

Philipp Marek philipp at marek.priv.at
Thu Aug 25 16:07:05 AEST 2022


>> - It seems that you are trying to prevent your customer (who 
>> presumably
>>    owns the product) from being able to log in to their own devices.
>>    Generally, this is considered rather consumer-unfriendly, so I
>>    would like to know what the underlying reason for it is.

> I have to second  on this, as it's been my experience so far that 
> vendors who
> try to lock customers out of systems are either trying to hide some 
> seriously
> weak system builds, or some shady ethical/technical practices the 
> customer
> would veto if they could see them or knew about them.  I'm fighting 
> this in
> my workplace all the time, as we have systems that (if they fail or are
> compromised) will cause human harm, and that's just not a negotiable 
> item for
> us any more.

Yeah, I'm annoyed by (badly) working appliances all the time, too,
and would also prefer a way to see all logs, modify the behaviour, etc. 
--
but that's because I believe that I can do a better job than the 
manufacturer!


Whether that is true or not depends not only on the manufacturer,
but also on every single on of the customers' people who (may) have 
access
to the box.

You surely don't want to get a box into your network that has _worse_ 
access
controls than your own boxes, right? Because that would provide 
attackers
with an easy first point.
Extrapolating that, such white boxes should be as unbreakable as 
possible
against _unauthorized_ access (yeah, I know about hardware access etc.).


But that is exactly the point --
"owning" the product also means "maintaining it".

And that's just not possible if any customer may "simply" log in
and change stuff at will.

[[  Imagine someone modifying your email, fileserver,
	or virus scan appliance to relay all "interesting" data
	to some external service (or a local USB stick that
	gets removed after the weekend!) ]]


IMO two issues are conflated here --

a)  the basic security should be as good as possible,
	to prevent unauthorized access;

b)  but perhaps (some) customers should be given a wide-range
	_read_ access to system logs as a debugging aid.


Just my ¢0,02.


More information about the openssh-unix-dev mailing list