5 ms·

Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and pri

Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other technology that allows easy compartmentalization with somewhat reasonable security isolation out of the box for existing server code. Containers are not perfect, and hypervisors/unikernels are a pain to deploy on commodity cloud services but we are slowly getting there. (Also if you notice, newer generation of operating systems like Android, iOS, Fuchsia are moving towards strong sandboxing with every single thing locked down where possible. There is an impedance mismatch between the Unix model and current demands. You can't migrate overnight so you build technologies to work around it. From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app)

taeric 7y ago
This gets silly, though. If you are going for full isolation where applications can't just let the user have data, then you have to coordinate every app talking to every other app. This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Is it safer? Hard to say. I can do less and have less capabilities without more active work from the developers. There is something to be said for this, of course. But it seems a losing game. I contend there is no technical panacea to security versus convenience.
- GauntletWizard 7y ago
  There is no technical panacea, but containers are a useful abstraction. Containers bring back the original intent of the unix process/user security model, allowing you to scope each process to have it's own 'private' filesystem to get around the broken way executables are built, packaged, and linked. This doesn't save you if you do dumb things, like have open ports that allow administrative access that are exposed to the rest of your (potentially malicious) system. They do force you to think about some of the questions, though, like "Where is my data stored and how do other tools interact with it?" Most of the problems that people complain containers don't solve are ones that are open ended, and have no definite solution.
  - taeric 7y ago
    containers are a great tool for corporate servers. For end user machines, it is a tougher sell.
    - GauntletWizard 7y ago
      What do you think of the permissions associated with Android apps? Each developer gets a separate and cordoned user account on your phone. They only have access to private storage unless they request it through special APIs. Android apps are run in containers, for some broad sense of the word. That's how it should be. Every app I run should be run with a simply configured set of permissions, and "per app" or "as user" makes sense, even in the desktop space. That's what snap originally tried to do (but failed at, and have now broken)
      - taeric 7y ago
        Isn't that where I said it can get silly? I don't want developers having an account on my phone. I just want to process some data on my phone. Consider that on my phone, I am limited to accessing my data for most apps through the apps. On my computer, I typically know where the data is stored.
- robocat 7y ago
  > This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Off topic, but I don't understand your objection... On Android Chrome the share button shows you a context sensitive choice of apps that will accept the object (a link, some text, etc), followed by a second choice of what the app can do with the object. The flow for copy-then-paste is more convoluted and is waaay less discoverable. Copy then paste is still available for the situations where it has an advantage.
  - taeric 7y ago
    copy-then-paste is only more convoluted if you haven't learned how computers have worked for a long time. And things have gotten some better for the phone option. But I don't have or want all apps installed. So, my sharing is dominated by copy/paste, still.
eyberg 7y ago
Deploying a hypervisor on top of a hypervisor (eg: a public cloud) usually makes very little sense so I don't see that as a trend. However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) so hypervisors typically in the form of ESX is still very much a thing and now that we are seeing tighter integration with things like unikernels that is where the 'comeback' is coming from. I would almost go as far to say that it's becoming hip not to be using public cloud today. Deploying a unikernel on top of commodity cloud is very achievable and easy today - I know because I'm involved with https://ops.city https://ops.city . I'd argue it's ridiculously easier than trying to deploy a container, clearly way safer and even faster and easier than using something like terraform. I do very much agree with your impedance mismatch re: unix model thought though.
- mynegation 7y ago
  > However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good at it. I know people who have to move servers and applications to a different data centre because the lease on an old DC is ending, it is a huge headache, and they would much rather concentrate on their core business.
  - eyberg 7y ago
    I don't know who you specifically work for but I've been to 2 different banking tech conferences in the past month. JPMorgan mentioned they have 13 (or was it 16?) wholly owned datacenters. BoA's tech summit was just this past week in Palo Alto and they were highly negative of anything public cloud. For them it is an extremely rare thing for them to put anything in public cloud. A point they stressed throughout the summit is that the main thing they sell is 'trust' (eg: by holding people's money) and that is quite simply not something they are willing to delegate to others and that's the main driver for them but of course all the other things like cost, security, regulatory, and data gravity are drivers as well.
