
Using tame() in userland - protomyth
http://marc.info/?l=openbsd-tech&m=144070638327053&w=2
======
flgr
For those wondering what this is about: [http://marc.info/?l=openbsd-
tech&m=143725996614627&w=2](http://marc.info/?l=openbsd-
tech&m=143725996614627&w=2)

    
    
         The current process is forced into a restricted-service operating mode.
         A few subsets are available, roughly described as computation, memory
         management, read-write operations on file descriptors, opening of files,
         networking.  In general, these modes were selected by studying the
         operation of many programs using libc and other such interfaces.
    

Sounds pretty interesting.

~~~
OJFord
It seems really interesting, and a good idea.

What I don't understand though is the incentive, what motivates a program-
author to "[b]e careful writing such diffs; you need to fully understand the
program and handle all cases"?

~~~
jerf
In addition to the other fine replies, I'd observe this falls in the set of
things that are pretty easy to use if you start with them from scratch, but
are hard to retrofit on to existing code. To retrofit requires the mentioned
extensive knowledge of the target codebase... to use it on a new codebase just
requires you to do any sort of testing at all, note the new thing you wrote is
a security violation, then think about what that means and what you should do
about it at precisely the point in time you have all the relevant context
loaded in your brain.

At the moment the motivation is to armor existing code, but the general case
for tame across its entire lifespan is to be used in new code. In that case
the motivation is the same as any other security practice... not to see your
code be fingered as the vulnerability that let $BAD_THING happen.

~~~
umitsu
i think the recent hiding of unused libc symbols is related to the tame
effort.

~~~
tedunangst
No, entirely unrelated.

------
piger

      --- bin/echo/echo.c	14 Dec 2014 16:55:59 -0000	1.8
      +++ bin/echo/echo.c	26 Aug 2015 22:07:37 -0000
      @@ -30,6 +30,8 @@
        * SUCH DAMAGE.
        */
       
      +#include <sys/tame.h>
    

MUCH TAME!

------
peterwwillis
Hooray simple security hacks!

....and booooo simple security hacks.

In the previous thread, someone says _" I really like this solution. Far
better than pissing around with SELinux configuration and it's well
contained."_ Which is a little bit like saying, "I really like these airbags.
Way easier than using a seatbelt."

~~~
vezzy-fnord
It's actually a consistent mechanism for doing privilege dropping on a
whitelist level. The same cannot be said for an API like POSIX capabilities.

~~~
JdeBP
My initial reaction was that it didn't match my use. It doesn't seem possible
to do what my use would require, which would be things like dropping specific
identified privileges without affecting what other privileges the process
might currently have. This would need some way for reading the process's
current restrictions. The current API is write-only.

Moreover none of the privilege sets seemed to allow the possibility of chain
loading once privileges had been dropped, as none of them allow execve().
OpenBSD tame() is, as its blurb states, not designed with the model in mind of
programs where initialization parts (consider UCSPI servers, for example) are
in a separate executable that then chain loads through common privilege
dropping tools to the main part of the program.

It's not as easy to wrap tame() into some shell-level composable tool as it is
to wrap jail() into the jexec tool.

------
malkia
Would that work for tools like busybox? I guess it'll work as long as it's set
only once, but doesn't busybox has a mode where one command can call
internally another, and then it'll have to set tame() again, or maybe even
restore it?

~~~
CUViper
The docs say you'll get EPERM for trying to increase permissions, so I'd guess
there's no way to restore it.

