OpenBSD Journal

Call for testing/battering: sysjail

Contributed by sean on from the new toys dept.

Kristaps Johnson writes:

sysjail, an OpenBSD and NetBSD "jail" implementation, has reached freeze before its 1.0 release. This release will feature full (limited by "what's possible") jail compatibility, plus some extra niceties:

http://sysjail.bsd.lv/

sysjail uses a combination of chroot(2) and systrace(1) to create jailed environments. We are in need of people to batter the system, both from a security and usability perspective, before the release. I anticipate at least a few weeks of heavy testing to flush out all border conditions one can use to panic sysjail or provide a means to break through the jail barrier - for example, by providing bogus syscall values, or running one's favourite fhroot-breaker. If you've a quick and dirty means to benchmark sysjail against common usage, please let us know as well!


Editors Note: There does not seem to be a port of this application yet so please make one if you use it. If you don't know how to make/submit a port then this would be a good one to cut your teeth on!

(Comments are closed)


  1. By Matthias Kilian (84.134.41.26) on

    > There does not seem to be a port of this application yet

    It's on the same site:

    http://sysjail.bsd.lv/dist/obsd-sysjail-0.4.5.tar.gz

    I didn't check it for correctnes, but a first hit builds and installs it, and the PLIST and WANTLIB seem to be o.k. at a first glance.

  2. By Anonymous Coward (66.111.212.52) on

    Awesome! I am also eagerly awaiting a see_other_uids sysctl, and a terror alert level in the motd.

    1. By djm@ (203.217.30.86) on

      orange

      1. By Nate (65.94.56.251) on

        > orange
        >

        I always felt partial to teal.

    2. By Thorsten Glaser (84.44.231.195) on http://mirbsd.de/

      > I am also eagerly awaiting a see_other_uids sysctl

      MirBSD actually has implemented two sysctls for hiding the
      environment of other users' processes or their process
      table entries entirely from other users, by idea of tedu@.

      Feel free to take the diffs from our cvsweb.

      (Let's paint it green?)

      1. By Anonymous Coward (66.11.66.41) on

        > > I am also eagerly awaiting a see_other_uids sysctl
        >
        > MirBSD actually has implemented two sysctls for hiding the
        > environment of other users' processes or their process
        > table entries entirely from other users, by idea of tedu@.
        >
        > Feel free to take the diffs from our cvsweb.

        Url?

        1. By Anonymous Coward (66.111.212.52) on

          > > > I am also eagerly awaiting a see_other_uids sysctl
          > >
          > > MirBSD actually has implemented two sysctls for hiding the
          > > environment of other users' processes or their process
          > > table entries entirely from other users, by idea of tedu@.
          > >
          > > Feel free to take the diffs from our cvsweb.
          >
          > Url?

          66.11.66.41 CA CANADA ONTARIO TORONTO HOMELAND SECURITY TECHNOLOGY

          Even more awesome. This gets better and better.

          I may be wrong, and I'd like to hear it if I am, but I don't think that's the kind of "security" the OpenBSD developers are into.

          This trusted computing business is rotten, really. And more annoyingly, it's not unix.

          1. By Anonymous Coward (66.11.66.41) on

            > 66.11.66.41 CA CANADA ONTARIO TORONTO HOMELAND SECURITY TECHNOLOGY
            >
            > Even more awesome. This gets better and better.

            What gets better and better? Are you on drugs?

            > I may be wrong, and I'd like to hear it if I am, but I don't think that's the kind of "security" the OpenBSD developers are into.
            >
            > This trusted computing business is rotten, really. And more annoyingly, it's not unix.

            Uh, it was a company that makes GPS software. It has nothing to do with trusting computing, security or whatever else you are thinking. Marketing dummies do stupid things, like name a company homeland security technology corporation when they just make GPS software. Perhaps instead of commenting ignorantly on my IP, you could either A) give me a url to the cvsweb he mentioned, or B) stfu.

          2. By Tommy (88.112.195.68) on













            > Even more awesome. This gets better and better.

            > I may be wrong, and I'd like to hear it if I am, but I don't think that's the kind of "security" the OpenBSD developers are into.

            Well.. Fact is that some people put logins and whatever to command lines, which ps &co will of course show. Is there some other way to protect these people from their stupidity?

            1. By Anonymous Coward (68.104.220.48) on


              > > I may be wrong, and I'd like to hear it if I am, but I don't think that's the kind of "security" the OpenBSD developers are into.
              >
              > Well.. Fact is that some people put logins and whatever to command lines, which ps &co will of course show. Is there some other way to protect these people from their stupidity?

              A lead pill. Who cares? You *can't* protect these people, or the systems they use, from their stupidity. I know firsthand they will find any and every possible hole to leak sensitive information out of. Users Cannot Be Educated Or Protected.

              1. By Anonymous Coward (66.11.66.41) on

                > A lead pill. Who cares? You *can't* protect these people, or the systems they use, from their stupidity. I know firsthand they will find any and every possible hole to leak sensitive information out of. Users Cannot Be Educated Or Protected.

                Those idiots pay us to host their sites. Considering how hard it is to explain to them not to use --password=s33kr1t on the command line, and have it actually sink in, yet how incredibly easy it is to just not show users each others processes, this seems like a very good solution. Telling them "haha, you got hacked cause you are dumb" isn't going to stop them from switching to a provider that does make some attempt at protecting them from themselves.

  3. By jirib (62.141.24.68) on

    LOL, i met some lithuanian openbsd users on openbsd channel on SILCNet, and then i found bsd.lv and sysjail. Then my friend ported sysjail on NetBSD... And now, it looks like sysjail is getting popular thanks this NetBSD port :)

    The world is so small :)

    jirib

    1. By Anonymous Coward (80.249.194.29) Artis on

      > LOL, i met some lithuanian openbsd users on openbsd channel on SILCNet [..]

      I believe you meant Latvian.

  4. By Sam Chill (68.53.205.186) samchill@gmail.com on

    In the mksysjail-dev script although the base_*() functions exist the profile cannot be used because in the section of code that chooses which profile to use it is not in the case statement. Seems like a minor oversight here is a patch:
    --- mksysjail-dev       Tue Aug 15 03:24:10 2006
    +++ mksysjail-dev-new   Tue Aug 15 03:27:07 2006
    @@ -174,6 +174,17 @@
    
     case "$profile" in
            none)   ;;
    +       base)   if [ `uname` = "NetBSD" ]
    +               then
    +                       base_netbsd
    +               elif [ `uname` = "OpenBSD" ]
    +               then
    +                       base_openbsd
    +               else
    +                       echo "$pn: unknown system `uname`" 1>&2
    +                       exit 1
    +               fi
    +               ;;
            ssh)    if [ `uname` = "NetBSD" ]
                    then
                            ssh_netbsd
    

    1. By Kristaps Johnson (62.85.46.110) on

      > In the mksysjail-dev script although the base_*() functions exist the profile cannot be used because in the section of code that chooses which profile to use it is not in the case statement...

      Fixed. Until I push a bug-fix release I'll have a patch posted off of the main page. Thank you!

    2. By Thorsten Glaser (213.196.246.74) on http://mirbsd.de/

      > In the mksysjail-dev script although the base_*() functions exist the profile cannot be used because in the section of code that chooses which profile to use it is not in the case statement. Seems like a minor oversight here is a patch:

      This one's better:

      base) base_$(uname) ;;

      Same for the others.

      1. By Miod Vallat (82.195.186.220) miod@ on

        > This one's better:
        >
        > base) base_$(uname) ;;
        >
        > Same for the others.

        Since when does uname return a lowercase string on *BSD systems?

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