>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.
>Subsequent calls to tame() can reduce abilities further, but abilities can never be regained.
What you are suggesting is not compatible with tame.
What I'm suggesting is entirely compatible with tame. It doesn't change anything about the implementation, but prevents you from accidentally calling functions that would error out.
The only thing that my suggestion optionally changes is that using, eg, socket() would be a compile time error AND a runtime error, instead of only a runtime error, if you tell the system that you want it. Don't define the macros to disable functions that you are trying to make uncallable? Your code is 100% unaffected.
It might be interesting adding the ability to do something like:
which would cause a compile error by removing declarations for uncallable functions.