Contributed by tbert on from the taming-the-beast dept.
Theo de Raadt (deraadt@) has pulled back the curtain on his entry into the process sandboxing contest:
I have been working for a while on a subsystem to restrict programs into a "reduced feature operating model". Other people have made such systems in the past, but I have never been happy with them. I don't think I am alone.
Generally there are two models of operation. The first model requires a major rewrite of application software for effective use (ie. capsicum). The other model in common use lacks granularity, and allows or denies an operation throughout the entire lifetime of a process. As a result, they lack differentiation between program "initialization" versus "main servicing loop". systrace had the same problem. My observation is that programs need a large variety of calls during initialization, but few in their main loops. Some BPF-style approaches have showed up. So you need to write a program to observe your program, to keep things secure? That is insane. So I asked myself if I could invent a simple system call, which people would place directly into programs, between initialization and main-loop. Secondly, I wondered what kind of semantics such programs would need. Not just directly themselves, but for DNS and other macro operations. Anyways, enough explanation. A manual page follows. Then the kernel diff. Finally, a sample of 29 userland programs protected to various degrees by using it: cat pax ps dmesg ping ping6 dc diff finger from id kdump logger script sed signify uniq w wc whois arp authpf bgpd httpd ntpd relayd syslogd tcpdump traceroute Not all these are perfect, but it shows the trend. The changes are fairly simple. In the simplest non-network programs, network access is disabled. In simple network programs, file access goes away. That is the trend. Sometimes a program is easily modified, making it better, because the integration of tame hints at an improvement which will make it tighter under tame. sed is an example...
The full email, as stated, contains the man page and the diff to make this happen. For those of us wanting an easily-retrofitted way of sandboxing applications, this looks like a huge step forward.
(Comments are closed)
By Anonymous Coward (2601:186:4180:61:3dfd:e87d:219e:c2bc) on
I really like the concept behind tame(2).
If I understand it correctly... It allows the developer of the application to inform the operating system about the expected behavior of the program as the program moves along its execution timeline.
Comments
By Anonymous Coward (199.185.178.4) on
> I really like the concept behind tame(2).
>
> If I understand it correctly... It allows the developer of the application to inform the operating system about the expected behavior of the program as the program moves along its execution timeline.
>
>
Correct. In addition to that, if the process deviates from the expected behaviour it gets terminated.
By Anonymous Coward (38.99.63.178) on
> I really like the concept behind tame(2).
>
> If I understand it correctly... It allows the developer of the application to inform the operating system about the expected behavior of the program as the program moves along its execution timeline.
>
>
It's basically a much saner version of Linux capabilities, for all that implies, both good and bad.
I just hope this doesn't mean that OpenBSD will swear-off Capsicum. Linux just got a primitive for implementing Capsicum's pdfork and pdwait. It would be awesome if that became more portable beyond FreeBSD and Linux. But of course that stuff doesn't implement itself, so until a patch is rejected I only have myself to complain to.
Comments
By Amit Kulkarni (72.219.53.105) on
> > I really like the concept behind tame(2).
> >
> > If I understand it correctly... It allows the developer of the application to inform the operating system about the expected behavior of the program as the program moves along its execution timeline.
> >
> >
>
> It's basically a much saner version of Linux capabilities, for all that implies, both good and bad.
>
> I just hope this doesn't mean that OpenBSD will swear-off Capsicum. Linux just got a primitive for implementing Capsicum's pdfork and pdwait. It would be awesome if that became more portable beyond FreeBSD and Linux. But of course that stuff doesn't implement itself, so until a patch is rejected I only have myself to complain to.
>
>
Reading the diffs, I think tame is a continuing enhancement of privilege separation. Theo hints at it, right there in his email: initial start-up needs lots of permissions, afterwards not so much.
I am not a kernel hacker at all, but in the best possible case, I suspect that over time, privilege separation can be replaced by tame in the OpenBSD tree. Because by trial and error, the devs will come to understand what the individual daemons will want the right set of permissions to satisfy all the functionality, and specify for it at start-up. Start as root and then reduce functionality. This will enhance the readability of the kernel code.
Comments
By Anonymous Coward (38.99.63.178) on
> I am not a kernel hacker at all, but in the best possible case, I suspect that over time, privilege separation can be replaced by tame in the OpenBSD tree.
Tame could never do that. Privilege separation isn't merely concerned with the privilege of executing a certain system call. There are an endless number of application-specific, context-specific "privileges". For example, the private key used to authenticate TLS sessions. In OpenSMTPd this key is kept in a separate process. The privilege in this case is the privilege of the signing operation, much narrower than the privilege of having read access to the key. Tame could never protect that key in such a manner, nor could seccomp or Capsicum, for that matter.
With something like Capsicum, you don't need to block the kill call, or worry at what moment in the process lifetime the kill call might be invoked. Instead, you have permission to send a signal to a process _only_ by dint of having been _explicitly_ passed the process descriptor (not PID), which cannot be counterfeit. That's a much more powerful tool to augment the task of implementing fine-grained, application-specific privilege separation. But as Theo noted, such techniques in general, and Capsicum in particular, require significant refactoring of existing code, and careful design of new code.
Tame is much more practical. I would hope it wouldn't become a crutch to avoid implementing proper privilege separation. I certainly doubt that was Theo's intention.
Comments
By Amit Kulkarni (10.11.131.113) on
> > I am not a kernel hacker at all, but in the best possible case, I suspect that over time, privilege separation can be replaced by tame in the OpenBSD tree.
>
> Tame could never do that. Privilege separation isn't merely concerned with the privilege of executing a certain system call. There are an endless number of application-specific, context-specific "privileges". For example, the private key used to authenticate TLS sessions. In OpenSMTPd this key is kept in a separate process. The privilege in this case is the privilege of the signing operation, much narrower than the privilege of having read access to the key. Tame could never protect that key in such a manner, nor could seccomp or Capsicum, for that matter.
>
> With something like Capsicum, you don't need to block the kill call, or worry at what moment in the process lifetime the kill call might be invoked. Instead, you have permission to send a signal to a process _only_ by dint of having been _explicitly_ passed the process descriptor (not PID), which cannot be counterfeit. That's a much more powerful tool to augment the task of implementing fine-grained, application-specific privilege separation. But as Theo noted, such techniques in general, and Capsicum in particular, require significant refactoring of existing code, and careful design of new code.
>
> Tame is much more practical. I would hope it wouldn't become a crutch to avoid implementing proper privilege separation. I certainly doubt that was Theo's intention.
>
Thanks for clarifying!
By Noryungi (noryungi) on
I think that is the very first spam of this kind I see on this site.
Comments
By tbert (tbert) on
>
> I think that is the very first spam of this kind I see on this site.
>
>
fix't
By Fredrik Ludl (217.208.148.2) fredrik@ludl.se on
That is a big task, but maybe programs that can not have a predictable behavior shall not be considered as well written software.
So the system itself is a quality enhancer to software.
By Just Another OpenBSD User (87.126.197.32) on