Hacker News new | past | comments | ask | show | jobs | submit login
Software developed or maintained by the OpenBSD project (openbsd.org)
168 points by yarapavan on Dec 18, 2015 | hide | past | favorite | 68 comments

I thoroughly enjoyed Theo de Raadt recent talk, "Pledge: A new security technology in openbsd". It left me itching to try OpenBSD.

"Pledge() is designed as a mitigation rather than a cure-all, de Raadt explains, but it's a mitigation with an interesting approach: a process or application stipulates the system services it needs, and if it steps beyond its boundaries, it's killed." http://www.theregister.co.uk/2015/11/10/untamed_pledge_hopes...

Hackfest 2015: Theo de Raadt presented "Pledge: A new security technology in openbsd"

video: https://www.youtube.com/watch?v=F_7S1eqKsFk

slides: http://www.openbsd.org/papers/hackfest2015-pledge/index.html

Note for those who don't really follow, pledge(2) is the System Call Formerly Know As tame(2).

This sounds exactly like seccomp and seccomp-bpf in Linux, so I don't think the feature is special to OpenBSD. Chrome uses it, for example.

From https://wiki.mozilla.org/Security/Sandbox/Seccomp#Intro_to_s...

"Seccomp stands for secure computing mode. It's a simple sandboxing tool in the Linux kernel, available since Linux version 2.6.12. When enabling seccomp, the process enters a "secure mode" where a very small number of system calls are available (exit(), read(), write(), sigreturn()). Writing code to work in this environment is difficult; for example, dynamic memory allocation (using brk() or mmap(), either directly or to implement malloc()) is not possible.

Seccomp-BPF is a more recent extension to seccomp, which allows filtering system calls with BPF (Berkeley Packet Filter) programs. These filters can be used to allow or deny an arbitrary set of system calls, as well as filter on system call arguments (numeric values only; pointer arguments can't be dereferenced)"

Pledge is much easier to user that seccomp-bpf and is now forced in more than half of the binary distribuited in the base system. Also, there is a big difference between having a technology and enforcing the technology: Seccomp has been included in linux for a very long time, but is ignored by most developers and not used except in specific instances (ie chrome as you pointed out)

...and the slides and linked presentation address this. Here is the slide: http://www.openbsd.org/papers/hackfest2015-pledge/mgp00011.h...

And here is a link into the presentation video: https://youtu.be/F_7S1eqKsFk?t=13m2s

Migrated my personal thinkpad to OpenBSD, other than firefox coughing up now and then - its been smooth so far.

Installing was a breeze, the man pages are well written, never had to run to google much except while partioning.

Also: Never knew sudo was a openBSD project.

Firefox won't crash if you raise the memory limit in /etc/login.conf. OpenBSD kills processes using more than 512MB by default.

Not quite what happens. OpenBSD doesn’t kill processes that use too much memory—it just causes any more memory allocation to fail. A well‐written program would detect that out‐of‐memory condition and try to handle it (maybe pause, or print a message to the user, or exit cleanly), but Firefox is not well‐written, and just crashes…

On the other hand, on Linux allocations succeed even when there isn’t enough memory on the system, and the OOM killer will kill a process once it starts using too much memory. Unlike the OpenBSD way, there’s no way for a process to detect that it’s using too much memory and handle it gracefully—you have to trust that the OOM killer is intelligent enough to never kill the wrong program…

Aborting on OOM is actually a deliberate decision by Firefox, to avoid the complication of dealing with failure cases (and NULLs getting everywhere) in every single memory allocation:


Thanks for clarifying.

I suppose it's more accurate to say that while OpenBSD doesn't kill processes outright, it maintains an environment where poor quality software will more likely crash than do harm.

The source of login(1) for anyone interested <http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/login/>.

Wow, I'll remember this the next time someone tells me memory allocations can't fail.

Seems like a great design overall, but I'm not sure how I feel about the fixed 512MB limit. That's too high in almost all cases, and too low for a few exceptions (e.g. browsers). Not that I have any suggestions for how to do it better, while still being reliable/predictable.

The limit is configurable, and is also set per login class. System daemons run with lower limits. If you create a user while installing, it’s added to the “staff” user class, which has higher limits than users added later—this works pretty well for the common use‐cases of “single user desktop” and “server meant to be accessed by multiple unprivileged users”. Of course, you can always configure these limits in login.conf if your situation doesn’t match up well.

> Never knew sudo was a openBSD project.

It's not. It just happens to be currently maintained by someone who is also an OpenBSD developer.

"currently maintained" seems to imply that this is a recent thing, so just to point out, millert has been maintaining sudo since before 1994.

Didn't openbsd attempt to rewrite sudo recently? There was a point about simplifying its configuration syntax.

Also, as a long time BSD fanboy, I've never considered OpenBSD to be a desktop OS. It's a great OS that I use on routers and servers, but never a desktop. I had a period where I used FreeBSD on my laptop but once I went Linux, I never looked back.

The utility is now doas(1) (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...)

Also, I'm surprised: I'm actually thinking about leaving Linux to put FreeBSD (or OpenBSD?) on my laptop (Linux is just too unstable and base utilities change non-stop: ip(8), iw(8), ifconfig(8), iwconfig(8), dhcpcd(8), systemd...)

> Didn't openbsd attempt to rewrite sudo recently? There was a point about simplifying its configuration syntax.

As the other two commenters said, you must be thinking of doas. Doas isn't a rewrite of sudo, it's an entirely new program with a different goal: capture the most common use cases of sudo and do away with most of the complexity to support the more involved scenario. This is a pretty common pattern in OpenBSD actually: provide the simple tool by default, let power users install the more complex tools if they need it for their work.

> Didn't openbsd attempt to rewrite sudo recently?

You're thinking of doas, perhaps?


Have you tried OpenBSD for desktop? FreeBSD on the desktop is, well, a pain. Hence PCBSD. But OpenBSD is actually pretty good at being a desktop, as long as you can live without some things like Flash and other things that will never be there.

PC-BSD is "the Ubuntu of BSD" – a preconfigured GUI, a GUI app "store" etc. If you can install OpenBSD, you don't need it.

FreeBSD on the desktop is not a pain!

FreeBSD on the desktop used be take a fair amount of fiddling. If that's no longer true then that's awesome! :)

A major cause of pain people are hit by when they try to use an operating system other than Windows is that they are uninformed about hardware compatibility. Frequently, when someone wants to try out a new OS, they'll try to install on their desktop/laptop/whatever and they will be frustrated to find a broken mess.

The correct way to get started with a new OS is to first try it out in a virtual machine. If you find that you enjoy using it, buy compatible hardware and go metal.

Strange, it's my desktop. I wonder how I manage.

I saw and thought the same thing at the bottom there! I also didn't know "su" = "substitue user" therfore "sudo" is "substitue user do".

I want to write some general things about OpenBSD / the OpenBSD Communtiy I realized while I gave it a spin just this month (in no particular order):

-) they are a "pressure cooker" for development, if they have to brake something in order to advance they will. way different mindest when you compare it to the linux kernel or FreeBSD. this does not mean it's unstable, but from version to version they might radically change something.

-) they strip down their system, if they don't like a license they don't implement it, and if something is too complicated / too big, they don't implement it. one of the contra-zfs-in-openbsd arguments (besides the license) quite simply is: it's so much code, it's so huge, it would be such an immense amount of work to audit it and to really really understand every single part of it.

-) openbsd runs on so many architectures partly because it allows them to catch more bugs. some weird bug you might encounter only while trying to install the system over network on machine xyz that nobody really uses anymore... running on so many multiple architectures gives them more input.

-) openbsd-community is way less elitist than people say/think it is. they expect you to have read the manpages (and they made such an effort to make them as good as possible), to maybe search on the internet yourself, to have tried some things out and to know how to use mailing lists, not too much in my opinion. they probably don't even mind the stigma of being elitists, as it keeps newcomers away. getting help is a privilege, not a fundamental right of every user.

-) they want others to use their tools. while it is probably unfair considering how many tools they provide and how little funding they get, nevertheless they actually genuinely are happy that their tools are used, which is an awesome mindset. but that probably is generally a bsd-license vs gpl kind of thing.

-) run your own sh*t! while many freebsd devs are simply using macs and running freebsd on their servers, openbsd developers are heavily encouraged to run openbsd everywhere they have the chance of doing so. you will find that most (maybe all) devs run it themselves on their notebook/desktop or at least on some of their private machines, which is awesome.

Some further resources:

-) openbsd faq http://www.openbsd.org/faq/ (especially section 1, 8, 9)

-) http://www.openbsd.org/ftp.html just give it a spin, why not? run it as virtual machine and play around, some hours worth while

EDIT (for some reason I can't edit above):

-) and just for fun https://www.youtube.com/watch?v=BlgdvSNpi60 (I love that video for some reason :D)

Good watch, thanks!

I'm always so surprised that OpenBSD seems to have a much smaller/tighter group of people working on the core[1]. Yet they seem to keep up and not only that, but also lead the way in some case (e.g. LibreSSL).

([1] Especially compared to the Linux kernel. Looking at maillist activity or number of different people, the Linux kernel seems to have a lot more people working on it).

It's worth remembering that OpenBSD does less--by design. There is no ZFS/Btrfs; there is no LVM; there is no SEOpenBSD, there is no support for mobile phone drivers, and so on. Linux can do many, many things that OpenBSD cannot do, and is making no effort to try to do.

But this is a good thing. It's why you're seeing OpenBSD "keep up": they've decided to keep things as simple as possible to enable them to be as secure as possible while still being a real unix, and what you're seeing is the fruit of that decision. The small team can now keep itself incredibly relevant, and can relatively easily stay on top of things in that space. The simplicity means fewer bugs and better security design, and more time to focus on third-party ecosystem support (e.g., LibreSSL, SSH, and so on).

In other words: it's not that OpenBSD is truly keeping up with Linux in general. In a very real sense, it isn't. What it is doing is keeping up, and even surpassing it, in a few very important, very key areas, and that in turn is keeping OpenBSD incredibly useful and incredibly relevant.

It is really impressive how much you can streamline and simplify a Unix system if you can afford to cut off legacy stuff. It's also great to see that stuff being spread outside the OpenBSD world.

Among the Linux-users I know, OpenBSD has a reputation for being very cryptic and, well, hardcore.

I am not really certain why. The installer is kind of spartan, yes, but it is not difficult to figure out. And not only is the system pretty simple, the documentation is really good, too.

I recently inherited an old laptop that would have ended up in the trash otherwise, and I installed OpenBSD on it. The battery is busted, unfortunately, but otherwise installing the system and setting up XFCE was pretty straightforward.

The community can be a little tough on newbies at times, but if one plays by their rules, they are a very friendly and helpful bunch.

> The installer is kind of spartan, yes, but it is not difficult to figure out.

In fact, it asks the same questions as a typical Ubuntu install: keyboard language, timezone, username + password, partitioning, network. They throw in a couple more questions about enabling NTP and SSH.

> And not only is the system pretty simple, the documentation is really good, too.

I think that newer users of Linux are not used to searching for documentation in man pages, instead they go look for an answer they can copy-paste off of Stack Overflow.

> I think that newer users of Linux are not used to searching for documentation in man pages, instead they go look for an answer they can copy-paste off of Stack Overflow.

Unfortunately, we see this for (some, newby) system administrators, too. I guess this is the typical issue with "getting it work" versus "getting it right".

What about docker .vs. real system administration?...

You know, if you use Docker for the right reasons, in the right way, it can be a real time saver.

I'm not really sold on the way Docker specifically tries to be fire-and-forget easy (it often succeeds in being silly and you have to work around it), but containers are good.

There's a lot of very useful software that just expects that it can do whatever it wants on a system, like install its own dependencies from git, run its own version of python etc.

You may want to run such software in production and it is an absolute maintenance nightmare if you install all the dependencies via package management. Upgrading starts with rebuilding and repackaging all dependencies. Not fun, and not a good use of time.

For such software, containers make it feasible to administer as somewhat manageable units: You create the Dockerfile or whatever to install the software you want, and run the resulting image on a host, and bring configuration in via puppet or something. Then, when you need to upgrade, you rebuild your image and deploy it on the host; rollbacks are trivial, as is scaling, or creating test environments.

You can of course achieve the same sort of thing with virtual machines providing you have good orchestration. However, often a deployment can consist of multiple software components that are separate units, but can (or must) share a single host.

I think so long as Linux containers don't actually offer real security, that's the niche where they are useful.

> I think that newer users of Linux are not used to searching for documentation in man pages, instead they go look for an answer they can copy-paste off of Stack Overflow.

I do not disagree entirely, but I would add that they've probably learned to do this because most linux distributions* are not very well documented -- in comparison to BSD systems, which are known for their amazing handbooks, man pages, etc.

*: Excluding (of course) Arch, Gentoo, and (Last I checked) Slackware

I know what you mean about man pages, but I think it's a little subtler than that. The man pages are generally useful if you already know roughly what you're looking for (i.e. you know that some utility provides the functionality you need) but can be a little troubling if you haven't a clue which combination of program, config file etc to use.

This is a fair point. As far as I know, on linux there are limited / no man pages covering general system architecture.

E.g "My wifi is broken, where do I start?"

Even older users can get into this habit. I started with Unix before the web existed. Man pages (or books) were usually the only documentation.

Then Google, and StackOverflow, and others came along and it was very easy to slip into the habit of just searching for answers.

When you use OpenBSD there isn't necessarily a lot to be found online, other than mailing list archives. But remember to look at the man pages and the OpenBSD FAQ[1] they will usually have the answers you need.

[1] http://www.openbsd.org/faq/

> Among the Linux-users I know, OpenBSD has a reputation for being very cryptic and, well, hardcore. I only played around on several occasions with OpenBSD but I always found it a lot easier and transparenter than Linux.

The only real difficulty with the installer I've found is the partitioning. That takes a bit of explanation.

It is a bit funny that it takes less time to run the installer and copy the needed files to /etc for our firewall than to re-image a disc. Same with our domain name servers.

I'm not sure that's really limited to any of the BSDs, honestly. Newer Unices and Linux in particular are pretty darn user friendly relative to how it used to be. And users have the backstop of googling for any answer these days.

OpenBSD hearkens to the older school of thought that reading the docs is not a bad thing and in fact can be a great place to start. It reminds me of my start on UNIX puzzling out the mysteries of UNIX one man page at a time.

You are in a maze of twisty little man pages, all alike.

the community is not tough on newbies; it is _harsh_ on those that do not read the documentation before asking questions. if something is not documented or documented incorrectly, that is a bug. too many folks who are new to OpenBSD do not bother to read any of the man pages or even the FAQ (which points to man pages) and then immediately hit the list, as if other people are supposed to do the reading and research for them.

Each release is like an obituary for grudgingly tolerated Unix software. See X11, Apache, BIND, Sendmail, OpenSSL, etc. Let's toast to a GCC replacement before 7.0!


I imagine GP is referring to XFree86, before XOrg.

Or essentially running as root, and aperture[0] mitigation?

[0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/...

A wonderful OS!

As a student I installed our faculty's firewalls based on PF, CARP (for failovers), Snort etc.

I wrote even a few articles on BGPD, Spam-Greylisting, Snort Intrusion Detection for a (now defunct) IT magazine from Germany :)

Those were the times, indeed....now back to JavaScript ;)

I used to host my personal web site on a Gateway 2000 beige box running OpenBSD installed on floppies. Those were the days.

For almost 10 years, the router at my parents' was my first PC (a Pentium 75 MHz with 16 MB of RAM and a 1 GB hard drive) running OpenBSD 3.0 or 3.1; I installed it, configured it, put it in a closet in the basement and didn't have to touch it until it died.

Thanks to the OpenBSD developers!

Surprised to see Niels Provos' name on that list so many times. Honeyd (and the associated book: Virtual Honeypots) was also developed by him and is quite interesting for anyone with an interest in cybersecurity.

