Re: systrace replacement

[Elad Efrat <elad%NetBSD.org@localhost>]

Hi,

Jonathan Schleifer wrote:

> systrace can be used for more than improving security: For example 
> limiting programs from doing stuff you don't want. Additionally, 
> everything that improves security is a good thing. There is no such 
> thing as perfect security, so every single bit that increases it is good.

True, but that is not the case. Systrace wasn't removed just because of
its design flaws, but due to other reasons as well: it was a pain to
maintain. I know because I used to maintain it. Reading Andrew's message
where he brought up its removal on tech-kern@, I can only assume that
it might have been a nightmare to make it work correctly with the new
threading model as well.

> If you fear that it would give false impressions of security to the 
> users, just don't have it in the default kernel config, like you had 
> before. Those who actually recompile their kernel to get systrace really 
> know what they're doing pretty.

I think the problem is that you're looking at things from a user's
perspective. One of the things that interest developers is the overhead 
maintaining the feature costs. There's no point in going into Systrace's 
internals here, but have a look at the way the userland program
translates syscall arguments: to me it's not that far from what kmem
grovelers are doing, and that is enough for me to object to having
Systrace in base, even if disabled by default.

I'm afraid that in order for us to provide a complete solution someone
will have to step up and address all of the outstanding issues. Until
then I believe it will be irresponsible to release a facility that is
known to be incomplete (at the very least), knowing that users tend to
use it as a security feature.

What I suggest to you is one of the following:

  - Describe, preferably in a new thread, what you're interested in
    doing & what you used Systrace for. I can almost guarantee that,
    in the long term, there will be a way of doing almost the same in
    NetBSD without Systrace.

  - Look into the Systrace implementation, specifically the parts
    outside kern/kern_systrace.c, and infer if and how it could be
    implemented as a module. For example, some process flags can be now
    stored using the "specificdata" interface. Some places might require
    the addition of new hooks to the system: if a hook makes sense, or
    falls under existing plans, it'll be a big step towards enabling
    Systrace to be implemented as a module.

  - Alternatively, look at the Linux Systrace implementation, the one
    using ptrace. IIRC, that is the only version Niels is ~maintaining,
    and might be an easier candidate for implementing using a module.

(btw: my opinion is that Systrace's major fallacy is its very concept:
restricting syscalls for an entire application is meaningless, and we're
looking at various ideas to export application state in order to enforce
flexible policies. That, however, is beyond the scope of this thread. :)

-e.