Contributed by jose on from the uBSD dept.
"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)
By click46 () click46 at operamail dot com on mailto:click46 at operamail dot com
Comments
By Anonymous Coward () on
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).
By niekze () on
By plankalkuel () on
Comments
By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net
Comments
By Anonymous Coward () on
By Peter Hessler () spambox@theapt.org on http://www.theapt.org/openbsd/
By Chris Humphries () chumphries@drauku.net on http://drauku.net
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
By zil0g () on
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
By mechiel () on
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
By Mattt () on
"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
By Matt () on
"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.
By RC () on
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
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.
By schubert () on
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?)
By Anonymous Coward () on
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
By Anonymous Coward () on
nat is already implemented in pf. acl for port requires more kernel code. that is more complexity.
Comments
By niekze () on
On the otherhand, with ACL's, this could be solved easily.
By Anonymous Coward () on
Comments
By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By me () on
assuming that it is the port <1024 root thingy you are talking about :)
1024>
By Anonymous Coward () on
Comments
By Chris Humphries () chumphries@drauku.net on http://drauku.net
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.
By zil0g () on
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
By pixel fairy () on mailto:pixel [shift +2] [not photosho] y
By Anonymous Coward () supc@bsdaemon.be on mailto:supc@bsdaemon.be
seems like they did s/OpenBSD/MicroBSD ...
Comments
By Anonymous Coward () on
Another ripp off.
By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org
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
By Anonymous Coward () on
By Anonymous Coward () on
Comments
By Anonymous Coward () on
"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
By click46 () click46 at webpimps dot net on mailto:click46 at webpimps dot net
that was simple.
By Jedi/Sector One () j@pureftpd.org on http://www.films-gratuits.com/
Comments
By Anonymous Coward () on
By OutBack Dingo () dingo@microbsd.net on http://www.microbsd.net
Comments
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
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Check for yourself:
http://www.microbsd.org/pipermail/
http://www.microbsd.com/pipermail/
http://www.microbsd.net/pipermail/
It's theirs, all right
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By El Volio () on
Comments
By Anonymous Coward () on
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.
By Anonymous Coward () on
Comments
By Anonymous Coward () on