3 ms·

https://yarchive.net/comp/sandboxes.html https://yarchive.net/comp/sandboxes.html is an interesting example of Clarke's first law: " When a distinguished but el

https://yarchive.net/comp/sandboxes.html https://yarchive.net/comp/sandboxes.html is an interesting example of Clarke's first law: " When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong." The post, from Theodore Ts'o, argues that software sandboxing is, if not quite impossible, rather difficult: in his post, he argues that either the user or the sandboxed program has to configure a sandbox. The user won't know what to do, and the executable can't be trusted. The author neglects to consider a third possibility: the OS dictates the shape of all sandboxes and software conforms to fit. This is model we use in Android and iOS and increasingly even on conventional Linux (via snap and flatpak). Sandboxing is not only possible, but essential. Anyway, being wrong is no great crime. Everyone's wrong sometimes. The author went on to do great things with the Linux kernel. It's interesting to think of why smart people are wrong and to be skeptical of claims of impossibly.

Veserv 2y ago
It is not even that. All you need is the program to present a “understandable” manifest of its requirements and you can choose to accept or deny. Standardized sandboxs just facilitate ease of use and analysis, and enable application developers to target easy-to-understand security models. The problem with the post is that it assumes that the most important thing is making sure that all non-malicious programs run no matter how convoluted. It is the same thought process that makes people say nonsense like formal methods are impossible due to the halting problem. No, we can just reject unless you make it easy to analyze; halting problem averted.
- quotemstr 2y ago
  > It is not even that. All you need is the program to present a “understandable” manifest of its requirements and you can choose to accept or deny. Sure. And if these understandable manifests contain requests only from a predefined set that the system provides, we call these requests "permissions" in the iOS and Android sense. You don't get to request arbitrary things and ask the user to approve them. > The problem with the post is that it assumes that the most important thing is making sure that all non-malicious programs run no matter how convoluted Agreed. > No, we can just reject unless you make it easy to analyze; halting problem averted Yes, and it's this idea that makes minimalism essential in OS design. The narrower your contract, the more flexibility you have to change your implementation.
  - Veserv 2y ago
    Agreed. It was unclear from your original post if you were talking about coarse-grained sandboxs or more fine-grained systems. To clarify, a system that defines coarse classes of sandboxs could declare a class of sandbox for non-networked applications, a sandbox for games, a sandbox for applications with storage exclusively for configuration data, etc. Such a system is different in many respects from a system that defines relatively fine-grained composable requirements. Obviously, a fine-grained system could be composed to present a model at the coarse abstraction level, but the way you target a application differs based on what abstraction level you are targeting.
- immibis 2y ago
  Okay, then every program demands every permission. Your choice is to let the program use your camera or to not use the program. And some of these programs are probably very important for your livelihood, so we know what the outcome is going to be.
  - aeonik 2y ago
    I miss rooting my Android phone and spoofing access to the GPS or camera. I could pipe arbitrary bits to any application.
contingencies 2y ago
You can also profile the execution in a less trusted environment and use that to define the sandbox, like running Linux in NSA SEL learning mode. This allows a black box approach to systems monitoring which works well with secret, forgotten and proprietary systems and is good engineering practice for most systems anyway, whether hardware or software, as anomalies are often highly detectable.
- immibis 2y ago
  You can, but it doesn't work very well.
  - contingencies 2y ago
    Au contraire, it works very well in many domains of engineering (source: I use it all the time). I suspect you may be viewing the general approach through a narrow lens of one particularly demanding requirement (targeting "absolute security"), and comparing an existing approach with input costs that are often considered high or unrealistic (eg. specialist manual configuration). For example, if the target system is a software system, and the baseline is "no extra security", then running a full codebase coverage test battery across software with network activity monitoring, computation monitoring, memory monitoring, kernel API monitoring, filesystem monitoring, etc. is going to get you a really strong profile of what isn't used to reduce the effective attack surface. This can be done at multiple levels: system API restriction, filesystem restriction, resource restriction, firewalling, VLAN segmentation, intrusion detection system ruleset generation, etc. This is awesome versus manual config, as it is free, precise, adapts with upgrades once plugged in to CI/CD, and requires zero specialist humans... who often function to perform similar processes in an iterative fashion on a best-effort basis.

Veserv 2y ago

It is not even that. All you need is the program to present a “understandable” manifest of its requirements and you can choose to accept or deny. Standardized sandboxs just facilitate ease of use and analysis, and enable application developers to target easy-to-understand security models. The problem with the post is that it assumes that the most important thing is making sure that all non-malicious programs run no matter how convoluted. It is the same thought process that makes people say nonsense like formal methods are impossible due to the halting problem. No, we can just reject unless you make it easy to analyze; halting problem averted.

quotemstr 2y ago
> It is not even that. All you need is the program to present a “understandable” manifest of its requirements and you can choose to accept or deny. Sure. And if these understandable manifests contain requests only from a predefined set that the system provides, we call these requests "permissions" in the iOS and Android sense. You don't get to request arbitrary things and ask the user to approve them. > The problem with the post is that it assumes that the most important thing is making sure that all non-malicious programs run no matter how convoluted Agreed. > No, we can just reject unless you make it easy to analyze; halting problem averted Yes, and it's this idea that makes minimalism essential in OS design. The narrower your contract, the more flexibility you have to change your implementation.
- Veserv 2y ago
  Agreed. It was unclear from your original post if you were talking about coarse-grained sandboxs or more fine-grained systems. To clarify, a system that defines coarse classes of sandboxs could declare a class of sandbox for non-networked applications, a sandbox for games, a sandbox for applications with storage exclusively for configuration data, etc. Such a system is different in many respects from a system that defines relatively fine-grained composable requirements. Obviously, a fine-grained system could be composed to present a model at the coarse abstraction level, but the way you target a application differs based on what abstraction level you are targeting.
immibis 2y ago
Okay, then every program demands every permission. Your choice is to let the program use your camera or to not use the program. And some of these programs are probably very important for your livelihood, so we know what the outcome is going to be.
- aeonik 2y ago
  I miss rooting my Android phone and spoofing access to the GPS or camera. I could pipe arbitrary bits to any application.

contingencies 2y ago

You can also profile the execution in a less trusted environment and use that to define the sandbox, like running Linux in NSA SEL learning mode. This allows a black box approach to systems monitoring which works well with secret, forgotten and proprietary systems and is good engineering practice for most systems anyway, whether hardware or software, as anomalies are often highly detectable.

immibis 2y ago
You can, but it doesn't work very well.
- contingencies 2y ago
  Au contraire, it works very well in many domains of engineering (source: I use it all the time). I suspect you may be viewing the general approach through a narrow lens of one particularly demanding requirement (targeting "absolute security"), and comparing an existing approach with input costs that are often considered high or unrealistic (eg. specialist manual configuration). For example, if the target system is a software system, and the baseline is "no extra security", then running a full codebase coverage test battery across software with network activity monitoring, computation monitoring, memory monitoring, kernel API monitoring, filesystem monitoring, etc. is going to get you a really strong profile of what isn't used to reduce the effective attack surface. This can be done at multiple levels: system API restriction, filesystem restriction, resource restriction, firewalling, VLAN segmentation, intrusion detection system ruleset generation, etc. This is awesome versus manual config, as it is free, precise, adapts with upgrades once plugged in to CI/CD, and requires zero specialist humans... who often function to perform similar processes in an iterative fashion on a best-effort basis.