4 ms·

It has always seemed quite obvious to me that dealing in machine code is a flawed approach for distributing software. At the most basic level, it entails giving

It has always seemed quite obvious to me that dealing in machine code is a flawed approach for distributing software. At the most basic level, it entails giving someone else near unfettered access to the hardware of your computer and simply hoping that they do nothing malicious or malformed. Yet the software world as a whole seems continually shocked at the idea of using anything else. Perhaps someday we will learn this lesson in its entirety and begin to share code rather than blobs.

yjftsjthsd-h 3y ago
I don't think machine code is the problem? Running a native binary doesn't give it access to anything inherently; the OS gives access through syscalls, and can impose restrictions - and indeed, does; it's not like running a binary on Linux automatically gives it access to anything under /dev. Also, it's not that the whole software world thinks blob-only software is normal; I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware. (Edit: And to be quite clear, a good chunk of this community would really like to get rid of those blobs too, it's just that we don't have a fix at this point.)
- James_K 3y ago
  > Running a native binary doesn't give it access to anything inherently While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases. The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor. > I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.
  - gggmaster 3y ago
    It's better than an OS that you have no control from top to bottom. But sure, it isn't ideal.
  - avianlyric 3y ago
    > The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs That’s not really how the software/OS relationship works. By default OS’s run software in very unprivileged CPU security contexts, where they can’t really do anything beyond but operate on memory the OS allocated to the software, with CPU instructions can’t talk directly to other hardware, or read/write memory beyond the bounds the OS specified. To do literally anything else, like open a file, write to a file, talk to a network interface, talk directly to other hardware connected to the CPU. The software needs to use a syscall, and effectively ask the OS to perform the operation on its behalf. Every single dangerous operation you can perform is guarded by the OS, the OS doesn’t validate anything, it simply decides to perform the operations requested, or it decides not to perform those operations. The only reason why software expects so much unfettered access to a system is simply because OS have historical not limited what software was allowed to do, OS’s simply performed whatever operation was requested of them without question. It only in the last 20 years or so that security became a concern, and it occurred to us that allowing software to just do whatever it wants is probably a bad idea. But the genie is out of the bottle, and it’s proving hard to put it back in. So retroactive work to limit what software can do by default, without simply breaking everything, is slow and difficult. If you ever want to understand why you can do somethings on MacOS, but not iOS, then this is a pretty good place to start (if we ignore Apple’s brand and commercial reasons for a moment). iOS only ever supported tightly sandboxed apps, that had to play nice with a draconian permissions system, where as MacOS is more standard OS, that was originally developed in the age before security was really a concern. So it’s easy to enforce tight sandboxing on iOS, where software has always had to deal with it, but hard on MacOS, where for the majority of MacOS history, sandboxing simply didn’t exist. > rather than a source-based approach in which malware is never allowed to touch the processor. That’s a nice idea, but doesn’t really hold up to scrutiny. You need to look at the ever increasing number of supply chain attacks to realise that simply being open source does little to ensure malware doesn’t make it onto your machine. And that before we get into issues like heart bleed, where the OSS software on your machine may contain bugs or errors that allow remote parties to gain access to privileged data or credentials, via OSS software that isn’t malware, it just got bugs in it. At the end of the day, it doesn’t really matter what magical security boundaries you develop, someone will find a way around it. Which is why defence in depth is such an important principle. Simply relying on the idea that Open Source means no malware is foolish. You need proper OS defences regardless.
frozenport 3y ago
Android and mobile platform make it hard to distribute as fully compiled source.
deleted 3y ago
[deleted]
brcmthrowaway 3y ago
ChatGPT?
akira2501 3y ago
"That's a really cool security aware script language you've got there! So.. um.. how can I extend it to call third party libraries?" Perhaps the idea that "the computer" is one single entity with a shared security domain and view of hardware is the flaw. Why can my web browser read my tax documents unless I go through a bunch of rather absurd efforts to prevent something so simple?
- xorcist 3y ago
  Because you want to be able do report your taxes documents to the tax office? It's one of those things that sound so simple on paper, but every time someone does that trivial thing and not make documents available to the web browser, usability suffers. The real answer why the browser can read certain files is much more complex, your web browser is not a singular entity anymore. And the network and protcol speaking parts of it can't access your documents, according to the principle of least authority. It's far from perfect and gets hacked every time, but do take the time to read how that's done. The hacks are just as complex as the web browser itself. The practical problem with the browser is the enormous complexity of functions, everything from OpenGL to databases to p2p and usb, that keeps growing boundlessly.
  - akira2501 3y ago
    Right.. which is why "home PC" is one of the largest attack surfaces we have. The fact that tax authorities expect you to brave the gap is only one of the problems with this configuration. The web browser _purports_ to be that entity. The list of CVEs shows that it isn't. If I install a "web browser" I'm installing "a binary program that can access anything it wants at any time it wants." "Do take the time to read" is an absurdly condescending thing to say while simultaneously moving the goalposts of the argument.