nostrademons 7y ago
An idea I've been toying around with but don't have time to fully explore or implement: The unit of isolation should be the library, not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can outlive the method call. So every time you call outside your own code assembly, you know that that call can't access the network, can't write to disk, can't display anything to screen. If you need it to, you explicitly pass the connection to a particular host or a handle to a particular directory, and then it can't access anything outside of that. Not sure if this is feasible performance-wise: if you do it at the binary level, it seems like it'd require remapping page tables and flushing the TLB with every external function call, which'd absolutely kill frameworks that have to execute callbacks many times a second. But there's a certain intuitive sense to making the unit of trust & communication the code written by a certain organization, and it also fixes attacks like npm malicious modules that haven't gotten all that much attention nor have effective mitigations beyond "audit all your dependencies".
- tsimionescu 7y ago
  Given that some of the most commonly used external libraries do networking, IO, graphics and encryption, I don't think this would really be feasible.
  - nostrademons 7y ago
    Presumably they'd have to be rewritten, but if you're talking a new OS anyway everything's gotten be rewritten, because you won't have the standard UNIX syscalls. This is not something to embark on lightly, which is why I haven't embarked on it yet. But imagine a future where using a traditional OS means there's close to a 100% chance that you will have your identity and/or financial assets stolen, or where these computers are widely used in the military and a security failure literally means you're dead. We're headed there anyway, judging from all the headlines on data breaches and identity theft. There'll be system failure at that point, as well as a strong incentive to rewrite everything as a secure system.
c256 7y ago
> From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app) DOS and such were designed around everything on the device being shared, with conflicts resolved at the application layer. Windows was built to maintain some (even ideological) compatibility with that world, while adding some of the benefits of separation and sharing (for example, moving away from the world where every piece of a job could crash/co-opt/exfiltrate the entire device). Unix (Multics, CTSS, ITSS, etc) was built to enable a world where multiple jobs (not processes; even then lots of jobs were multi-process) and multiple people could share the device. Threads, jails, cgroups, etc were added to move to a world where sharing wasn’t entirely cooperative and trusting. VMs, containers, and hypervisors are on the recent end of that same movement, along with wasm and JS sandboxing. In the end, it’s a balancing act between performance (speed, power, cost) versus safety, often starting from different points. Exo-, uni-, and library-kernels are similar efforts that haven’t (yet?) caught on, but there’s a pretty clear direction of movement towards the strongest isolation that our (currently quite flawed) hardware can afford.
- tarsinge 7y ago
  This comment made me remember my first Mac where when you launched an app it was given complete control over the hardware, with ASM calls to the Mac Toolbox. Remembering these times it makes me wonder why should there be only one direction, and that maybe there is an alternative to putting all our most sensitive data in every internet connected devices? In old times when you had a computer to do some hobby like games, photo editing, music, etc... the data was only related to that activity, and in the worst case of nuking the hard drive you lost only that work.
rgbrenner 7y ago
Other than the newer web tech initiatives like WebAssembly/JS sandboxing Yes, this is the lightest weight isolation that's somewhat secure for random code.. And considering that we regularly find exploits that escape that sandbox, I would never use it to run some random persons code on a server. Yes, we do that all the time in the browser, but that's a more limited environment where a single user is choosing what to run... whereas on a server, anyone who wants to attack the service can just upload whatever code they want. I know Cloudflare is doing it in Cloudflare Workers... and I think that's crazy. They're inspecting the code, and they added OS sandboxing... so that's a little better.. but trusting the JS sandbox in that environment is just nuts. Wouldn't surprise me if this ended up being another cloudbleed. If you want to run random code, the only safe option right now is to use a heavier form of isolation like a VM (and even that is not perfect). The performance loss is the necessary trade off to allow random people to run code (some of whom are deliberately attacking the service). This is the downside to the "cloud"... performance losses to allow random people to share servers.
takeda 7y ago
In a business environment the code you run is typically the code you wrote. You generally don't run unfamiliar code if you do, you are not being careful. All it takes is to have a container contain a backdoor that phones home, and essentially give someone access to inside of your network.

