|
|
Subscribe / Log in / New account

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

I don't believe that at all. These features are always to give "security" (i.e. perpetual ownership) to device designers, by making it too annoying to tinker with (keep in mine that Turing showed that this is not security at all). With iTunes they had to turn off the DRM (on music only) because otherwise no-one would have used their product as it provided negative value.


to post comments

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 19:10 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

This code was largely written while I was at Red Hat, not a company known for its hardware products.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 13:21 UTC (Thu) by ncultra (✭ supporter ✭, #121511) [Link] (1 responses)

Mathew, thank you for your effort on all of this code, it is needed and appreciated for a good segment of the user base.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 9:17 UTC (Fri) by bluca (subscriber, #118303) [Link]

Seconded. It's incredibly useful, and especially given how long and difficult the road to mainline was, praise is well deserved. Thank you!

Garrett: Linux kernel lockdown, integrity, and confidentiality

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:

  1. 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.
  2. 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:

  1. 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.)
  2. 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?).
  3. 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?).
  4. 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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 22, 2020 23:39 UTC (Wed) by pizza (subscriber, #46) [Link] (11 responses)

You left something out of the factual claims:

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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 4:23 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (7 responses)

I broadly agree with you, with some qualifications:

  1. Consequentialism doesn't care about property rights *as rights,* but it may be willing to recognize their abrogation as a form of harm which can be morally weighed. I already described doing so in my previous post, so I'm not sure what more there is to add here.
  2. For deontology, property rights may be contracted away, regulated, limited by other responsibilities, or otherwise extinguished, and you need to determine whether that has happened in each specific case. Property is not a trump card.
  3. There is a tendency to confuse the legal with the moral. Property rights and contractual obligations straddle this line, and need to be carefully considered in a deontological setting to avoid presuming that "the law" is always morally correct.
  4. We are discussing the morality of locking down the device in the first place, not the morality of rooting it after the fact. Those two things could both be morally permissible, because they are different actions taken by different people at different times.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 7:17 UTC (Thu) by scientes (guest, #83068) [Link] (6 responses)

I appreciate that your effort. Besides the property rights mentioned above, I am mainly talking about how Linux is impossible to make secure because of the massive attack surface. The main way to show this, is to show what it is NOT, which is software written from the beginning to be proven correct:

https://microkerneldude.wordpress.com/2016/06/16/verified...

Garrett: Linux kernel lockdown, integrity, and confidentiality

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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 11:16 UTC (Thu) by Wol (subscriber, #4433) [Link]

This is the difference between Mathematics and Science.

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,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 12:52 UTC (Fri) by jhhaller (guest, #56103) [Link] (3 responses)

The one I remember was a UK company (INMOS?) who was going to build a provably correct microprocessor. Unfortunately, they didn't account for silicon defects in actual implementations of the microprocessor. While that's not to say formally verifying the design is bad, just that it won't guarantee a particular chip will always work the way the specification says it should.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 17:49 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

Yep. Reminds me of a security story I heard a long time ago, about pen-testing a very fancy biometric lock system. An iris scanner, if I recall correctly.

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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 18:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can trick a LOT of electronic locks using a simple magnet to trigger the motor relay.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 24, 2020 18:09 UTC (Fri) by kmweber (guest, #114635) [Link]

And to a large extent, it matters just what you're trying to protect against.

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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 11:19 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> You left something out of the factual claims:

> 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,
Wol

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 12:23 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Not to forget that the keeper/user is not necessarily the owner (as has been mentioned elsewhere).

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.

Garrett: Linux kernel lockdown, integrity, and confidentiality

Posted Apr 23, 2020 12:26 UTC (Thu) by Wol (subscriber, #4433) [Link]

I know. The trouble is, a lot of people seem to start from the premise "if it's in my possession, I own it". After all, possession is nine tenths of the law, after all ... :-)

Cheers,
Wol


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds