OpenBSD Journal

OpenBSD/Xen boots multiuser

Contributed by marco on from the dept.

Eduardo Alvarenga pointed us to an interesting blog from Anil on Xen.

(Comments are closed)

Comments

  1. By anonymous (70.197.118.201) on

    Excellent news :-)

  2. By Anonymous Coward (85.178.97.121) on

    wich XEN gets hacke don?
    Xen3 or Xen2?

    If the latest netbsd was choosed as source then XEN3 should be the Version we`re all dreaming about, or?
    http://www.netbsd.org/Ports/xen/

    Comments

    1. By Brad (72.60.177.181) brad at comstyle dot com on

      > wich XEN gets hacke don?
      > Xen3 or Xen2?
      >
      > If the latest netbsd was choosed as source then XEN3 should be the Version we`re all dreaming about, or?
      > http://www.netbsd.org/Ports/xen/

      If you had even botherd to read the SoC project you would have your answer.

  3. By Anonymous Coward (89.210.244.162) on

    combining xen & openbsd should offer amazing security capabilities.
    setup that comes to mind:
    each daemon inside its own domU vm running chrooted & systraced (as far as it can be done at least).

    Comments

    1. By Anonymous Coward (24.82.182.29) on

      more layers does not necessarily imply more security.

      Comments

      1. By Anonymous Coward (24.34.57.27) on

        > more layers does not necessarily imply more security.

        What sort of trash is this? Segregation of services means if one is violated, the intruder doesn't gain access to the system of any of the others. It's the reason we have jail in the first place.

        Comments

        1. By Anonymous Coward (24.46.21.20) on

          > > more layers does not necessarily imply more security.
          >
          > What sort of trash is this? Segregation of services means if one is violated, the intruder doesn't gain access to the system of any of the others. It's the reason we have jail in the first place.

          Aside from this it allows for testing of new services on something other than a production box, so that you can 'go live' with something, yet easily segregate it should it fail (or break). It helps with security & stability....

        2. By Anonymous Coward (70.25.115.53) on

          > > more layers does not necessarily imply more security.
          >
          > What sort of trash is this? Segregation of services means if one is violated, the intruder doesn't gain access to the system of any of the others. It's the reason we have jail in the first place.

          Using systrace and chroot and jail and such is pointless if each service is in its own VM. Its just adding layers of complexity for no reason.

          Comments

          1. By Anonymous Coward (24.46.21.20) on

            > > > more layers does not necessarily imply more security.
            > >
            > > What sort of trash is this? Segregation of services means if one is violated, the intruder doesn't gain access to the system of any of the others. It's the reason we have jail in the first place.
            >
            > Using systrace and chroot and jail and such is pointless if each service is in its own VM. Its just adding layers of complexity for no reason.

            Not really. Look at it this way:
            You've a production OpenBSD server that runs Xen, and several Development /Testing servers running as domU's. If you've some nasty app that breaks, you can still check on the state of the system because of a decent systrace policy. Alternatively, if some process is jailed on a regular box, the same argument applies if you want to jail it on a domU: to prevent access to anything you'd rather not have in case of an exploit or other nastiness. The domU's are nice because you've no need of extra servers or worry for one server breaking and taking everything with it. The extra 'layer' isn't really such a bother either. I actually look forward to being able to use OpenBSD/Xen (instead of NetBSD like I currently do). Nice for research & production.
            Cheers

            Comments

            1. By Anonymous Coward (151.136.100.2) on

              of course according to you all world is i386.
              xen is still one archetecture only it will not help security
              on any other architecture but i386... yeah maybe amd64.

              Comments

              1. By Anil Madhavapeddy (82.133.102.210) anil@recoil.org on http://anil.recoil.org

                > of course according to you all world is i386.
                > xen is still one archetecture only it will not help security
                > on any other architecture but i386... yeah maybe amd64.

                Huh? A lot of misguided comments here, especially this one. There are several good reasons why Xen (specifically the split device-driver model) helps with security. I'm really busy with some hacking at the moment, but will write up a few facts about OpenBSD/xen later on at the same feed linked above (http://anil.recoil.org/blog/articles/category/xen).

                There are Xen/{amd64,ppc64,itanium} ports you know... there is no such thing as an "i386-only" OpenBSD developer :)

                -anil

            2. By Anonymous Coward (66.11.66.41) on

              > Not really. Look at it this way:
              > You've a production OpenBSD server that runs Xen, and several Development /Testing servers running as domU's. If you've some nasty app that breaks, you can still check on the state of the system because of a decent systrace policy.

              You can anyways without systrace.

              > Alternatively, if some process is jailed on a regular box, the same argument applies if you want to jail it on a domU: to prevent access to anything you'd rather not have in case of an exploit or other nastiness.

              Which part of "running in its own domU instance" is hard to understand? Each service has its own OS, there is nothing else for it to access, so jails and systrace is just extra stuff for no reason. Sure they have their use when multiple services are running in the same OS. That is not what is being discussed though. Get with the program.

              > I actually look forward to being able to use OpenBSD/Xen (instead of NetBSD like I currently do). Nice for research & production.

              So do those of us who know how to read. Nobody said Xen was bad, I said there is no need to use jails and systrace if you are running each service in its own Xen'd OS instance.

        3. By Joachim Schipper (82.157.194.81) on

          > > more layers does not necessarily imply more security.
          >
          > What sort of trash is this? Segregation of services means if one is violated, the intruder doesn't gain access to the system of any of the others. It's the reason we have jail in the first place.

          Yes, but this is only worthwhile if the jail is strong.

          Now, I don't know too much about Xen, but it's security record doesn't seem too bad as of yet. However, note that the traditional chroot() and systrace both reduce priviliges (usually; systrace *can* add priviliges). Thus, even if the jail is broken, you are not worse off than you would be without the extra layer.

          However, I'm not so sure about Xen. Certainly, the 'child' system must be compromised before anything can happen; but if there is a sufficiently large bug in Xen, and it can be exploited, one could jump all the way to the host system.

          Now, from a quick look, the Xen people appear quite clueful and apparently they have picked an architecture designed to minimise this risk. However, arbitrarily adding layers is not necessarily a good thing.

          On the more practical side of things, updating one system is easier than updating twenty.

          Now, I am not saying Xen is necessarily bad for security, or even that it might not generally be a good idea; but is complex enough, as a technology, that implementing it also adds some problems.

          Joachim

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