OpenBSD Journal

OnLamp: Creating Systrace Policies

Contributed by jose on from the small-intro dept.

Michael Lucas is back with another systrace article. His previous story covered some systarce basics and now his current article covers the actions of creating systrace policies. He also describes the use of the Hairy Eyeball project's repository as a good collection of examples.

Really briefly, when I create a systrace policy I tend to run the program under systrace -A with any arguments, use it a bit, and then edit the resulting policy file. I collect the filenames I can use to go from exact matches (the eq in the policy file) and change them to be globbing matches using the match action in the systrace file. For example, I have a line like



native-fsread: filename match "/usr/lib/libc.so.*" then permit


This allows me to match any version of my libc shared object, great for upgrading. I also do this with inet sockets, specifying all of my DNS servers, and I also roll up my directory matches. Then I run the program under systrace -a and watch how it fails (it logs to the syslog) and adjust my policy as needed. This iterative approach seems to work for me but I didn't think this was well explained in Lucas' article.

(Comments are closed)


Comments
  1. By Anonymous Coward () on

    This isn't meant to be a troll, but I'm sure it reads like one..:-)

    How can you guys trust systrace? It seems to me that until everyone starts using the same policies and policies are 'shipped' with the base install or maintained with ports, systrace loses much of its security potential. Simply put, systrace policies are way too easy to fuck up. Most every example I've seen uses really broad rules like permiting writing to ~, binding to any port and making a connection anywhere. This may work for stopping worms and canned exploits posted to some mailing list but I see it as being little better than homebrewed chroot hacks in the end.

    Comments
    1. By Anonymous Coward () on

      Some people may find that you're trolling indeed, but there is some truth in what you're saying.
      Systrace is a great tool, with a lot of potential. But it is only a great tool in the hands of a skilled sysadmin. The average sysadmin will probably f*** up his/her rules, and do more harm than good (by trusting an untrusted app: "it's systraced, so what can happen?")
      But systrace is still young. As it ages, more and better (for non-gurus ;)) documentation will become available. I'd write some myself, but as I'm just starting to look into systrace, it probably wouldn't be worth anything ;))

    2. By djm () on

      Try doing a mental s/systrace/pf/ on your post and see how it sounds. Any security tool can be configured in a too-permissive manner, but that doesn't make the tool bad.

      I'm sure that you will see more audited policies showing up in /etc/systrace in subsequent releases.

    3. By grey () on

      Systrace really hasn't shaped up in OpenBSD as I think was intially intended. After /etc/systrace was entered into the tree, the indication to me definitely seemed clear that it would slowly be populated with audited policies, that could easily be run from a default install (if not _relied_ on from a default install, which would be truly fantastic).

      Unfortunately, with Niels no longer being with the OpenBSD project, I think that the potential of systrace is not being realized within OpenBSD. Not only has there been drift between current systrace versions and -current OpenBSD, but I just don't think that we'll see a mass of audited policies shipping with the default install for a long while.

      This is definitely sad, and an unfortunate situation, for a tool which is really doing things in a simple & easy to configure way that has previously only been seen in an extremely small number of commercial tools (e.g. Okena's very spendy offerings). I was mentioning it to a couple of acquaintences last week (who are more FreeBSD & Linux oriented) and they were really excited at the idea and went to go research it for themselves. In the open source world, it's still unique for offering what it does with such simplicity - at least, that's true for a little while longer still I'm sure.

      However, while the potential of systrace is great, it is only relized only with a large set of working and audited policies. There's a spot for them in /etc/systrace - but have you seen anything added to it since Niels lost access? At least it's straightforward to create your own policies - which is really the greatest part about the systrace implementation (if you look at Okena's offerings, you need a completely separate product to generate your own policies, and that costs bank). However, without a trusted base from which to derive examples and experience from, the likelihood of having ineffective policies is high (whereas in say, Okena's example [again] - a group of trusted common policies is shipped as the key selling point of the product).

      Hairy Eyeball is a good resource to have, but at my last look (1.1 I guess) I haven't been too enthusiastic about the policies as they typically have absolutely no comments to them indicating whether they've been audited, optimized, what pitfalls may remain, not even who generated them sometimes. There's no telling whether it's something that our diligent Jose combed over, or whether it's Joe-SmackAss simply running systrace -A on some process and putting up what he ended up with in the end (and who knows if he might've been owned while the process was running). I don't want to detract from the project, since it _is_ needed - but without even commenting the policies, you really don't know what you're getting.

      Let's not forget that while systrace is great, some things are just inherently difficult to write a functional policy for - e.g. sshd. Naturally, if an exploit relies on legitimate system calls that aren't likely to be denied, that starts to chip away at the functionality of the tool. Some might try to be a devils advocate, and state that this gives some advantage to not having default policies in the base install, since it gives more information about what is permitted - but that's horseshit. The reality is, there are just some programs which aren't good matches for systrace - thankfully, these are rare - while the majority of programs can greatly benefit from its usage.

      Anyway, as I see it, systrace is definitely not living up to its potential, not so much because the policies are fucked up - but because, as you said yourself, not everyone is using the same policies shipped with the base install, so we don't have much to go off of as far as functionality or security track records, since you're not going to get bug reports off of two policies (and now that bind9 is default, the named policy is totally worthless no doubt).

      On a personal level, I think it's more saddening to see a rift with provos; but I don't really know the details - and I don't know whether things can (or will be) mended there. The lost potential of his continued contributions I think are far greater than the lost potential of systrace.

      Comments
      1. By Anonymous Coward () on

        Now that was a clever troll.

        Comments
        1. By grey () on

          It definitely was not intended to be a troll - I've been a long time user and supporter of the OpenBSD project, and a real fan of not only the technical advances it has made, but that it really has a philosophical different from many other projects out there. The developers I have met have also been outstanding, so don't get me wrong - if I express dissappointment regarding the state of systrace & provos, it's not to slight the project as a whole - it's just me expressing personal [and I did say 'personal' before] feelings.

      2. By djm () on

        Systrace is definitely living up to its potential on my systems. I have nearly every program that listens to the network or handles untrusted data running under systrace. This took me a couple of evenings work.

        Nobody knows what software is allowed to do better than the admin, so make your own policies and be happy.

    4. By Marten King () on

      I think this is about as dumbed down as something that controls execution at that level should go.

      Sure it would be nice for a set of default policies to ship, but as with anything this will be built up over time.

      While many systems have identical requirements for execution enviornment of specific programs, many others are different; at this point there is no shorcut to configuration, only deeper knowledge will suffice.

      The bottom line is that people who don't know or understand how to configure these policies should either learn or get help elsewhere.

      Personally I'm weary of this trend toward every clown setting up firewalls, mail servers, web servers and countless other security critical things completely from canned tutorials. I'm not saying that tutorials are bad either, just explaining a bad side effect.

      Being a good sysadmin requires skill and hard work. Having some super easy configuration for every possible component leads to a Microsoft-ish way of doing things, and is ultimately detrimental.

Latest Articles

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