taeric 7y ago

This gets silly, though. If you are going for full isolation where applications can't just let the user have data, then you have to coordinate every app talking to every other app. This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Is it safer? Hard to say. I can do less and have less capabilities without more active work from the developers. There is something to be said for this, of course. But it seems a losing game. I contend there is no technical panacea to security versus convenience.

GauntletWizard 7y ago
There is no technical panacea, but containers are a useful abstraction. Containers bring back the original intent of the unix process/user security model, allowing you to scope each process to have it's own 'private' filesystem to get around the broken way executables are built, packaged, and linked. This doesn't save you if you do dumb things, like have open ports that allow administrative access that are exposed to the rest of your (potentially malicious) system. They do force you to think about some of the questions, though, like "Where is my data stored and how do other tools interact with it?" Most of the problems that people complain containers don't solve are ones that are open ended, and have no definite solution.
- taeric 7y ago
  containers are a great tool for corporate servers. For end user machines, it is a tougher sell.
  - GauntletWizard 7y ago
    What do you think of the permissions associated with Android apps? Each developer gets a separate and cordoned user account on your phone. They only have access to private storage unless they request it through special APIs. Android apps are run in containers, for some broad sense of the word. That's how it should be. Every app I run should be run with a simply configured set of permissions, and "per app" or "as user" makes sense, even in the desktop space. That's what snap originally tried to do (but failed at, and have now broken)
    - taeric 7y ago
      Isn't that where I said it can get silly? I don't want developers having an account on my phone. I just want to process some data on my phone. Consider that on my phone, I am limited to accessing my data for most apps through the apps. On my computer, I typically know where the data is stored.
robocat 7y ago
> This is why the share button on a phone is ridiculous. Instead of just copy to clip board, you get a ton of options. Off topic, but I don't understand your objection... On Android Chrome the share button shows you a context sensitive choice of apps that will accept the object (a link, some text, etc), followed by a second choice of what the app can do with the object. The flow for copy-then-paste is more convoluted and is waaay less discoverable. Copy then paste is still available for the situations where it has an advantage.
- taeric 7y ago
  copy-then-paste is only more convoluted if you haven't learned how computers have worked for a long time. And things have gotten some better for the phone option. But I don't have or want all apps installed. So, my sharing is dominated by copy/paste, still.

eyberg 7y ago

Deploying a hypervisor on top of a hypervisor (eg: a public cloud) usually makes very little sense so I don't see that as a trend. However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) so hypervisors typically in the form of ESX is still very much a thing and now that we are seeing tighter integration with things like unikernels that is where the 'comeback' is coming from. I would almost go as far to say that it's becoming hip not to be using public cloud today. Deploying a unikernel on top of commodity cloud is very achievable and easy today - I know because I'm involved with https://ops.city https://ops.city . I'd argue it's ridiculously easier than trying to deploy a container, clearly way safer and even faster and easier than using something like terraform. I do very much agree with your impedance mismatch re: unix model thought though.

mynegation 7y ago
> However, outside of the valley bubble many large sectors of the economy do not use public clouds (such as banking, health, defense) I work in traditional finance, outside of Silicon Valley and there is a huge drive to move to the public cloud. For the same reason banks do not own their office buildings anymore - managing computing infrastructure is not their core business and - to be honest - they are not very good at it. I know people who have to move servers and applications to a different data centre because the lease on an old DC is ending, it is a huge headache, and they would much rather concentrate on their core business.
- eyberg 7y ago
  I don't know who you specifically work for but I've been to 2 different banking tech conferences in the past month. JPMorgan mentioned they have 13 (or was it 16?) wholly owned datacenters. BoA's tech summit was just this past week in Palo Alto and they were highly negative of anything public cloud. For them it is an extremely rare thing for them to put anything in public cloud. A point they stressed throughout the summit is that the main thing they sell is 'trust' (eg: by holding people's money) and that is quite simply not something they are willing to delegate to others and that's the main driver for them but of course all the other things like cost, security, regulatory, and data gravity are drivers as well.

nostrademons 7y ago

