3 ms·

I know all that. The process you describe is the OS verifying the behaviour of software as it runs. >That’s a nice idea, but doesn’t really hold up to scrutiny

I know all that. The process you describe is the OS verifying the behaviour of software as it runs. >That’s a nice idea, but doesn’t really hold up to scrutiny It does actually. The kind of attack you describe only works because software exists in non-source based systems. If you were going to run a Haskell function, and you were told that I was going to modify its body in some way, there is no way I can insert malware into it because you cannot reach out of the context of the function and mess with the operating system. Software is composed of functions, which naturally run in a fully containerised state and only become dangerous when the OS adds an additional layer of computer-wide state.

avianlyric 3y ago
> Software is composed of functions, which naturally run in a fully containerised state That’s simply not true. It’s a convenient fiction that modern programming languages provide, but they only provide it by virtue of not providing API to access external state, and even that isn’t true. Most programming languages do let you access state beyond a functions stack, in the simplest form by allowing your function to interact with data stored on a heap. There’s absolutely nothing about software that inherently results in “functions, which naturally run in a fully containerised state”. Functions are just a useful abstraction, in the same way an OS’s APIs are also just useful abstraction. There’s absolutely nothing that makes function scopes inherently more secure than OS APIs. Arguably function scopes are vastly less secure than OS APIs, there’s a good reason why stack overflows are one of the most common forms of Remote Code Execution exploits.
- James_K 3y ago
  > Functions are just a useful abstraction Yes. Containers are also just a useful abstraction. And both of them are contained, unless you add something that exposes their environment.
  - avianlyric 3y ago
    That is kind of my point. To claim that functions are somehow more secure than containers, or just standard process isolation (which is basically all container are), is just silly. Functions are no more inherently secure than containers. Both abstraction are contained, until something exposes the external environment to them, both of them can be configured to simply not do that.
    - James_K 3y ago
      The claim that functions are more secure is quite reasonable, and it stems from the fact that they are simple. You or I could write a contained function, or even a piece of software that verifies a function is contained by scanning its source code. We could do this in perhaps a few weeks of spare time. Compare and contrast to the effort that goes into other containerisation techniques. Docker would take more that a week of spare time to write. It is orders or magnitude more complex.
      - avianlyric 3y ago
        > Compare and contrast to the effort that goes into other containerisation techniques. Docker would take more that a week of spare time to write. It is orders or magnitude more complex. That’s because you’re comparing a butter knife to a chainsaw. You can quite easily run an entire process in manner that just as limited as simple function by using something like seccomp[1] which prevents the process from doing anything except exiting, or read/writing to file handles that have already been opened as pass to it. No need to spend a weekend or whatever writing something to “verify a function is contained”, or anything like that. Just give your process to the OS and tell the OS to contain it. Heck if you’re on a system with systemd, all you need a handle full of lines of config, and you’re done. No need to worry about how good your static analysis is (spoiler alert, it’s never good enough), or creating a new language, or reading anyone’s code. You use containerisation frameworks when you want your software to be able to interact with the world, but want to be able to carefully analyse and limit how it interacts with the wider world. It’s total overkill if you just want to execute code that performs computations without interacting with other systems. [1] https://en.m.wikipedia.org/wiki/Seccomp https://en.m.wikipedia.org/wiki/Seccomp

avianlyric 3y ago

> Software is composed of functions, which naturally run in a fully containerised state That’s simply not true. It’s a convenient fiction that modern programming languages provide, but they only provide it by virtue of not providing API to access external state, and even that isn’t true. Most programming languages do let you access state beyond a functions stack, in the simplest form by allowing your function to interact with data stored on a heap. There’s absolutely nothing about software that inherently results in “functions, which naturally run in a fully containerised state”. Functions are just a useful abstraction, in the same way an OS’s APIs are also just useful abstraction. There’s absolutely nothing that makes function scopes inherently more secure than OS APIs. Arguably function scopes are vastly less secure than OS APIs, there’s a good reason why stack overflows are one of the most common forms of Remote Code Execution exploits.

James_K 3y ago
> Functions are just a useful abstraction Yes. Containers are also just a useful abstraction. And both of them are contained, unless you add something that exposes their environment.
- avianlyric 3y ago
  That is kind of my point. To claim that functions are somehow more secure than containers, or just standard process isolation (which is basically all container are), is just silly. Functions are no more inherently secure than containers. Both abstraction are contained, until something exposes the external environment to them, both of them can be configured to simply not do that.
  - James_K 3y ago
    The claim that functions are more secure is quite reasonable, and it stems from the fact that they are simple. You or I could write a contained function, or even a piece of software that verifies a function is contained by scanning its source code. We could do this in perhaps a few weeks of spare time. Compare and contrast to the effort that goes into other containerisation techniques. Docker would take more that a week of spare time to write. It is orders or magnitude more complex.
    - avianlyric 3y ago
      > Compare and contrast to the effort that goes into other containerisation techniques. Docker would take more that a week of spare time to write. It is orders or magnitude more complex. That’s because you’re comparing a butter knife to a chainsaw. You can quite easily run an entire process in manner that just as limited as simple function by using something like seccomp[1] which prevents the process from doing anything except exiting, or read/writing to file handles that have already been opened as pass to it. No need to spend a weekend or whatever writing something to “verify a function is contained”, or anything like that. Just give your process to the OS and tell the OS to contain it. Heck if you’re on a system with systemd, all you need a handle full of lines of config, and you’re done. No need to worry about how good your static analysis is (spoiler alert, it’s never good enough), or creating a new language, or reading anyone’s code. You use containerisation frameworks when you want your software to be able to interact with the world, but want to be able to carefully analyse and limit how it interacts with the wider world. It’s total overkill if you just want to execute code that performs computations without interacting with other systems. [1] https://en.m.wikipedia.org/wiki/Seccomp https://en.m.wikipedia.org/wiki/Seccomp