3 ms·

Claiming 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

by gabcoh 7y ago

Claiming 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.

by gabcoh 7y ago

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.