OpenBSD Journal

sysjail redivivus: emulation, cleanliness, and completion

Contributed by merdely on from the get-out-of-jail-free dept.

Kristaps Dzonsons writes:

sysjail, sysjail.bsd.lv, is a user-land virtualisation system first released early last year. The primary goal of sysjail is to provide the functionality of FreeBSD's jail(8) to OpenBSD (and NetBSD) users. Since November, the project has quieted, but in the past few months I've had opportunity to fix outstanding bugs. Since then, sysjail has been nearly completely re-written and needs testing to stabilise.

The list of changes is considerable, but the most visible is emulation. sysjail now supports emulated FreeBSD and Linux binaries, in effect allowing emulated binaries to have the same containment as native binaries. Overshadowing this visible change is cleanliness: the system has been re-written with an stricter eye toward clean, manageable code. Other notable improvements: prisons may be internally shut down with standard calls to shutdown(8) and the reboot(8) family, IPV6 is supported, multiple addresses are supported, sysjail(3) is droppable into any source tree, etc. Many, many bug-fixes join these new features.

In order to put sysjail into stable/maintenance mode, I need rigorous testing. Internally, we use sysjail with httpd and sshd, but this is minor use of a potentially powerful tool. The emulation isn't well-tested either: my understanding of the system calls arises from examination of the compat sources, which may not be correct. Some of Linux's semantics, especially socketcall(2), are particularly crufty.

sysjail has its lusty eyes on being stable and totally transparent in terms of security expectations. With this done, I can slap a "stable" sticker on the sources and put them in maintenance mode. A noble goal. If you've used sysjail before, or are interested in jail(8)-like facilities, please test and submit bugs! --bsd.lv

Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.

(Comments are closed)

