Using tame() in userland

http://marc.info/?l=openbsd-tech&m=144070638327053&w=2

by protomyth • 11 years ago

66 23 11 years ago

flgr• 11 years ago

For those wondering what this is about: 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• 11 years ago

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"?

bkeroack• 11 years ago

Presumably the program author (or OpenBSD ports maintainer) knows more about what permissions the program requires than the end-user sysadmin who would be configuring SELinux, AppArmor, etc.

brohee• 11 years ago

If there is somehow an exploitable vulnerability in the program, if exploited after the tame call the attacker only takes control of a restricted process, which hopefully mitigate or blocks the attack.

This a very smart application of the least privilege principle. The idea is that most programs don't need most syscalls after they complete their initialization, and thus dropping the privilege to use them is both cheap, safe and effective.

jerf• 11 years ago

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.

ecoffey• 11 years ago

Reading that man page sounds like the way to go about it is start with `tame(0)` as early as possible in the program and see how it fails. then iterate pushing `tame()` down and expanding the flags until the program functions.

ori_b3• 11 years ago

I'd imagine that it would be easy to miss a disallowed system call down one rarely used path in a larger program.

It might be interesting adding the ability to do something like:

    #define TAME_ENABLE
    #define TAME_ENABLE_FOO
    #define TAME_ENABLE_BAR
    #include <foo.h>

which would cause a compile error by removing declarations for uncallable functions.

bodyfour• 11 years ago

There some good previous HN threads discussing the earlier announcements such as https://news.ycombinator.com/item?id=9928221

peterwwillis• 11 years ago

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

pakled_engineer• 11 years ago

Only if the seat belt consists of thousands of strands you have to piece together, and if you screw up one strand your entire belt could fail. I've hung myself with SELinix a few times as complexity grows even just trying to set a policy(s) for an Android phone with half the features removed. Even the NSA guys on the SEAndroid mailing list have been stumped sometimes with complexity errors.

vezzy-fnord• 11 years ago

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• 11 years ago

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.

tyho• 11 years ago

Apart from SELinux is not available in OpenBSD, so you can't use both in tandem.

piger• 11 years ago

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

malkia• 11 years ago

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• 11 years ago

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

Using tame() in userland

Related Stories