Contributed by jose on from the small-intro dept.
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 permitThis 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)
By Anonymous Coward () on
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
By Anonymous Coward () on
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 ;))
By djm () on
I'm sure that you will see more audited policies showing up in /etc/systrace in subsequent releases.
By grey () on
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
By Anonymous Coward () on
Comments
By grey () on
By djm () on
Nobody knows what software is allowed to do better than the admin, so make your own policies and be happy.
By Marten King () on
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.