Garrett: Linux kernel lockdown, integrity, and confidentiality
Garrett: Linux kernel lockdown, integrity, and confidentiality
Posted Apr 22, 2020 22:22 UTC (Wed) by NYKevin (subscriber, #129325)In reply to: Garrett: Linux kernel lockdown, integrity, and confidentiality by scientes
Parent article: Garrett: Linux kernel lockdown, integrity, and confidentiality
> 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:
- The set of users whose devices are at serious risk of malware infection is much, much larger than the set of users who want to root their devices.
- Malware can do a lot more harm if the device can be rooted than if it cannot.
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:
- Whether you are a consequentialist ("The needs of the many outweigh the needs of the few") or a deontologist ("We hold these truths to be self-evident, that all men [...] are endowed by their Creator with certain unalienable Rights[...]"). You can't be both, because they contradict each other. (There are other ethical positions as well, but for simplicity I omit them here.)
- If you are a consequentialist, the amount of harm that you believe is created by each instance of malware on average, and by each user denied the right to root their device. Then, you multiply by the number of users affected, and compare the two harms in aggregate.
- Factors such as the "fault" of nontechnical users for failing to secure their devices, or the "freedom" of technical users to root their devices, are out of scope and not evaluated, except to the extent that they can be framed in terms of consequences (e.g. Would nontechnical users have been infected anyway? Can we quantify the amount of additional harm caused by the infected device being unlocked, instead of the total harm?).
- If you are a deontologist, whether you consider rooting a device to be a fundamental right, and the extent (if any) to which you believe this right can be attenuated by your contractual agreement with the vendor or service provider, or by other considerations such as the availability of unlocked devices.
- Factors such as the number of users who will actually be subject to malware infections, and the likely consequences of those infections, are out of scope and not evaluated, except to the extent that they can be framed in terms of rights and responsibilities (e.g. Does the manufacturer owe a duty of care to its users? Will the malware cause harm to the public, for which the manufacturer would be responsible? Do the users themselves have responsibilities here?).
- Whether facts can give rise to morality in the first place. (This is mostly only of interest to philosophers, but it gives you a sense of just how complicated this whole problem is.)
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
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