yjftsjthsd-h 3y ago

I don't think machine code is the problem? Running a native binary doesn't give it access to anything inherently; the OS gives access through syscalls, and can impose restrictions - and indeed, does; it's not like running a binary on Linux automatically gives it access to anything under /dev. Also, it's not that the whole software world thinks blob-only software is normal; I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware. (Edit: And to be quite clear, a good chunk of this community would really like to get rid of those blobs too, it's just that we don't have a fix at this point.)

James_K 3y ago
> Running a native binary doesn't give it access to anything inherently While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases. The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor. > I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.
- gggmaster 3y ago
  It's better than an OS that you have no control from top to bottom. But sure, it isn't ideal.
- avianlyric 3y ago
  > The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs That’s not really how the software/OS relationship works. By default OS’s run software in very unprivileged CPU security contexts, where they can’t really do anything beyond but operate on memory the OS allocated to the software, with CPU instructions can’t talk directly to other hardware, or read/write memory beyond the bounds the OS specified. To do literally anything else, like open a file, write to a file, talk to a network interface, talk directly to other hardware connected to the CPU. The software needs to use a syscall, and effectively ask the OS to perform the operation on its behalf. Every single dangerous operation you can perform is guarded by the OS, the OS doesn’t validate anything, it simply decides to perform the operations requested, or it decides not to perform those operations. The only reason why software expects so much unfettered access to a system is simply because OS have historical not limited what software was allowed to do, OS’s simply performed whatever operation was requested of them without question. It only in the last 20 years or so that security became a concern, and it occurred to us that allowing software to just do whatever it wants is probably a bad idea. But the genie is out of the bottle, and it’s proving hard to put it back in. So retroactive work to limit what software can do by default, without simply breaking everything, is slow and difficult. If you ever want to understand why you can do somethings on MacOS, but not iOS, then this is a pretty good place to start (if we ignore Apple’s brand and commercial reasons for a moment). iOS only ever supported tightly sandboxed apps, that had to play nice with a draconian permissions system, where as MacOS is more standard OS, that was originally developed in the age before security was really a concern. So it’s easy to enforce tight sandboxing on iOS, where software has always had to deal with it, but hard on MacOS, where for the majority of MacOS history, sandboxing simply didn’t exist. > rather than a source-based approach in which malware is never allowed to touch the processor. That’s a nice idea, but doesn’t really hold up to scrutiny. You need to look at the ever increasing number of supply chain attacks to realise that simply being open source does little to ensure malware doesn’t make it onto your machine. And that before we get into issues like heart bleed, where the OSS software on your machine may contain bugs or errors that allow remote parties to gain access to privileged data or credentials, via OSS software that isn’t malware, it just got bugs in it. At the end of the day, it doesn’t really matter what magical security boundaries you develop, someone will find a way around it. Which is why defence in depth is such an important principle. Simply relying on the idea that Open Source means no malware is foolish. You need proper OS defences regardless.

frozenport 3y ago

Android and mobile platform make it hard to distribute as fully compiled source.

deleted 3y ago

[deleted]

brcmthrowaway 3y ago

ChatGPT?

akira2501 3y ago

"That's a really cool security aware script language you've got there! So.. um.. how can I extend it to call third party libraries?" Perhaps the idea that "the computer" is one single entity with a shared security domain and view of hardware is the flaw. Why can my web browser read my tax documents unless I go through a bunch of rather absurd efforts to prevent something so simple?

xorcist 3y ago
Because you want to be able do report your taxes documents to the tax office? It's one of those things that sound so simple on paper, but every time someone does that trivial thing and not make documents available to the web browser, usability suffers. The real answer why the browser can read certain files is much more complex, your web browser is not a singular entity anymore. And the network and protcol speaking parts of it can't access your documents, according to the principle of least authority. It's far from perfect and gets hacked every time, but do take the time to read how that's done. The hacks are just as complex as the web browser itself. The practical problem with the browser is the enormous complexity of functions, everything from OpenGL to databases to p2p and usb, that keeps growing boundlessly.
- akira2501 3y ago
  Right.. which is why "home PC" is one of the largest attack surfaces we have. The fact that tax authorities expect you to brave the gap is only one of the problems with this configuration. The web browser _purports_ to be that entity. The list of CVEs shows that it isn't. If I install a "web browser" I'm installing "a binary program that can access anything it wants at any time it wants." "Do take the time to read" is an absurdly condescending thing to say while simultaneously moving the goalposts of the argument.