Projects maintained by OpenBSD developers outside OpenBSD

* Sudo (...1980...)

wow. I didn't even think about sudo like that...

Not only that, the guidance you get (first root email, man afterboot, etc) enforces you to use a limited user instead of root and to learn about sudo.

OpenBSD now is using 'doas' instead of sudo (so the guidance you get points to 'doas', not to 'sudo').

When I did first try openbsd in the 4.x series, it was using sudo.

Also consider it really has one maintainer for all these years and is extremely complex in its capabilities

This is probably why they replaced sudo with doas.

edit: oh, seems sudo maintainership history is more complex and current maintainer has an openbsd commit bit.

With regards to malloc, what is the benefit of "random (delayed) free"?

Not 100% sure, but I think this is to mitigate exploitation of UAF (Use After Free) flaws.

Adding an unpredictable delay in between when an application frees some memory, and it becomes available for reuse elsewhere will likely reduce the window of vulnerability where an exploit may be able to leverage the issue.

> W^X: First used for sparc, sparc64, alpha, and hppa in OpenBSD 3.3. Today, most architectures implement it.

Oh come ON! Is OpenBSD still pretending they: a) invented this b) understood it (said "X is impossible" when PAX already did it)

Really, OpenBSD? Really?

Theo and friends explicitly say they don't look at what Linux does, which does explain that they can claim that they are first. 1) Don't look for or at state of the art. 2) Pretend you're doing state of the art, since you've not seen the others.

The PAX/grsec people generally appear confounded by this, claiming their patch was first and that they were #1. The reality is that even today their patches remain largely uncommitted patches, and as a community, they didn't push as hard as OpenBSD did and continues to do with upstream projects. They much rather publicly attack OpenBSD, which has historically ignored them preferring to do actual work.

The software ecosystem as a whole has gained far more from OpenBSDs efforts than that of the PAX/grsec teams.

This is ridiculous. Since OpenBSD started as a fork of NetBSD, one could similarly claim that innovations in OpenBSD are irrelevant if they have not been picked up and integrated by NetBSD.

What bothers me is that:

1) "We invented W^X" -- No you didn't. Well, at best you re-invented it. 2) "It cannot be done on x86" -- Uh, PAX is doing it on x86. ... 3) "Oh look how awesome we are, we invented a way to do it work on x86 too." -- Whatevs.

Don't build a straw man from my comment and pretend that I said things I didn't.

a fundamental difference between W^X and PAX is that PAX can be disabled on a per binary based, where W^X is applied on the whole system. That more aggressive aproach has been applied first on OpenBSD and i like to believe that's that they are referring to

You'd like to believe that but it's not.

See my reply to the other person replying to me.

OpenBSD does well for the areas it focuses on. It's easy to admire a project that has a narrow focus. The accolades always appear to come from those with the least amount of experience with it however. "I use it for a high performance firewall for my mom" "It's great as a desktop on my old laptop, that I do nothing with." It's like hearing someone praise Steve Jobs for inventing Photoshop, merely because they use it on a Mac. Fire up a high performance database on OpenBSD that uses a production equivalent of modern data. Setup a fileserver on nfsv3, use sshfs, or run the latest Linux version of <insert anything here>. Then talk about your experiences. "We are secure because we don't support firewire/bluetooth" is an invalid argument.

You're implying that OpenBSD is a toy OS. It's not. There are people using it for real work under real load. Is it the fastest? Nope. If you're spec'ing out a server and cutting edge performance is your major concern then you should pick something else. But that's not the only criterion in real production environments. There are roles where OpenBSD is not only an acceptable choice, but the best choice. As always, it's about the best tool for the job. No tool is the best for every job.

Have you ever used it in any of these roles you speak of? What was your experience?

Yes, I have. My experience was good. It's easy to install, configure, and maintain, and it's rock solid. But it's not the only tool in my toolbox.

Jack-of-all-trades is not everyone's metric.

Not all software works on whatever system you run, does that make that OS not worthy of whatever accolades it gets ?

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact