OpenBSD Journal

Interesting Systrace Helpers

Contributed by jose on from the sandbox-security dept.

Systrace is one of those things that many people want to play with but sometimes don't know where to get started with. Projects like and Hairy Eyeball have done a good service in sharing repositories, but more examples of usage still needed. Running everything under systrace, for example, can require a help program, and ./configure scripts, a perfect place to use systrace, are hard to wrap with a policy. A recent thread on the mailing lists saw Dug Song share some of the tools used on to provide a total systrace environment. Definitely worth checking out for some systrace ideas.

(Comments are closed)

  1. By grey () on

    Did this story just take the words out of everyone's mouth or what?

    Dug's response is super intriguing. I would love to see monkey in its current state; or better yet - see some of its nifty improvements make it into OpenBSD defaults.

    The mention about this stuff being difficult to generalize echos much of the outlaying criticism of systrace though (i.e. it's kickass in principle, but hard for users to do properly in practice). Sadly, it sounds like Dug is pretty busy too so I don't imagine these changes getting lots of attention outside of monkey for the moment.

    I still didn't see any feedback regarding the propose mailing list, so maybe folks should chime in here as well? I think it'd be neat! And well, given the current state of affairs I guess rather than might be where it needs to end up (smiley face goes down).

    Very -very- _VERY_ cool though, I would love to see some more docs on the monkey no setu/gid, nosuid, etc. stuff, I know that there are even alternate options for stsh from people deadly readers should know (not sure if he wants attention on that just yet though).

  2. By Anonymous Coward () on

    i, for the first time, went and read onlamp's systrace articles ... and couldn't help but notice this:

    "This program can use the native connect(2) system call to talk to /dev/log and only /dev/log. That device hands the connections off elsewhere. If you didn't know that this was how the program logged, however, you'd be confused. Although the program is running in a changed root, /dev/log is opened before the chroot happens and chroot(2) does not revoke access to open files outside the chrooted area."

    this makes sense and all, but i recalled seeing a dev/log existing inside the named chroot. checked on it, and sure enough it's there. so i was just wondering ... there exists truth to onlamp's statement about accessing files outside of the chroot before the actual chroot call takes place, right? and therefore, is the article just wrong as to the operation of named with systrace under openbsd (accessing /var/named/dev/log and not /dev/log)? or are /dev/log and /var/named/dev/log essentially the same device .. thanks in advance

    1. By Anonymous Coward () on

      You're mostly right with your last assumption. In
      fact, the names in the Unix file system are just
      names for objects. Once you've manage to open them,
      or as in the case of AF_LOCAL sockets, to associate
      a socket with them, you're not using them anymore, but you're using a file descriptor number associated with the underlying object. You can fork() ochroot() and continue to use that file
      descriptor, or you can even send it through a AF_LOCAL socket and let another process use it.

Latest Articles


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