User: Password:
Subscribe / Log in / New account

Reactive vs. pro-active kernel security

Reactive vs. pro-active kernel security

Posted Jul 17, 2011 21:56 UTC (Sun) by gmaxwell (guest, #30048)
In reply to: Reactive vs. pro-active kernel security by dlang
Parent article: Reactive vs. pro-active kernel security

The applications where security is far more important than performance are no less real because other things exists. Consider the firewalls and jump-hosts that mediate administrative access to those 100,000 machines.

General purpose software doesn't mean "ignores requirements that are less important to me, but more important to others" — I'd say that something general purpose software seeks to find a blended solution that works acceptably for all cases, and offers options where the needs differ.

There is obviously a maintainability concern with options, but copy from/to checks can be made fairly self-contained— far more so than, e.g. the peppering of the codebase that SELinux requires. I'd think that this kind generic boundary hardening is exactly the kind of optional feature a general purpose system should have.

(Log in to post comments)

Reactive vs. pro-active kernel security

Posted Jul 18, 2011 8:03 UTC (Mon) by dlang (subscriber, #313) [Link]

actually, most of the protections we are talking about adding here are not really relevant to the firewall/jump box type of application. In those applications you severely limit what code you run on the box and test it extensively. these types of protections are mostly aimed at protecting the systems after you allow untrusted people to run arbitrary code on it.

there really are not that many situations where you do that.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds