Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Posted Apr 22, 2020 12:03 UTC (Wed) by scientes (guest, #83068)In reply to: Garrett: Linux kernel lockdown, integrity, and confidentiality by jorgegv
Parent article: Garrett: Linux kernel lockdown, integrity, and confidentiality
Posted Apr 22, 2020 19:10 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Apr 23, 2020 13:21 UTC (Thu)
by ncultra (✭ supporter ✭, #121511)
[Link] (1 responses)
Posted Apr 24, 2020 9:17 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
Posted Apr 22, 2020 22:22 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
> I don't believe that at all.
We must be careful in disagreeing with each other, lest we talk past each other and learn nothing from it. This starts by being precise about the claims with which we disagree:
These claims are factual, not ethical. They may be subject to empirical refutation (and if you have citations, I would be very interested in seeing them), but they cannot be logically refuted by moral arguments.
To determine the morality which results from this set of facts, you would need to consider:
Since all of these points are somewhat subjective and/or disputed, it should be unsurprising that reasonable people may disagree about them. But we must not lose sight of the underlying facts, or it will be impossible to have a constructive discussion about this question.
Posted Apr 22, 2020 23:39 UTC (Wed)
by pizza (subscriber, #46)
[Link] (11 responses)
0) The device is the property of the owner.
Therefore one has to include the concept of property rights in any analysis, especially in situations where the owner and user are the same party.
Posted Apr 23, 2020 4:23 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (7 responses)
I broadly agree with you, with some qualifications:
Posted Apr 23, 2020 7:17 UTC (Thu)
by scientes (guest, #83068)
[Link] (6 responses)
https://microkerneldude.wordpress.com/2016/06/16/verified...
Posted Apr 23, 2020 10:44 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (5 responses)
When I sat in a class in proven software in the 1980's, the professor who was all for it wanted to stress that it isn't perfect unless you map out the entire universe in your proof. All it takes to destroy most proofs is some change in the environment be it running on a different CPU, hardware or even the orientation of the system. [The example given was that software which had been proven correct would fail in a way outside of the proof, if the computer was turned 90 degrees during the day. It worked fine at night in that orientation. The reason turned out to be a microwave dish in another lab which affected various components inside of the computer just slightly enough to make them not react properly.]
In the end, you can't make anything absolutely secure and generally usable. You can make it resilient and robust, but if people or the environment can interact with the system at all.. there will eventually be a way to make it insecure.
Posted Apr 23, 2020 11:16 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Your program proof will prove that your program is correct and consistent.
You then need to test it, to make sure (as best you can!) that theory and reality agree.
Mathematical proofs prove that things are *consistent*. Scientific proofs prove that reality disagrees with mathematics.
Cheers,
Posted Apr 24, 2020 12:52 UTC (Fri)
by jhhaller (guest, #56103)
[Link] (3 responses)
Posted Apr 24, 2020 17:49 UTC (Fri)
by zlynx (guest, #2285)
[Link] (2 responses)
One attacker bypassed the whole thing by inducing a signal into the wire in the wall that triggered the unlock relay. So much for security scanners.
And one of the smart cards where secret keys could be extracted by observing the outputs while applying a hair dryer to the card.
Posted Apr 24, 2020 18:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 24, 2020 18:09 UTC (Fri)
by kmweber (guest, #114635)
[Link]
In college, I had a summer job that involved (among other things) cleaning and performing routine maintenance on large inkection molding machines at an automobile factory. This required physically entering the machines. The molds used weighed on the order of forty tons; consequently, the hydraulic presses generated several thousand tons of force. You did NOT want to be stuck inside that thing if it were accidentally powered up.
Consequently, as is standard practice in such environments, we used a lockout/tagout process that involved placing padlocks to immobilize the switches and valves for the power sources, and then placed the keys for those padlocks in a lock box. The lock box was shut by individual padlocks for everyone on the team, and each person kept their key on them. That way, it could only be opened (and thus the padlocks on the switches could only be unlocked) if everyone involved came out of the machine and removed their personal padlock.
Of course, the lock box was made of fairly brittle plastic, and the padlocks themselves were of the sort that you could cheaply purchase at any hardware store. So it wouldn't have been difficult at all for someone with ill intent to bypass the whole system--all you'd need is a hammer or bolt cutters. But that was fine, because it wasn't intended to protect against malice. It was there to prevent accidents, and it did so quite effectively.
Posted Apr 23, 2020 11:19 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
> 0) The device is the property of the owner.
Not to forget that the keeper/user is not necessarily the owner (as has been mentioned elsewhere).
Cheers,
Posted Apr 23, 2020 12:23 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Of course!
But the keeper/user and owner can also be the same party, and when that device's ownership is transferred as part of a sale, the seller/oldowner no longer gets any say in what the buyer/newowner does with it.
Posted Apr 23, 2020 12:26 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Wol
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Wol
Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Wol
