OpenBSD Journal

MicroBSD 0.5 released

Contributed by jose on from the uBSD dept.

Dimmy writes :
"Some Australian/American/Bulgarian fellows made a tiny BSD distro, which is a mix between FreeBSD and OpenBSD, has some ports and other stuff -a. Full install is about 200 megs, the install iso is 64 MB.It can run on low end x86 boxes. The thing is located at www.microbsd.org and there are 2 mirrors: one in the US: http://microbsd.wiretapped.us/ and one in Australia. IMO, looking at the docs, it resembles some stripped version of OBSD + some of the robustness of FBSD. Hats off to them, pvalchev@,tacho@ and the others "
Last time we posted on this, we had a batch of interesting comments. So, before posting, I asked what was significant about this: Some docs are missing, still, but the project is trying to move along. Project news is also available.

(Comments are closed)


Comments
  1. By click46 () click46 at operamail dot com on mailto:click46 at operamail dot com

    ...when does OpenBSD or FreeBSD plan to use port ACL's like MicroBSD? This root below 1024 shit is getting old...

    Comments
    1. By Anonymous Coward () on

      Agreed - I would prefer to have that patch before the tcp speedup, or even the recent non-exec stack work.

      I imagine that it might break a -lot- more things though; but hopefully it will be incorporated into 3.2 (haven't seen any commit messages though).

    2. By niekze () on

      damned straight

    3. By plankalkuel () on

      ACL will be in FreeBSD 5.0.

      Comments
      1. By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net

        userland ACL's I'm talking port binding ACL's. I've read NOTHING that says they are even THINKING about this. go cvsup -CURRENT and you'll see nothing has changed. I guess that just means no one on the project is interested. I keep finding all these things I really want to do in C but so far none have gotten me off my ass.

        Comments
        1. By Anonymous Coward () on

          TrustedBSD is working on this with their Fine-Grained Capabilities and Mandatory Access Control.

    4. By Peter Hessler () spambox@theapt.org on http://www.theapt.org/openbsd/

      Last I checked, that was one of the features of systrace, to allow any program to do certian things, based on a config file.

    5. By Chris Humphries () chumphries@drauku.net on http://drauku.net

      ACL's in OpenBSD will never happen. for a few reasons:

      1) complexity. more complex the code, more prone it is to bugs and harder to manage. KISS

      2) ACL's are "hard" to implement correctly if you are new to using them, so it wont help much if you
      do not know exactly what you are doing.

      3) seems there is a remove-suid-from-everything movement, specially some of the work that has happened recently in openbsd... privsep ssh, no suid sendmail, etc. This seems a more simple alternative solution to the problem, and alot easier for programmers and administrators to manage.

      4) openbsd now has systrace, that can protect main things you may need acl's for, such as around the apache remote exploit, where they could get a shell... with systrace properly configured, they would never be able to get a shell.

      ---

      also you have to think about is ACL's truely needed? yes they may be cool, but other than that, why would you warrent using them on a system?

      many times, your problems may be solved by alternate (usually existing) solutions, than more complex and "cooler" ones.

      just my 3 cents,
      Chris.

      ps -> note: http://www.lucq.org has patches for openbsd that provides acl and auditing, if interested.

      Comments
      1. By zil0g () on

        "Using sysctl(8) you can allow given UIDs to bind to a limited set of privileged ports. E.g., you can allow UID 67 (www) to bind to port 80 (and only port 80), thus removing the need for httpd to start as root."

        exactly how is this complex and easy to get wrong?
        if you ask me it's PERFECT and I'd really love to see it comitted.
        (is any developers reading? why isn't this the easiest solution, instead of alllll those workarounds here, there and everywhere)
        $0.4

        Comments
        1. By mechiel () on

          I'm not an expert on security or secure coding, so I could be very wrong.

          It seems to me that letting daemons bind to a priviliged port doesn't necessarily improve security. For example you couldn't chroot to an empty directory because only root can successfully call chroot(2). You also can't fork an unprivilidged child for handling communication since you can't setuid to that unpriviliged user.

          So, when one bug is found, an attacker could take over the port/daemon, right?

          As I said, I don't really have any experience writing secure daemons (yet), so if these issues aren't really issues, please correct me.

          Comments
          1. By Mattt () on

            "Cannot chroot", True. But why not allow all users to be able to revoke already given permissions, like access to bits of the file system. However that said, someelse must have had this idea and rejected it, so why? (*)

            "Cannot fork", um not sure. You can do priv sep a la qmail, with multiple daemons as different users. Cannot remeber how they all get started though, but no binaries are setuid in qmail on my system.

            "one bug gets whole daemon", well yes, but without putting the (large) effort into priv sep for every daemon this is an issue anyway. At least with ACLs you can remove the chroot requirement, so the comprosed user doesn't matter as much.

            I also am human, so please correct mistakes. Especially (*).

            Comments
            1. By Matt () on

              D'oh, I cannot type, but here is an important correction...


              "one bug gets whole daemon", well yes, but without putting the (large) effort into priv sep for every daemon this is an issue anyway. At least with ACLs you can remove the *** setuid root *** requirement, so the comprosed user doesn't matter as much.

          2. By RC () on

            letting daemons bind to a priviliged port doesn't necessarily improve security. For example you couldn't chroot to an empty
            directory

            There have been many instances where a program written to drop privlidges, did not, or was exploitable previous to droping privlidges... Chroot or not, if you don't give programs ROOT in the first place, they can't be exploited to give ROOT access, just access to that account. When someone gets ROOT, you basically have to scrap everything because they've trojaned all the tools, logs, and all the files as well. When someone compromises an account, you can have all those files set to read-only, and possibly even automatically kill any processes that shouldn't be running as that user.

            Rather than rant any further, check out another discussion on the subject: http://sourceforge.net/tracker/index.php?func=detail&aid=567313&group_id=11118&atid=311118

            when one bug is found, an attacker could take over the port/daemon,
            right?


            Automatically kill any processes that shouldn't be running as a particular user. Let's say they get a shell, then what? If they have no access to the filesystem, what can they do? At best, they could send some crafty code into the program's memory space that will cause it to forward data elsewhere. That is assuming that they can even gain access without (at least) momentarilly showing up in the process list (which would lead to immediate eviction).

            Despite the metion of OpenSSH, it could not benefit from TCP Port ACLs. It needs to be Root anyways.

      2. By schubert () on

        1. is complete bullshit. the guy at www.lucq.org did a rough (and WORKING implmentation) in _very_ little code. Chflags is more complex then a simple addition than new sysctl variables.

        4. Systrace itself is INHERENTLY complex because it REQUIRES complex config files. sure you can have them automagically generated for you but how optimal are those config files? (you can drop apache root port 80 privs with it with _1_ line in /etc/sysctl.conf, how big is your /usr/sbin/httpd systrace config file again?)

      3. By Anonymous Coward () on

        >> 1) complexity. more complex the code, more prone it is to bugs and harder to manage. KISS

        Yes, keep it simple!

        What's the current workaround to running a service (e.g. apache) on a non-privleged port, but still having traffic from joe-schmoe user get directed to a priveleged port from the outside? (drumroll)

        It's complex!

        Having to stick a bridging fw in between and redirect privleged port traffic to non-priveleged port running daemon is not a simple task. Moreover, it requires more hardware + software - thereby such existing methods to workaround this problem are inherently more complex as another point of failure (not to mention cost and configuration) is introduced into your network.

        Sure, you could run the service on a non-priveledged port, and have clients connect on the appropriate port, but that also adds complexity, either due to user stupidity (impossible to solve), or flawed client design (in which case you might have to redirect from the client end as well using netcat or something - definitely not 'simple').

        >> 2) ACL's are "hard" to implement correctly if you are new to using them, so it wont help much if you do not know exactly what you are doing.

        I don't see this as being any more difficult to implement than the alternative methods of accomplishing similar levels of robust daemons. (see below on discussion of the difficulty of properly implementing systrace to be functionally useful).

        >> 3) seems there is a remove-suid-from-everything movement, specially some of the work that has happened recently in openbsd... privsep ssh, no suid sendmail, etc. This seems a more simple alternative solution to the problem, and alot easier for programmers and administrators to manage.

        Agreed, there are aother alternatives, and some are simpler - but that doesn't mean that they're necessarily enough, nor that they're the simplest. The notion of priveleged ports has long been disputed as a major problem with Unix's relation to networking, look at most of the modern alternatives (plan9, EROS, etc.) they've sought ways to address this as it is a problem that applies to more than just sendmail, or sshd, or BIND or apache. You could either do a lot of work, privseping & auditing -each- application (something that should probably be done ultimately, but it will -never- happen), or you could address the meta-problem, and take care of at least one aspect of it. Port ACL's are not a panacea, and work still needs to be done in order to make those daemons secure as well, but by tackling a root issue, then the process for improving each individual daemon will be somewhat simplified - I think it's a net gain; do a bit of hard work up front - to make life a little easier when it comes to improving the sshd & ftpd's of the world.

        >> 4) openbsd now has systrace, that can protect main things you may need acl's for, such as around the apache remote exploit, where they could get a shell... with systrace properly configured, they would never be able to get a shell.

        Systrace is great, but it addresses a completely different problem. And one note - getting systrace -properly- is not necessarily as easy as it seems (it can seem way _too_ easy if you've worked with it much, props to Niels on the interface ;).

        Not only are you going to deal with performance and rule ordering issues (since systrace rulesets go by first match wins - ruleset ordering can greatly affect speed, or greatly affect security), but how many people are going to have an understanding of all (or heck, -any-) of the system calls anyway? The auto-ruleset generation mode is quite useful for a novice to just get things working; just as the "Accept all" (ACK!)option - but generating a ruleset that 1. works for all intended instances, and 2. actually blocks unintended usage is not something that a novice (default?) user can necessarily be expected to do, or at least do -properly-. Until OpenBSD ships with more preconfigured systrace rulesets (/etc/systrace only has -two- rulesets shipping in snapshots right now) for common daemons, and those rulesets are being used for the default services, it's just not going to be used much, and worse, it's not going to be used effectively in many instances either.

        I still think that the port-ACL idea is great, and something that OpenBSD should really look to adopt in some form. Other types of access controls (MAC for file access, etc.) I think are a bit useless unless you're going for some sort of military/Orange book/whatever type of cannonized notion of security - but the notion of priveleged ports is a relic that should be disgarded. It is a detriment to _functional_ network security more than it improves it. The idea that only the root account should be binding to those ports to prevent users from running their own network services etc. was never successful for keeping unwanted services running on a machine (e.g. ftp4all as a pure userland ftpd); moreover - Lucq's ACL patch, still addresses the idea that you don't want users designating what runs (so even though root doesn't need access to port 80 directly, it can still say that only the apached run by www can connect to it).

        Seems sad that when so much of the OpenBSD developers take the approach of "shut up and code" that when someone who has contributed other patches that have been incorporated, submits something that could really be an asset to the overall security paradigm of the OS - that it is getting this sort of disrespect, and lack of a decent argument against its implementation (albeit, maybe not from an OBSD developer directly).

        The port ACL patch [or something like it] -has- merit. Don't just write it off as complex, or that there are other workarounds (they don't cut it, or address different issues in my opinion). Maybe it's not the right design for OpenBSD as it stands now, and requires reengineering, auditing and so on - but it's seems like it, or something similar, could be really valuable (in a way that an sshd written in Java isn't ;)

        Comments
        1. By Anonymous Coward () on

          Sure, you could run the service on a non-priveledged port, and have clients connect on the appropriate port, but that also adds complexity, either due to user stupidity (impossible to solve), or flawed client design (in which case you might have to redirect from the client end as well using netcat or something - definitely not 'simple').

          nat is already implemented in pf. acl for port requires more kernel code. that is more complexity.

          Comments
          1. By niekze () on

            and what happens when a user process starts listening on the non-priveledged port you've been using??? (which is one of the mains reasons for the whole priveledged port idea in the first place)

            On the otherhand, with ACL's, this could be solved easily.

          2. By Anonymous Coward () on

            Have you even bothered to look at the ACL port patch? It's just under 800 lines worth of patches - hardly huge.

            Comments
            1. By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net

              where's this patch at? I'd like to take a look at it.

              Comments
              1. By Anonymous Coward () on

                http://www.lucq.org/openbsd/patches/network_port_acl-20020327-0927.tgz

                Comments
                1. By Anonymous Coward () on

                  yes it looks like the same code they used, so they already did the integration. it doesnt apply cleanly anyway on current, and they have the gcc canary stack protection built in. they also talk about rfc tcp/ip mods, and tcp/ip speedups, and privacy. seems like they are gathering alot of work from others and merging it into current while building on a base install and creating utilities. ill site back and watch. heck let them do all the work if they want. Its still a good concept reading their web site.

        2. By Anonymous Coward () on

          Having to stick a bridging fw in between and redirect privleged port traffic to non- priveleged port running daemon is not a simple task. Moreover, it requires more hardware + software - thereby such existing methods to workaround this problem are inherently more complex as another point of failure (not to mention cost and configuration) is introduced into your network.
          It doesn't need to be a separate machine running a bridging firewall - see nat.conf(5) for an example (using rdr to direct incoming connections to port 80 to a service running on 8080). Allowing non-priviledged binds to <1024 does give some benefits over doing this (i.e. for Apache, not showing the 'internal' port number in server-generated absolute links) but that's not really a problem in many situations.

    6. By me () on

      I could of course be wrong, but doesnt at least freebsd allow you to reconfigure the "must be root to bind to ports lower than 1024" with a sysctl?]

      assuming that it is the port <1024 root thingy you are talking about :)

  2. By Anonymous Coward () on

    it's a good sign when they have enough taste to make postgresql one of their database ports. :-)

    Comments
    1. By Chris Humphries () chumphries@drauku.net on http://drauku.net

      which i brought up... i mean mysql is in there and mysql isnt even a real database :) (yes i am biased, but i believe for good reason:) )

      niness doublechecked it, and i think brad committed it :)

      also secure pop3 got added as well... as it wasnt in there and was setting up popd over stunnel :)

      not sure who checked that in.

  3. By zil0g () on

    what did I miss here, µBSD == 200MB?
    how incredibly useful for that 32 flash card I've been wanting to buy...
    hold on, I think I'll just re-tar base31 to make it fit.
    ...stability from F%#!BSD?
    /* end rant */

    there, done, it does look interesting though :)

    Comments
    1. By pixel fairy () on mailto:pixel [shift +2] [not photosho] y

      why dont you just use a cf card? you can get those up to 1G

  4. By Anonymous Coward () supc@bsdaemon.be on mailto:supc@bsdaemon.be

    read http://microbsd.wiretapped.us/0.5/i386/INSTALL.i386
    seems like they did s/OpenBSD/MicroBSD ...

    Comments
    1. By Anonymous Coward () on

      Just to get famous!

      Another ripp off.

    2. By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org

      Well, this is a growing trend in the *BSD derived project world.

      I personnaly consider giving people a so-called installation document that is full of inaccuracies, a disservice to users, if not more.

      At least this particular search-and-replace operation does not point people to OpenBSD mailinglist for the problems they might encounter. Although I doubt the address is valid...

      Comments
      1. By Anonymous Coward () on

        It seems something went slightly backwards from their 0.5 release from their 0.4 release because the install doc in it is factually correct, even on the 0.4 ISO so there might have been an oversight/issue in their 0.5 release. Who knows what happened. Anyway Ill keep my eyes on the project. The original author did say its fairly new so they may have slight bumps in the road. heck who hasnt had them.

    3. By Anonymous Coward () on

      And the problem with this is what? Fine, make your own distribution. CMU made MACH from BSD. FreeBSD and Net BSD came about from BSD, and OpenBSD was derived from NetBSD. So what is the issue with MicroBSD? Have you failed to read the BSD license? If every tom, dick and harry wants to make their own BSD distro., they can. If they don't want to give you the source, they can. It is a big reason Theo feels strongly about the BSD license. Do what you want with the code: make your own distro, put it on a router, charge money for it, take it and modify it... The code is free, do what you will.

      Comments
      1. By Anonymous Coward () on

        The problem with 'this' is evident if you reread Miod's post. Borrowing and releasing one's own BSD/whatever to fill a need is great - but:

        "giving people a so-called installation document that is full of inaccuracies, [is] a disservice to users"

        It could just be growing pains - and it looks like MicroBSD is picking up some things that might not make it into the base OpenBSD distro (e.g. the Lucq port-ACL patch - I'll echo that I'd like to see something akin to it in the OBSD base install). So in time maybe MicroBSD will differentiate itself just as the other projects you mentioned have over time. For now, it's not quite there, and the reason for it existing right now isn't clear either.

        For now it would be nice if they took a step towards cleaning up their documentation to indicate that they're really moving in their own direction. If all you're really doing is repackaging the work of others, best to do it properly.

        If you look at the evolutions of other BSD-derived projects (some mentioned in your post about), they tended to fill more of a -need- than anything else. However, the growing trend seems to be less about meeting needs others haven't faced, and more about repackaging the work of others. This is the same phenomena seen in myriad Linux distros, distinguishment based upon packaging, and not content in 95% of the cases. No one wants or needs the lame distribution trend to continue with BSD's, especially if they can't take the time to get the simple things correct.

        Hopefully MicroBSD will do more of the need based improvements. I would hope they branch out into actually incorporating new innovations, and not just tossing it together with other people's work; I mean who cares about postgresql as a distinguishing feature, it's a port for many platforms. OpenBSD has been doing a lot of -new- things of late, with pf and systrace just in the past year. Not that they don't borrow other bits (e.g. the TCP speedup that was recently committed) but overall they've got some distinguishing characteristics (first OS w/ an integrated IPSec stack, first to ship with SSH [their own even]), etc. We don't need clone-BSD's, we need more innovators.

        Comments
        1. By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net

          so dont use it then.
          that was simple.

    4. By Jedi/Sector One () j@pureftpd.org on http://www.films-gratuits.com/

      There's one very positive thing they added to the installer : it asks for the keyboard encoding.

      Comments
      1. By Anonymous Coward () on

        Which has been in 3.1 AFAIK. Hence, not that new at all.

  5. By OutBack Dingo () dingo@microbsd.net on http://www.microbsd.net

    While we realize we are probably due for more flack, let me point out the positives, yes there is some cleaning still needed. We know it. There is only 4 of us working on this so far. Things take time. As for the rest well we are currently the only BSD distrib with Stack Protection build in. It was there in 0.1. And we are moving in a direction that other BSDs are not, like a web/console based GUI to manage all aspects of the system, even firewall rules! Also this is not just a distro, in short time you will be able to from a cdrom bootup build a complete secured server for http/smtp/ftp/dns/firewall/sql etc etc etc. Making it far simpler to roll out internet based systems that come protected out of the box. These systems are being designed to be turn-key, easy to manage and secure out of the box by default. These are our initial goals, unlike the other BSDs and yes we realize we all will have our place in the BSD world. Just stay tuned, cant hurt to watch. It obviously would take less energy then replying to posts here.

    Comments
    1. By Nothing personal, just business... () on


      You might want to hide this stuff:

      http://www.microbsd.org/pipermail/

      and protect private information about your(?) employees:

      http://www.microbsd.org/pipermail/corp_preferredpump.com.mbox/corp_preferredpump.com.mbox

      Quoting OutBack Dingo:
      > These systems are being designed to be turn-key, easy to manage and secure out of the box by default.

      Thanks, but I think I will pass.

      Comments
      1. By Anonymous Coward () on

        Ummm seems you have the wrong URL there freind, its microbsd.net not microbsd.org

        Comments
        1. By Anonymous Coward () on

          .net and .org point to the same IP address.

          Comments
          1. By Anonymous Coward () on

            odd cause .net and .org are owned by two completely different people, but .org is owned by the same person who owns .com, ans its a virtaul server located in NY so the data you are seeing might not be theirs

            Comments
            1. By Anonymous Coward () on

              grr...
              Check for yourself:
              http://www.microbsd.org/pipermail/
              http://www.microbsd.com/pipermail/
              http://www.microbsd.net/pipermail/

              It's theirs, all right

              Comments
              1. By Anonymous Coward () on

                yeah we see it also, but its a virtual server, so its hosting multiple domains currently and if you read the microbsd.net site it says they are on temporary space while their links are re-installed, i email the guy, he said he doesnt own microbsd.org or .com someone in england owns them and has pointed the at .net, he also said he got a request from someone who wanted to buy the domain name. He also said that they are on a colo service located in NY temporarily. I see him your post.

                Comments
                1. By Anonymous Coward () on

                  It seesm as though whoever is hosting them uses a control panel application which is actually the security problem, it like that on every site located on the box, not just the microbsd.net site

      2. By El Volio () on

        Of course, the same folks are running a REALLY old version of Apache (1.3.14), so there are some pretty serious problems there AFAICT.

        Comments
        1. By Anonymous Coward () on

          the same folks are running a REALLY old version of Apache (1.3.14), so there are some pretty serious problems there AFAICT.

          i'm running Apache 1.2.6 on a server (it needs a proprietary plugin that only works w/ 1.2.6), but it's been patched over the years.

  6. By Anonymous Coward () on

    Now the thing that really interests me is that the leader of the project is wanted in North Carolina for ripping off a previous employer by promising a system, taking the money then leaving the state. Some very interesting mssage board posts about this. Also not to mention that he is a complete and utter fraud. I would highly doubt if he even setup their servers. We could go on forever about this..

    Comments
    1. By Anonymous Coward () on

      Interesting. I can't find anything about this on google. Please link me.

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