- 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
