3 ms·
The person best positioned to lock down a program is the developer. Only they know when and how certain resources need to be accessed, and only they are positio
by wahern 7y ago
The person best positioned to lock down a program is the developer. Only they know when and how certain resources need to be accessed, and only they are positioned to refactor the source code to maximize the cost+benefit of stricter security policies.
But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized.
seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized.
This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints.
Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
- gabcoh 7y agoClaiming the developer is in the best position to lock down there own programs is obviously making the assumption that the developer can be trusted. It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself. I think it would be a great idea to integrate MAC more widely in package distribution systems.
- wahern 7y ago> It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself The problem is that it's much more difficult to write software that way, which is why few people do it. And it doesn't actually solve the problem of trust because it's exceptionally difficult to prove that those rules capture and constrain the most security-relevant aspects of the program, so you're back at square one in terms of trusting the developer and their skill. Your argument makes the most sense if security were simply a matter of enumerating filesystem and syscall access. But it's rarely that easy. Usually you need certain kinds of access at various stages of the programs, or the types of access required are a function of the inputs to the program--e.g. the files specified on the command-line or the configuration file. Handling these requirements in the most appropriate ways tends to devolve to a matter of writing ad hoc code in the context of the peculiarities of the program architecture. Declarative solutions divorced from the structure of the code don't work well. What's most important are the time, place, and manner of constraining particular privileges, as opposed to merely identifying all the privileges and switching from "insecure" to "secure" at a single point in the application.
- jancsika 7y ago> The person best positioned to lock down a program is the developer. The person best positioned to lock down a program is the maintainer of the platform on which all the other programs run. In fact the individual program developers should strive not only to ignore security altogether, but to develop a common set of tools that delivers arbitrary third-party code to the user's machine. This makes security theater unlikely as any given developer will only have expertise in their program proper and not in the security of their program plus the arbitrary third-party code. This also ensures maximum velocity of domain-appropriate development and focuses on ease of program installation-- the exact opposite of the problem being parodied in the article. That velocity will rapidly grow the platform. This neutralizes any efforts to thwart progress through ad hoc program lockdown as futile. At the same time it puts massive pressure on the platform itself to gracefully handle misbehaving programs lest systemic insecurity decrease installation velocity. Thus you get a system where arbitrary programs may be installed as quickly as possible with a security model that works even if 100% of the programs installed are malicious. The cost is that arbitrary user data is exfiltrated during most program installations and runtimes (but that is a minor implementation detail).