Comments

  1. By Anonymous Coward (70.173.172.228) on

    I was wondering what exactly are the problems with jailing shm and sem? I ask because of pgsql's requirement.

    And yes, I know that freebsd's jail also EPERMs those functions, but I also know that there are kernel patches to allow jails to use shared memory and semaphores.

    Comments

    1. By Kristaps Dzonsons (62.84.12.40) kristaps.dzonsons@latnet.lv on

      > I was wondering what exactly are the problems with jailing shm and sem? I ask because of pgsql's requirement.
      >
      > And yes, I know that freebsd's jail also EPERMs those functions, but I also know that there are kernel patches to allow jails to use shared memory and semaphores.

      shm and sem (and msg, etc.) share a global namespace: there's no [easy-ish] way to partition requests from the host system (or from other jails). sysjail has a --allow-ipc flag (like security.jail.sysvipc_allowed sysctl on FreeBSD) that will allow you to execute sysvipc functions. I believe that https also needs --allow-ipc to run. -kk

  2. By Anonymous Coward (24.37.242.64) on

    Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.

    Isn't there another way with setting the home directory that allows sftp/scp to automatically chroot to their home directory?

    Comments

    1. By Johan Torin (jtorin) on

      > Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.
      >
      > Isn't there another way with setting the home directory that allows sftp/scp to automatically chroot to their home directory?

      Uhm, that's pretty much the holy grail of sftp usage...

      Being serious, it is sort of possible with some chroot addon hacks, none which are available or supported in the default install. Like (old) patches to sshd, or a special chroot shell which the sftp service is executed under. None leaves me satisfied...

      But doing this under sysjail, doesn't that mean that you need one jail for each user which you want to separate from the rest of the system?

    2. By Anonymous Coward (24.37.242.64) on

      > Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.
      >
      > Isn't there another way with setting the home directory that allows sftp/scp to automatically chroot to their home directory?

      I think what I was thinking, was something like setting /usr/libexec/sftp-server as the user's shell, which I believe restricts the user to sftp only - I don't recall of this is the specific way to do it and/or if the same applies to sshd?

      Someone please correct me if I'm wrong or clarify, I know I've read something like this somewhere and now I can't find where...

      Comments

      1. By Anonymous Coward (198.144.207.178) on

        > > Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.
        > >
        > > Isn't there another way with setting the home directory that allows sftp/scp to automatically chroot to their home directory?
        >
        > I think what I was thinking, was something like setting /usr/libexec/sftp-server as the user's shell, which I believe restricts the user to sftp only - I don't recall of this is the specific way to do it and/or if the same applies to sshd?
        >
        > Someone please correct me if I'm wrong or clarify, I know I've read something like this somewhere and now I can't find where...

        Does setting /usr/libexec/sftp-server as the user's shell prevent the user from using "cd" to move up the directory tree from their home directory?

        I've had success setting up chroot'd sftp w/ scponly.
        (http://sublimation.org/scponly)

        I was able to get it working on OpenBSD 3.9 w/ scponly 4.1 and more recently on 4.0 w/ scponly-4.6. scponly-4.6 is much more strict in its requirements for the setup of chroot directories. The fs must be mounted without "nodev" so that /dev/{null,zero,random,urandom} can be created, and the scponly source has a build_extras/arch directory with some handy OpenBSD-specific script fragments for recreating /etc/pwd.db within the chroot/chroots.

        I'm not endorsing scponly as the best solution; I tinkered with jailkit and rssh as well. scponly works well for my purposes.

    3. By Timothy (220.253.0.99) on

      > Editor's note: I briefly played with sysjail the other day to set up a jailed web/ssh server on -current. My end goal is to allow users I host websites for to scp/sftp their website files to their website directory without having access to the rest of the system. It was not difficult to set up and it works pretty well.
      >
      > Isn't there another way with setting the home directory that allows sftp/scp to automatically chroot to their home directory?

      I read this and thought "scponly".

  3. By vext01 (85.211.143.83) on

    Hi,

    Is anyone working on a port?

    Thanks

    Comments

    1. By Chl (82.240.25.187) on

      > Is anyone working on a port?

      It's already done : http://sysjail.bsd.lv/#download

    2. By Brynet (Brynet) on

      > Hi,
      >
      > Is anyone working on a port?
      >
      > Thanks

      Wow this was a dumb post, did you even consider "reading" the initial post? or visit the site? This is a project to implement FreeBSD's jail functionality on NetBSD and OpenBSD, If that is their primary target.. why would anyone have to port it?

      You my friend, are broken... rm -f vext01

      Comments

      1. By Anonymous Coward (24.37.242.64) on

        > > Hi,
        > >
        > > Is anyone working on a port?
        > >
        > > Thanks
        >
        > Wow this was a dumb post, did you even consider "reading" the initial post? or visit the site? This is a project to implement FreeBSD's jail functionality on NetBSD and OpenBSD, If that is their primary target.. why would anyone have to port it?
        >
        > You my friend, are broken... rm -f vext01

        Maybe he meant a port as in importing it native.

        Comments

        1. By Kristaps Dzonsons (62.84.12.40) kristaps.dzonsons@latnet.lv on

          > Maybe he meant a port as in importing it native.

          There's a port (as in ports(7)) on the sysjail site, but it isn't in the OpenBSD port system proper. I don't suggest having it in there until a few months of strenuous testing have passed.

          Comments

          1. By Amit Kulkarni (130.39.156.87) on http://forestlaw.blogspot.com

            > > Maybe he meant a port as in importing it native.
            >
            > There's a port (as in ports(7)) on the sysjail site, but it isn't in the OpenBSD port system proper. I don't suggest having it in there until a few months of strenuous testing have passed.
            >

            According to Slashdot http://it.slashdot.org/it/07/08/09/138224.shtml
            sysjail admins have recommended not to use it until the problems mentioned by Robert Watson are resolved. So will systrace also be revoked from OpenBSD tree, as NetBSD has disabled systrace by default according to the story?

  4. By Anonymous Coward (65.126.221.67) on

    Just ran across this posting from the USENIX WOOT conference. Any thoughts?

    Comments

    1. By Anonymous Coward (216.68.198.57) on

      WOOT7 and R. Watson's presentation: As always, hostile code is hostile. Life. Audit accordingly.
      As to SELinux and TrustedBSD, well, more complex, harder to verify and really know. Security system can also compromise overall system too.
      OpenBSD, simpler is better. If enforcement gets perfected, add it, and use accordingly.

      Peace all.

    2. By Kristaps Dzonsons (62.84.12.40) kristaps.dzonsons@latnet.lv on

      > Just ran across
      > this posting from the USENIX WOOT conference. Any thoughts?

      As the sysjail web-site indicates, the project has been suspended until the underlying issues are solved. There's no way [I can see] to solve these issues from sysjail, although the attack window may be narrowed with crude and heavy-handed measures. Pity. I'm more concerned with the more common ptrace and ktrace.

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