4 ms·

> 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

> 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. That's common, but it's certainly not a requirement to run native code. For example, we've done a pretty good job at retroactively fixing that while preserving backwards compatibility with containers (I can, and have run normal official Firefox binaries inside a docker container with zero access to my real home directory) or sandboxes like flatpak (bubblewrap). If you want to run real native binaries but don't have to preserve backwards compatibility, then it gets easy; genode ( https://genode.org/ https://genode.org/ ) does a lovely job of truly practicing only giving programs what access you want to give them. > 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 think you're overoptimistic regarding what you can do with the source code short of manual (human) auditing. I mean, sure there are things you can scan for to try and catch bad behavior, but in the case of actual malice I wouldn't trust automatic code analysis to protect me. >> 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. I have no idea why you think either of those things? Depending on the distro I certainly can compile from source on my own box (ex. Gentoo, NixOS), but I can also use precompiled binaries (ex. Debian, NixOS) while still having it be trivial to go find the exact source that went in to the binary package I downloaded (this has gotten even stronger with Reproducibility efforts meaning that I can even verify the exact source and build config that created a specific binary). The actual application software and OS are available as Open Source code that can be audited, with binaries available as a convenience, and the only remaining blobs (unwelcome but impractical to fix so far) are firmware blobs with relatively constrained roles (and on machines with an IOMMU we can even enforce what access they have, which is a nice mitigation).

James_K 3y ago
> I think you're overoptimistic regarding what you can do with the source code Suppose you have a Java function. If you remove the file-system class at a system level, what can that code do? It's pretty easy to isolate it so that it cannot compile to any kind of malicious code, only conduct computations to produce values. That's why you can open a website running JavaScript without as much worry for the security of your computer as you would have downloading a blob and running it. > I have no idea why you think either of those things? Well most of the software on your computer has the following api: int main(int argc, char **argv) This is because it needs to run as an executable. Without this requirement, software might have much more interesting APIs which are much more useful. But instead there is a requirement that all software is mashed into blobs and has all of the useful information removed from it. Additionally, just compiling the software from source does nothing to guarantee that it isn't malware. You can compile malware from source just as easily as anything else. The system I'm proposing does not allow for malicious programs to be compiled.
- EraYaN 3y ago
  You know that a main function is not really the only way to do programs right? Like shell integrations and other such things are exactly what you talk about. Those are software with "interesting APIs". It just does not make a lot of sense for a foreground application or at least some application that needs control. And besides if you have a look at Apple platforms and how they do communication with running applications, "interesting APIs" right there. And finally there is no requirement at all that ELF binaries are stripped of useful info (symbols, debug info etc), there is a desire though to save disk space and make reverse engineering harder. All of this has nothing to do with the executable code format (native vs byte code or what have you).
  - James_K 3y ago
    > You know that a main function is not really the only way to do programs right? > there is no requirement at all that ELF binaries are stripped of useful info Yes, you can add useful information to a program. This is what I'm advocating for. The issue is that most people don't do this, which is what I'm complaining about. Consider the difference between distributing executable files vs. Python libraries for instance. > All of this has nothing to do with the executable code format I don't see how you can write an entire comment about the format in which code is distributed and come to this conclusion.

James_K 3y ago

> I think you're overoptimistic regarding what you can do with the source code Suppose you have a Java function. If you remove the file-system class at a system level, what can that code do? It's pretty easy to isolate it so that it cannot compile to any kind of malicious code, only conduct computations to produce values. That's why you can open a website running JavaScript without as much worry for the security of your computer as you would have downloading a blob and running it. > I have no idea why you think either of those things? Well most of the software on your computer has the following api: int main(int argc, char **argv) This is because it needs to run as an executable. Without this requirement, software might have much more interesting APIs which are much more useful. But instead there is a requirement that all software is mashed into blobs and has all of the useful information removed from it. Additionally, just compiling the software from source does nothing to guarantee that it isn't malware. You can compile malware from source just as easily as anything else. The system I'm proposing does not allow for malicious programs to be compiled.

EraYaN 3y ago
You know that a main function is not really the only way to do programs right? Like shell integrations and other such things are exactly what you talk about. Those are software with "interesting APIs". It just does not make a lot of sense for a foreground application or at least some application that needs control. And besides if you have a look at Apple platforms and how they do communication with running applications, "interesting APIs" right there. And finally there is no requirement at all that ELF binaries are stripped of useful info (symbols, debug info etc), there is a desire though to save disk space and make reverse engineering harder. All of this has nothing to do with the executable code format (native vs byte code or what have you).
- James_K 3y ago
  > You know that a main function is not really the only way to do programs right? > there is no requirement at all that ELF binaries are stripped of useful info Yes, you can add useful information to a program. This is what I'm advocating for. The issue is that most people don't do this, which is what I'm complaining about. Consider the difference between distributing executable files vs. Python libraries for instance. > All of this has nothing to do with the executable code format I don't see how you can write an entire comment about the format in which code is distributed and come to this conclusion.