OpenBSD Journal

tame(2) WIP

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)


Comments
  1. 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
    1. 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.

    2. 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
      1. 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
        1. By Anonymous Coward (38.99.63.178) on

          <snip>
          > 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
          1. By Amit Kulkarni (10.11.131.113) on

            > <snip>
            > > 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!

    3. By Noryungi (noryungi) on

      The comment above is spam.

      I think that is the very first spam of this kind I see on this site.

      Comments
      1. By tbert (tbert) on

        > The comment above is spam.
        >
        > I think that is the very first spam of this kind I see on this site.
        >
        >

        fix't

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

  2. By Just Another OpenBSD User (87.126.197.32) on

    Finally, at the right time wonderful solutions to real world problems are happening as usual in the OpenBSD space first.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]