An idea I've been toying around with but don't have time to fully explore or implement: The unit of isolation should be the library, not the process. Each time you call into another developer's library, the library should have only the privileges you explicitly pass to it as capabilities, and you should be able to specify whether these capabilities may be delegated outside the receiving library and whether they can outlive the method call. So every time you call outside your own code assembly, you know that that call can't access the network, can't write to disk, can't display anything to screen. If you need it to, you explicitly pass the connection to a particular host or a handle to a particular directory, and then it can't access anything outside of that. Not sure if this is feasible performance-wise: if you do it at the binary level, it seems like it'd require remapping page tables and flushing the TLB with every external function call, which'd absolutely kill frameworks that have to execute callbacks many times a second. But there's a certain intuitive sense to making the unit of trust & communication the code written by a certain organization, and it also fixes attacks like npm malicious modules that haven't gotten all that much attention nor have effective mitigations beyond "audit all your dependencies".

tsimionescu 7y ago
Given that some of the most commonly used external libraries do networking, IO, graphics and encryption, I don't think this would really be feasible.
- nostrademons 7y ago
  Presumably they'd have to be rewritten, but if you're talking a new OS anyway everything's gotten be rewritten, because you won't have the standard UNIX syscalls. This is not something to embark on lightly, which is why I haven't embarked on it yet. But imagine a future where using a traditional OS means there's close to a 100% chance that you will have your identity and/or financial assets stolen, or where these computers are widely used in the military and a security failure literally means you're dead. We're headed there anyway, judging from all the headlines on data breaches and identity theft. There'll be system failure at that point, as well as a strong incentive to rewrite everything as a secure system.

c256 7y ago

> From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app) DOS and such were designed around everything on the device being shared, with conflicts resolved at the application layer. Windows was built to maintain some (even ideological) compatibility with that world, while adding some of the benefits of separation and sharing (for example, moving away from the world where every piece of a job could crash/co-opt/exfiltrate the entire device). Unix (Multics, CTSS, ITSS, etc) was built to enable a world where multiple jobs (not processes; even then lots of jobs were multi-process) and multiple people could share the device. Threads, jails, cgroups, etc were added to move to a world where sharing wasn’t entirely cooperative and trusting. VMs, containers, and hypervisors are on the recent end of that same movement, along with wasm and JS sandboxing. In the end, it’s a balancing act between performance (speed, power, cost) versus safety, often starting from different points. Exo-, uni-, and library-kernels are similar efforts that haven’t (yet?) caught on, but there’s a pretty clear direction of movement towards the strongest isolation that our (currently quite flawed) hardware can afford.

tarsinge 7y ago
This comment made me remember my first Mac where when you launched an app it was given complete control over the hardware, with ASM calls to the Mac Toolbox. Remembering these times it makes me wonder why should there be only one direction, and that maybe there is an alternative to putting all our most sensitive data in every internet connected devices? In old times when you had a computer to do some hobby like games, photo editing, music, etc... the data was only related to that activity, and in the worst case of nuking the hard drive you lost only that work.

rgbrenner 7y ago

Other than the newer web tech initiatives like WebAssembly/JS sandboxing Yes, this is the lightest weight isolation that's somewhat secure for random code.. And considering that we regularly find exploits that escape that sandbox, I would never use it to run some random persons code on a server. Yes, we do that all the time in the browser, but that's a more limited environment where a single user is choosing what to run... whereas on a server, anyone who wants to attack the service can just upload whatever code they want. I know Cloudflare is doing it in Cloudflare Workers... and I think that's crazy. They're inspecting the code, and they added OS sandboxing... so that's a little better.. but trusting the JS sandbox in that environment is just nuts. Wouldn't surprise me if this ended up being another cloudbleed. If you want to run random code, the only safe option right now is to use a heavier form of isolation like a VM (and even that is not perfect). The performance loss is the necessary trade off to allow random people to run code (some of whom are deliberately attacking the service). This is the downside to the "cloud"... performance losses to allow random people to share servers.

takeda 7y ago

In a business environment the code you run is typically the code you wrote. You generally don't run unfamiliar code if you do, you are not being careful. All it takes is to have a container contain a backdoor that phones home, and essentially give someone access to inside of your network.