Slashdot Mirror


Torvalds Opposes Tying UEFI Secure Boot to Kernel Lockdown Mode (phoronix.com)

An anonymous reader quotes Phoronix: The kernel lockdown feature further restricts access to the kernel by user-space with what can be accessed or modified... Pairing that with UEFI SecureBoot unconditionally is meeting some resistance by Linus Torvalds. The goal of kernel lockdown, which Linus Torvalds doesn't have a problem with at all, comes down to "prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded." But what has the Linux kernel creator upset with are developers trying to pair this unconditionally with UEFI SecureBoot. Linus describes Secure Boot as being "pushed in your face by people with an agenda." But his real problem is that Secure Boot would then imply Kernel Lockdown mode... "Tying these things magically together IS A BAD IDEA."

69 comments

  1. Essentially by 110010001000 · · Score: 5, Insightful

    Essentially what the corporations want is for people to only user the Internet via locked down ("approved" or "secure" devices). These devices will only have cloud based storage available and everything will be streamed from servers and the consumer will only need to pay a monthly fee for all this goodness. If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week.

    1. Re:Essentially by Anonymous Coward · · Score: 1

      So, Chromebooks.

    2. Re:Essentially by Anonymous Coward · · Score: 1, Insightful

      If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week.

      It's sexism. We need to lock down computers to prevent sexism. #MeToo

    3. Re: Essentially by Anonymous Coward · · Score: 2, Insightful

      Racism, too. And to prevent the wrong candidate from winning an election.

    4. Re:Essentially by vtcodger · · Score: 1

      "If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week."

      Bedbugs!! We need secure boot welded to Kernel Lockdown in order to fight the bedbug epidemic. (I'll also help fight global warming, prevent asteroid strikes, discourage illegal immigrants from voting, and save the skeets)

      --
      You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
    5. Re:Essentially by Billly+Gates · · Score: 1

      Essentially what the corporations want is for people to only user the Internet via locked down ("approved" or "secure" devices). These devices will only have cloud based storage available and everything will be streamed from servers and the consumer will only need to pay a monthly fee for all this goodness. If you don't think this will happen, think of the children, or the terrorists, or the terrorist children, or security, or whatever the problem is this week.

      Actually UEFI boot is just an encrypted boot loader. It is a feature if you put the tinfoil hat away as you can add your own keys. My Asus board offers this and it is GREAT FOR SERVERS. Many companies sign their RedHat Enterprise with UEFI and customer keys to prevent rootkits.

      It is not a kernel level anything. For a phone that is truly locked down you would need an encrypted CPU where if the assembly code isn't signed it will refuse to run on some DRM nightmare. But the bootloader doesn't go that far at all.

    6. Re: Essentially by murdocj · · Score: 1

      blah blah blah... it's all evil conspiracy by "the man"

    7. Re:Essentially by epyT-R · · Score: 2

      Not just corporations. Your friendly local 'globalhood' government wants it too.

    8. Re: Essentially by peppepz · · Score: 5, Informative

      UEFI secure boot and Microsoft-mandated secure boot are two different things.
      Microsoft took the secure boot specification, which is neutral, and added their own requirements, which aren't. They mandated themselves to have literally as much power as possible, while at the same time leaving to the user as little power to take back ownership of their own machine as it was possible without the world accusing them of taking over the PC market.

    9. Re: Essentially by Jane+Q.+Public · · Score: 1

      It is, in fact, just that.

      If you don't understand that, I have this really great bridge to sell you. It's a hell of a deal.

    10. Re:Essentially by Jane+Q.+Public · · Score: 4, Informative

      It's only "great" if you use that company's EFI support for that particular operating system.

      Otherwise, it's a major pain in the ass, and can even block you form installing the OS you may want to use.

      Microsoft has been the biggest pusher of this scheme, because it did not want people to be able to dual-boot. They called it a "security" measure, but in fact my system is a hell of a lot more secure if I install MacOS and run Windows in a "bootcamp" or VM.

      It's ALL ABOUT corporate lock-in, and not about security at all. Just as HDMI was/is.

    11. Re: Essentially by Anonymous Coward · · Score: 0

      Stop being so fucking boring.

    12. Re:Essentially by MerlinTheWizard · · Score: 1

      This trending economic model (or business model, which is unfortunately starting to mean the same) of forever renting goods leads to the abolition of private property, at least for the masses. Kind of funny that what looks like the the new epitome of capitalism so strangely resembles communism. What's your take on this?

    13. Re:Essentially by rtkluttz · · Score: 3, Interesting

      Malware. Any system that treats the owner of the device as the problem is malware. I'm all for secure boot as long as the owner of the device decides what to tag as secure and has complete control over the encryption and lockdowns.

      --
      Digital is, by definition, imperfect. Analog is the way to go.
    14. Re:Essentially by WorBlux · · Score: 1

      Read the article. Lockdown is a kernel mechanism to make even root can't read to write to Ring 0, helping to keep disk encryption keys safe even from root access attacks, protecting bootloader configuration, and some sorts of code injection.

    15. Re:Essentially by WorBlux · · Score: 1

      Most x86 boards let you set up the KEK (key exhange key, or platform key) or disable it entirely. Really it's the only way to prevent certain types or persistent attacks, attacks which become much easier when you have a standardized modular firmware.

      HDMI is a great standard, it's DVI with a sound and remote channel thrown in. HDCP sucks, and like all DRM is better off outright boycotted and broken.

    16. Re:Essentially by stooo · · Score: 2

      Here's the basic explanation :
      https://lkml.org/lkml/2018/4/3...

      --
      aaaaaaa
    17. Re:Essentially by Anonymous Coward · · Score: 0

      think of the children

      That's how they do it. https://www.eff.org/deeplinks/2018/03/how-congress-censored-internet

    18. Re:Essentially by Anonymous Coward · · Score: 0

      This trending economic model (or business model, which is unfortunately starting to mean the same) of forever renting goods leads to the abolition of private property, at least for the masses. Kind of funny that what looks like the the new epitome of capitalism so strangely resembles communism. What's your take on this?

      Corporate Feudalism.

    19. Re:Essentially by jbo5112 · · Score: 1

      macOS has more CVE findings released that Windows 10. Why would using macOS as a base be more secure?

  2. Please don't hurt me. by Anonymous Coward · · Score: 0

    OK, so how DO you keep the bad people out? Ideology certainly isn't working. Saying pretty-please isn't either.

    1. Re:Please don't hurt me. by guruevi · · Score: 5, Interesting

      That's not what the argument is about. UEFI SecureBoot has its place and reasons although an open implementation would be much better, Linux Kernel Lockdown has its place and reasons. Requiring one to enable the other is a problem or declaring that your system is broken without both enabled is a problem.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    2. Re: Please don't hurt me. by Monster_user · · Score: 4, Insightful

      "This discussion is over until you give an actual honest-to-goodness reason for why you tied the two features together. No more "Why not?" crap." -Torvalds

      Linux is a distribution by users, for users. So the individuals you are locking down are the developers and future developers of the operating system.

      "Keeping the bad guys out" is a nanny state problem for for-cost operating systems. You can tie secure boot and kernel lockdowns together if you want to outsource your I.T. to a third party or for-cost developer.

      The rest of us what to know what the difference is between what secure boot protect, and what kernel lockdowns protect. As well as to be able to enjoy our hobby without having to get a degree in cyber security to sign a kernel every time we want to try out a new OS or distribution.

    3. Re: Please don't hurt me. by Anonymous Coward · · Score: 1

      Lock your house so people can't get to your computer. Kernel lockdown is about keeping control of your own system. Tying It to secure boot, though, is about keeping whoever has possession of the system (you) from having total control of it.

    4. Re: Please don't hurt me. by Monster_user · · Score: 1

      Secure boot ensures that the kernel can't be modified prior to boot. Thus it eliminates a false sense of security. The goal is to ensure that an attacker with temporary physical access to a machine cannot compromise it fully.

      The question is what need or benefit is gained by having these two features intrinsically linked on the back end?

    5. Re: Please don't hurt me. by fibonacci8 · · Score: 2

      Thus it eliminates a false sense of security.

      I suspect you meant emanates there, mostly because I've just reread one of Bruce Schneier's essays.

      --
      Inheritance is the sincerest form of nepotism.
    6. Re: Please don't hurt me. by Anonymous Coward · · Score: 1

      The goal is to ensure nobody has full access to modify the system.

      FTFY.

    7. Re: Please don't hurt me. by Anonymous Coward · · Score: 0

      Then put the system on ROM! DUH!

    8. Re: Please don't hurt me. by sjames · · Score: 4, Informative

      That is an argument for having the ABILITY to use secure boot with a locked down kernel (Linus is fine with that). It is not an argument for why the kernel MUST be locked down if you use secure boot. The latter is what others are arguing for without providing Linus a good reason.

    9. Re: Please don't hurt me. by Anonymous Coward · · Score: 1

      Plus, there are other ways to solve the secure boot problem. For example, some systems I use boot from read-only media. Those would still benefit from the runtime protections of kernel lockdowns, but only one mention of that or other methods of securing boot by either side and the pro side for tying this to secure boot just blew it off with a "but how common is that?"

    10. Re: Please don't hurt me. by WaffleMonster · · Score: 4, Insightful

      Nanny state to ensure your HIPPA and PCI and SOX compliant servers at work do not have rootkits?

      If a system is rooted once a computer is booted then a few things MUST be true:

      1. You've already epically failed. It's game over right there and then. Talk about what happens next is mightily irrelevant.
      2. See 1.
      3. See 1.
      4. Unless vulnerability is found and fixed secure boot won't do shit to prevent the rootkit from being re-loaded upon next boot the same way it was loaded initially.

      I very much fail to see the point here. The only conclusion I could draw that would make any sense is when you get owned you can get away with tempting fate and not have to completely rollback system / rebuild all of your shit otherwise secure boot seems to be an exceedingly pointless waste of time.

      There is a much easier and much more secure way to handle this that does not require any cryptographic bullshit. Deny capability to modify OS image via hardware latch and don't allow any hardware to incorporate persistent storage that can be modified in the field.

      The real reason for secure boot isn't security. It's exclusively about locking out users in order to dictate terms.

      IT departments require UEFI secureboot with custom add in keys for their servers which Redhat and FreeBSD support I may add is to make sure you keep your job.

      Box checking jobs sure do pay well regardless of predictably feckless results.

    11. Re: Please don't hurt me. by Anonymous Coward · · Score: 0

      No, secure boot is in fact there for security, and only for security.

      Specifically, securing the device for the companies, since we can't have those filthy users making decisions or having unauthorized opinions, now can we?

    12. Re: Please don't hurt me. by Skuld-Chan · · Score: 1

      Serious question though - how do you as a Linux user protect physical security of the machine - say in the event someone breaks into your house/office without your knowledge, and installs a bootkit?

      I remember the guy who discovered all the Mac "ThunderStrike" vulnerabilities said in a presentation - Secureboot would have protected against that attack - and that was a vulnerability that could have been applied in the time it takes for you to turn your head at a coffee shop, talk to someone and turn your head back to continue using your computer (which is now compromised).

    13. Re: Please don't hurt me. by Anonymous Coward · · Score: 0

      Yep. Most people in the don't secure my boot camp know nothing about the extensiveness of getting into a PC or a cloud PC where you've staked your billions of dollars. At the heart of this is providing choice. As long as the administrator of the machine _wants_ secure boot enabled who's to say they can't. You're not paying for my customer's safety so why should I listen to you, so to speak. If there's a way to provide that choice of who needs it then it's all good. Obviously I hate the concept of vendor lock-ins as much as anyone. This is a two way street. There's a time and place for this tech. Just give the option and shut up.

    14. Re: Please don't hurt me. by q4Fry · · Score: 1

      I'm not a security whiz, but maybe with heads?

  3. Thanks for the summary by Anonymous Coward · · Score: 1

    What does any of this mean?

    1. Re: Thanks for the summary by Monster_user · · Score: 4, Informative

      Kernel Lockdown protects the kernel.

      Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.

      Together they are supposed to make it impossible to bypass or break the core things, which is supposed to make a computer more secure.

      Of course adding security breaks things. Such as open source drivers for hardware for which drivers do not exist. Which means that those needing exemptions to the security will lose both, not just one or the other. Reducing security overall.

    2. Re: Thanks for the summary by Junta · · Score: 5, Informative

      Secure Boot protects against malware and malicious hardware, as well as teenagers with Linux on USB thumb drives bypassing security altogether.

      Actually, it does none of that. This is one of my peeves with secureboot, it is annoying *and* largely ineffectual.

      On malware, yes, it would protect against a certain class of malware: boot sector virus. But then again, a subset. Sure you can't be a kernel, and that does hypothetically give the OS creators a foundation to have some layer that is intact. What if your malware is a patched gdm, sshd, pam, or agetty? Yeah, those would be fine. Windows still has plenty of malware despite being 'Secureboot'. What about replacing /etc/shadow in linux or the SAM db in Windows? Sure, that is also fair game, go ahead and insert your backdoor account with admin privilege.

      On malicious hardware, it doesn't do anything, though related technologies can cause UEFI drivers to not execute if not signed. The OS asks the platform if it is secureboot enabled and takes the answer at face value (there's no secure mechanism to vlaidate that the platform isn't lying to you).

      As far as Linux or Windows PE on USB thumb drives, again it doesn nothing. A windows or linux install disk can also be a 'rescue' disk. For that matter, secureboot covers neither the initramfs nor the wim file, so make your own privileged install media, it's all good as far as secureboot is concerned. You don't need a custom kernel to make a boot disk.

      With that, what are the protections against the general class of replacement hardware/boot configuration/boot media?

      Well, the weakest is a BIOS/UEFI/bootloader passwords, which in theory mitigates the chances someone can select their bootable media. In BIOS systems, it is common for USB disk to boot preferentially, so this might not pan out. The typical UEFI boot setup on the otherhand is a bit more specific by usually having a single boot item and that boot item being the machine specific boot partiion GUID and file. However even then I suspect you could probably discern the boot volume guid as non-admin user, and I don't know what UEFI will do if you have removable media with the same GUID as the boot volume. Also, none of this does a damn thing if the attacker could remove the boot media and mess with it offline.

      So now we have SED/BitLocker/dm-crypt soultions, which are more hardened. However, by themselves these make automatic reboots impossible, and are thus highly annoying. For another, the keyphrase prompt can be emulated and phished if an attacker has two cracks at your system (one to install a fake prompt using a valid kernel, another to go and glean the captured secret.

      At last we come to the most relevant security approach: Trusted Boot. Here you use SED/BitLocker/dm-crypt as above, but rather than prompting for password, you seal the key to TPM PCRs. This allows the system to boot and unlock automatically, but only if the user didn't do anything different (like boot form a different device, or enter f1 setup, or replaced the motherboard). Again at least one potential hole is whether you can spoof a GUID to trick the platform to boot with the same PCR state. another limitation is that generally you have a backup password, and a user could assume if they see the prompt, something innocuous went wrong rather than malicious (e.g. I had a device that went in for warranty repair, and the PCR state was lost forever and so I had to take it on faith the repair center nor the mail system did anything to phish the recovery prompt).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    3. Re: Thanks for the summary by Junta · · Score: 1

      Actually, I recall that time I held back my boot volume, so I knew they couldn't have modified it. I am trusting that the TPM is acting as advertised, but at some level that becomes unavoidable.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re: Thanks for the summary by thegarbz · · Score: 1

      Sure, that is also fair game, go ahead and insert your backdoor account with admin privilege.

      How? That would require access to the system itself. The point of secure boot is to close of a previously unclosable vector. It was never meant to protected against any changes to the OS itself, just the changes that can happen and persist outside of the OS.

      Just because it only targets boot sector based malware doesn't make it ineffectual. Quite the opposite actually since this was a malware vector which was previously effectively not protected against.

    5. Re: Thanks for the summary by Junta · · Score: 2

      How would they get a kernel-level virus onto the boot sector/partition? If a user has some method that would let them modify the boot volume, they have a way to modify passwd/shadow/SAM. Either the enduser runs something as admin (which admittedly full disk encryption would do nothing to stop) or an offline attack is required with or without secureboot (which full disk encryption can stop).

      My point is it only works against a subset of boot sector virus: ones that run a modified kernel or stage before the kernel. Malware can do plenty in userspace, and in many cases it's impossible for a generic subsytem to tell whether a userspace customization is authentic or malicious.

      Contrast this with disk encryption sealed to TPMs. This would ideally be modified such that there is a PCR mutated by fingerprints of efi executables. This would enable a shim.efi to do unsealing and have that particular OS vendor's chain of trust rooted without the firmware having to manage central keys and also providing meaningful protection against offline attacks.

      The other problem I have is that SecureBoot, practically speaking, makes MS the gatekeeper to the PC platform. You want to boot your OS on user systems, go talk to Microsoft. This has two effects:
      1) Gives MS too much control and a nice anti-competitive lever to use if they wanted.
      2) To do this without being perceived as anti-competitive and given resources, they probably have had to sign more than they should. This means there is likely some vulnerable stack that is signed floating about. In theory MS could revoke keys, but I don't think they ever have for one, and for another the chances that a user gets an update with an updated revocation database is far from guaranteed.

      I would have much preferred a spec that had the install media do a vendor-specific key install, and a mandatory baked in option to remove the key and revocation db. This would have given much more fine grained control for verification of vendor provided assets. At the end of the day though, full disk encryption is a mandatory part of your strategy if you really want to protect from offline attacks.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    6. Re: Thanks for the summary by thegarbz · · Score: 1

      If a user has some method that would let them modify the boot volume, they have a way to modify passwd/shadow/SAM.

      Not at all, we invented something called disk encryption which for obvious reasons either doesn't apply to the boot sector, or (and the brute force method) needs to be applied before the BIOS finishes it's job, and that is outside of the OS control and therefore not as common as managed processes such as those applied by the OS.

      The other problem I have is that SecureBoot, practically speaking, makes MS the gatekeeper to the PC platform.

      Yes now that IS a legitimate concern.

    7. Re: Thanks for the summary by Junta · · Score: 1

      Not at all, we invented something called disk encryption

      Which I went into, at length. Admittedly, I'm unsure if there is a TPM PCR mutated by the cryptographic hashes of EFI executables, but such a mechanism would allow arbitrary efi to execute, but mutate the PCRs to prevent disk encryption key from being unlocked if altered. In this way, a relatively simple shim.efi (the same sort that enables secureboot without having to get updates signed endlessly) could be responsible for both ensuring PCR validty to get a volume key, and then subsequently verify subsquent content, using vendor-specific verification mechanism.

      This would be secure, more accessible, and permit the OS to do a more thorough validation of the platform it is booting on (compared to taking the secureboot flag at face value)

      --
      XML is like violence. If it doesn't solve the problem, use more.
  4. Re:Still expensive here in Australia by thesupraman · · Score: 1

    You are in the wrong article..

    Try again.

  5. Re: Trump will be tied to a prison toilet by Type44Q · · Score: 1

    I bet you dream of being his toilet.

  6. Left wing fairy tales by Anonymous Coward · · Score: 0

    In your fantasy, he's going to prison FOREVER? Where? Azkaban? You're clearly in a paranoid delusional leftist fantasy, so I guess Azkaban makes senseS

  7. Nice straw man by Anonymous Coward · · Score: 2, Insightful

    uefi secure boot won't "keep the bad people out" either. In fact, uefi secure boot is a vehicle to take control away from you-the-computer-owner, and as such is the vehicle of bad people looking out for themselves using your hardware.

    1. Re: Nice straw man by Anonymous Coward · · Score: 0

      It's NOT "your hardware" though. It's THEIRS, with you paying rent one way or another. Just do nothing, wait and see!

  8. It means by Anonymous Coward · · Score: 0

    that unlike sir tim berners-lee, linus is not a complete sell-out and actually does put his foot down when it seems called for.

    1. Re: It means by Anonymous Coward · · Score: 0

      Linus has and continues to do more than come up with a hypertext protocol and ride that for the rest of his life.

  9. Thanks, but you're mistaken about both by raymorris · · Score: 3, Interesting

    First, kernel lockdown in no way restricts which drivers you might have running. If you want to *change* which drivers you have running without rebooting, you'll need to *sign* the new module. Absolutely nothing prevents you from signing an open-source module. The command is:

    scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko
    (Or just set check the box to sign all modules in make menuconfig).

    Sign-file signatures work for both secure boot and the kernel restriction. For the kernel, the first time you ever sign a module you enroll your public key with keyctl.

    1. Re:Thanks, but you're mistaken about both by Junta · · Score: 1

      Of course, this can't play well with akmods/dkms and still be secure, since for that to work you'd need the signing key easily available. So you will have to take a more tedious approach for out-of-distro drivers than before.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  10. You people are all nuts! by Anonymous Coward · · Score: 1

    How stupid can this be? You put everything on ROM. No time wasted 'loading' this and that. Who thought that shit up to begin with? A computer should always be in a ready to run state, just apply power.

    1. Re:You people are all nuts! by Anonymous Coward · · Score: 0

      With flash-drives there is not particular reason for drives to not be memory mapped anyway.
      Should just boot directly from the drive and copy the things you want fast access to to ram.

  11. While installing / compiling a new kernel by raymorris · · Score: 2

    The key only needs to be available while installing a new kernel (not all the time), and only on one system in your organization.

    Without the protection:
    At any time, any system on your network can have kernel-level code changed, from userspace.

    With the protection:
    Before you deploy a new kernel across your network, plug your USB stick with key into your build system in order to allow dkms to build and sign the module. Then unplug the stick so that your kernel can't be changed without you doing it.

    It gives you control of when and where your kernel can be changed, by dkms or any other program.

    1. Re:While installing / compiling a new kernel by Junta · · Score: 1

      The point is that DKMS/akmod type packages make out-of-tree drivers auto-handle updates, and any system can just be applying updates from vendor with no effort required to stage it, on each server.

      Here, you must vet every single kernel update and prepare your matching kmods prior to letting systems apply the fix.

      I didn't say you couldn't build your kernel as you describe, just that deploying akmods/dkms type driver packages to your systems becomes a non viable approach, and that a more tedious approach (as you describe).

      --
      XML is like violence. If it doesn't solve the problem, use more.
  12. *ctl it! by Anonymous Coward · · Score: 0

    just integrate it with SystemD already!

  13. Free SW movement should avoid locks to the users by Anonymous Coward · · Score: 0

    It seems to Tivoization

  14. Good For Linus by Anonymous Coward · · Score: 0

    The corporate mindset is diametrically opposed to the concept of ownership. This applies to computers, phones, game consoles, books, John Deere Tractors, and cars. Hey corporations, I bought this thing and can do anything that I damn well please with it.

    If you shove a some contract in front of me that tries to strip my rights, I walk. You just lost yourself a customer and sale for life.

    If you sue your customers for restoring functionality to their game consoles, you can expect a boycott of your products for life.

    If you tell your customers that they have to have their oil changed at the dealership or else violate the DMCA, screw you. May everyone who learns of your crap stop doing business with you.

    We're not just talking about the corporate nameplates. We are talking about the executives behind this treachery. It's time to start making a list.

  15. They will have it their way by barryvoeten · · Score: 1

    Well now Microsoft is investing more and more into open source and putting out linux updates like a champ, we might say they really care about what will happen. In this regard I can suggest the outcome that if L.T. does not bend (and he usually does not) they might even fork to ensure they have their version of linux the way they want it.

    1. Re:They will have it their way by JustNiz · · Score: 1

      > we might say they really care about what will happen.

      We might. Or we might say this is just yet another variant of embrace,extend,extinguish.that's been Microsoft's core strategy since MSDOS.

      > they might even fork
      That would be the dumbest idea ever because no-one with an actual clue would take their fork as seriously as the "real" Linux, but nothing would surprise me when dealing with Microsoft or the clueless management types that keep buying/deploying their products.

  16. Worse -- not communism just rentier capitalism -- by bdwoolman · · Score: 1

    Using tons of evidence Thomas Piketty points out in his book Capital in the Twenty-First Century that capital will naturally always grow at a higher rate than the rate of economic growth (read: wages).

    From Wkipedia: "The book's central thesis is that when the rate of return on capital (r) is greater than the rate of economic growth (g) over the long term, the result is concentration of wealth, and this unequal distribution of wealth causes social and economic instability."

    The rentier capitalist state is pretty much a done deal IMHO. The software subscription model being but a single case in point -- not to mention the cloud.

    Remember the property grab during the last bubble burst? For those who are prepared with lots of cash these deflationary episodes are a peak opportunity. Market makers do their best to engineer them periodically (but not too often) to get equity at fire-sale prices as well as to scoop up real property, which can be rented, mined, developed, farmed, resold etc. Real estate is especially attractive in the long run because in the end there really is only land -- as any aristocrat will tell you. Control the land and you control.... everything. A few more bubble bursts and voila! Eighteenth Century France.

    --
    "No fear. No envy. No meanness." Liam Clancy
  17. Re:Trump will be tied to a prison toilet by jbo5112 · · Score: 1

    Why should Trump be tied to a prison toilet? He isn't under investigation for criminal activity.