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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



- 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux