Contributed by jose on from the security-by-sandboxing dept.
" 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)
By RC () on
By JTorin () on
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! :-)
By grey () on
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.
By Anonymous Coward () on