OpenBSD Journal

Announcement: Hairy Eyeball - systrace policy repository

Contributed by jose on from the security-by-sandboxing dept.

floh sends us this note:
" blafasel.org is proud to announce Hairy Eyeball a systrace policy repository with currently around 160 policy examples, including a whole systraced x11 by Dug Song and Niels Provos and other assorted goodies, come, enjoy and contribute :)"
Floh was the guy who wrote here that someone should do this, and so he did! It's a pretty good collection of policies, and if nothing else it shows you the kinds of things you can do with them. Looks like this project is taking shape, well done, Floh!

(Comments are closed)


Comments
  1. By RC () on

    I've got to wonder about the usefulness of some of them. A policy for ifconfig? Why would anyone want to systrace ifconfig?

  2. By JTorin () on

    Ehh, correct me if I'm wrong, but if an intruder (or local user) has privilegies enough to replace a system binary, can't a policy file also be replaced?

    But it ofcourse prevents attacks in which a binary (eg. a system service) is buffer overflowed (or whatever) and tricked in executing arbitrary code.

    Any chance of seeing systrace policies in the default install? (or is there already? Gotta take time to install 3.2, my CD is gettting older by the day! :-)

  3. By grey () on

    Yes, there are policies shipped in the default install, check /etc/systrace if you're running 3.2 (or most of -current for a while before that).

    Unfortunately, there are still only two that are four months old within CVS, and they don't really seem to be completely coordinated with what a stock install might be running.

    Fortunately, systrace makes it very easy to create policies and the syntax is very straight forward. Using the GUI to create policies from within X is almost mindlessly easy, and from a shell (make sure you use -t) one can use the -A option to create policies automatically even.

    Unfortunately, just because it's easy to create policies doesn't mean that the policies created will be effective. You see, you can write a policy which will still permit illegitimate behaviours (e.g. you must be especially wary if generating a policy automatically, while connected to a network where malicious activity might be occurring). You can also easily write a policy which doesn't permit legitimate actions as well - the repurcussions for that can be just as serious e.g. a system daemon or application ends up halting & dumping core because you didn't forsee a particular system call being used. Finally, systrace rules are not necessarily optimized for speed, rule ordering does have an effect. If you are running systrace on a demanding application (e.g. lots of users with lots of programs that are all systraced, a heavily loaded daemon, or just super crummy old hardware) it is possible that system performance will be impacted, especially if your rulesets aren't optimized. This latter concern is rarely cited, and one can imagine that it is generally going to be much less severe than a ruleset which permits too much or too little.

    Fortunately, systrace rulesets can be editted, optimized and checked by hand with little effort. The rules are plaintext, the syntax is clear, and there's even a method for commenting actions thanks to ye olde #.

    Unfortunately, few people seem to be taking advantage of the commenting ability to indicate whether the ruleset was automatically generated, done by hand, etc. Even the ones shipping with the default install and on the Hairy Eyeball have a dirth of such information. System Calls aren't exactly as straight forward to understand as a lot of things, at least not to me (I never claimed to be all that smart though) - if people actually made note of what they did in their policies, not only would it be a little easier to trust since you will have a better idea of what the ruleset is doing, but it will facilitate understanding & learning - which is especially good to encourage with new applications.

    The efforts of the Hairy Eyeball are laudable, but I don't think I'm alone when I voice an interest in commented, auditted policies as being added to the /etc/systrace directory to be available for the default install. Hopefully the new archive will continue to raise interest and eventually facilitate understanding so that we can get closer to that point.

  4. By Anonymous Coward () on

    If you encapsulate every binary in a systrace policy what would be the overhead on a relatively busy shell server with, say, 2000+ active accounts?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]