"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"
"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)"
And here is a link into the presentation video: https://youtu.be/F_7S1eqKsFk?t=13m2s
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.
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…
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/>.
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.
It's not. It just happens to be currently maintained by someone who is also an OpenBSD developer.
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.
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...)
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.
You're thinking of doas, perhaps?
FreeBSD on the desktop is not a pain!
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.
-) 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
-) and just for fun https://www.youtube.com/watch?v=BlgdvSNpi60 (I love that video for some reason :D)
( 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).
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.
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.
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.
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".
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 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
E.g "My wifi is broken, where do I start?"
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 they will usually have the answers you need.
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.
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.
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 :)
* Sudo (...1980...)
wow. I didn't even think about sudo like that...
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.
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.
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.
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 software ecosystem as a whole has gained far more from OpenBSDs efforts than that of the PAX/grsec teams.
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.
See my reply to the other person replying to me.
Not all software works on whatever system you run, does that make that OS not worthy of whatever accolades it gets ?