Domesticating applications, OpenBSD style

Posted Jul 21, 2015 23:23 UTC (Tue) by felixfix (subscriber, #242)
In reply to: Domesticating applications, OpenBSD style by dlang
Parent article: Domesticating applications, OpenBSD style

The vast majority of programs are not those kind of long-lived programs.

to post comments

Domesticating applications, OpenBSD style

Posted Jul 21, 2015 23:25 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

but the ones that are "this kind of long-lived programs" are the ones that you need to worry about the most because they are the ones that provide services to other programs (or other systems).

Domesticating applications, OpenBSD style

Posted Jul 22, 2015 1:10 UTC (Wed) by wahern (subscriber, #37304) [Link] (2 responses)

Until Shellshock happened, and people realized that a huge pool of potential exploits was lying under their noses the entire time in the form of the various command-line utilities. Just because defenders are focused on one area doesn't mean attackers aren't exploiting other areas. Are you going to to audit utilities like awk, sed, and grep for exploits related to environment variables, data structures buffer bugs, etc? Executing utilities this way is poor form these days, but unfortunately still quite common. Occasionally it still makes sense, such as when executing a configurable command to perform some check or make some policy decision; and in that case you never know how it's implemented.

Regarding the usefulness in complex programs, note that OpenBSD developers tend to implement their services using a rigorous privilege separation and message passing pattern. In particular, they often use subprocesses to implement very specific operations which require no or minimal access to the environment. For example, the TLS private key in OpenSMTPd is only kept in memory in a subprocess, so that bugs in the protocol stack cannot expose the private key. (Yes, they hacked and extended the signature routines in OpenSSL to do this.) After startup, the subprocess doesn't need any privileges except the ability to read and write to the IPC messaging socket and perhaps the /dev/crypto driver. The point of tame(2) is to make it a one-liner to drop privileges after an application-specific initialization procedure.

The utility is limited from the perspective of trying to lock down every conceivable application out there. But that's not the goal. The goal is much more specific, oriented toward the needs of OpenBSD services and OpenBSD developers.

I'm not sold on the concept. But it's hardly useless.

Domesticating applications, OpenBSD style

Posted Jul 22, 2015 22:02 UTC (Wed) by dvdeug (subscriber, #10998) [Link] (1 responses)

This can't do much for awk and can't do anything for GNU awk. Awk is an interpreter, and doesn't know what the program is going to do, and GNU awk is an interpreter with the ability to load arbitrary shared libraries at runtime.

I'm less then impressed with cat. I acknowledge it's an easy example, but it implies that cat isn't trustable. If in 2015 C programmers can't write a cat without buffer overflows, maybe they should stop writing cat in C. A correct cat is better then one that is limited in what it can do when it fails. Other programs are more complex, but a program that fails with an exception on a buffer overflow is better then one that can corrupt local files but not reach the network on a buffer overflow.

Domesticating applications, OpenBSD style

Posted Jul 26, 2015 8:53 UTC (Sun) by mti (subscriber, #5390) [Link]

I see at least two ways of making this useful for awk. One is to expose the tame() call to awk scripts to be able to write safer awk scripts. The other is to add a command line option to awk to set the flags awk should use in its call to tame(). Most awk scripts I have seen doesn't need more than simple file I/O.

As for cat it is not quite as simple as you think it is. For one thing it includes calls to several multi-byte character string functions.