Why OpenBSD Is Important to Me
ggr.com
ggr.com
Yes, there are NSA scandals, yes, the US government has repeatedly overstepped boundaries, yes, caution and scepticism is a very healthy and good thing, but on the other hand there are GNU/Linux distributions taking security somewhat seriously, they have to, they too work with open source code, have a lot of users, and review said code, I doubt someone is interested in your specific data, I doubt using a GNU/Linux distribution or some other BSD OS is some risk one shouldn't take, I doubt we should all have to automatically strive for an "ethical" all Free Software life or otherwise we are in risk of somehow being under totalitarian control, I doubt Apple and Microsoft are totally out to get you and by definition filled with evil backdoors the NSA uses to spy on _everyone_... I doubt they only do malicious things,... and talking about security, it's not all in the Software, a lot is in users' behaviour... not talking about him specifically, but "We are all spied on by the NSA, please like me on Instagram and follow me on Facebook for hourly updates on my life so we can join in the fight against totalitarian control"...
As you have guessed by now I am some kind of allergic to this... those idealistic over-simplifications... drawing everything in black and white...
Some of the OS X users I know are incredible technology-orientated and privacy concerned people, should I draw the conclusion they are being overly naive by not using OpenBSD for everything? I don't think so, they are just not suffering from paranoia, are pragmatic and living in the real world...
I avoid oversimplifications, too. Yet, most of what the author wrote was proven by precedent. Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment on that. Rest seems accurate.
"Some of the OS X users I know are incredible technology-orientated and privacy concerned people, should I draw the conclusion they are being overly naive by not using OpenBSD for everything?"
The conclusion is that they prefer to use OS X. That simple. Far as its security, it's made by a company that spent a long time lying to its users that they were immune to malware because Mac's were just inherently secure. They added lots of mitigations sometimes 10 years behind Windows and UNIX per one firm. I recall one vulnerability where an administrative service required a username and password for log-in but didn't check it against database. If you entered any password, you got in.
Such a history of absolutely, terrible security plus deception of customers means Apple products shouldn't be trusted for security by default. Any "privacy concerned people" using it are making a foolish mistake or intentionally trading away privacy for some other benefit.
Now, what you just saw me do was the evidence-based approach to these things. Helps cut through the noise nicely.
That's fair. FWIW I wasn't trying to focus on Linux in my post. I'm grateful for Linux and the volunteers that contribute to it, both the apps and the security work. The work everyone is doing on FOSS lifts all boats. And you're right of course, not all Linux distros are created equal when it comes to security. And my anti-privacy, anti-security sentiment was more pointed at proprietary software, i.e. a lot of iOS apps.
That caught my eye as well; lumping Linux in with Windows or even OSX is insulting in the extreme on the privacy front and only slightly less on the security front. To be sure, the focus on many Linux distros is not security at the forefront, and there are some that you definitely shouldn't trust if you're paranoid (those that use binary only kernel modules), but just being on Linux is a step in the right direction if you value privacy, freedom and security. Hell, can someone tell me if it's dead simple to install OpenBSD with full disk encryption? Debian has offered this for quite some time, and it's why I wipe and re-install even pre-installed Linux systems with it.
Dead simple. Full disk encryption on OpenBSD is a discipline of softraid(4). One bioctl command during the install will initialize a hard disk with true full disk encryption. When I say true, I mean, no separate un-encrypted /boot partition like LVM on LUKS requires.
Since you are a security researcher, aren't a lot of people of "your breed" using Macs as well?
As for the OS X security track record I don't claim to be incredibly well versed in that regard, thank you for the insight. But the piece doesn't primarily talk about security flaws, rather about systemic risks in using any sort of proprietary software whatsoever, especially by "evil" corporations like Microsoft and Apple (it might not say that directly, but that's how I conceived it) which I think is far over-emphasized.
I use Linux, BSD's, and custom systems. From what I've gathered, the people using Mac's do it for usability and apps more than anything. The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel. The real benefit is you get a desktop with comparable usability to Windows, you can pull out command line for full power of the UNIX underneath, it's overall more reliable/consistent than Linux on desktop side, and there's plenty of apps from vendors who target Windows + Mac but not Linux.
So, that's the overall value equation. A UNIXy OS with many apps and nice interface. I considered attempting to secure its foundation, Darwin, at one point but it's a hodgepodge of crap thrown together. Clever way to get a system out the door for Jobs back in the NEXT days. Not so good later on when one is improving foundations. :)
Note: Addressing your other point in a new comment as I can never remember length restriction.
Is it necessary to ignore the microkernel choice? Isn't MacOS X -not- microkernel, even though (or "because") it uses an old version of Mach? [0][1][2]
[0] https://en.wikipedia.org/wiki/Mach_%28kernel%29
So, Mach is its own discussion of failure in and of itself. There was also a history... Trusted Mach, Distributed TMach, DTOS... of trying and failing to secure Mach using high-assurance methods. The security improvements in new Mac OS's, esp sandboxing and such, were actually recommended with that old research in mind. They realized the foundation wasn't going to be secured as it never worked in the past. So, they went for decomposition and isolation schemes for apps themselves plus IIRC integration of TrustedBSD mechanisms.
The promises of microkernels seem extremely attractive to me, but we know that the promise of simplicity doesn't come for free (witness Hurd[0]). There were versions of Mach that were high-profile (i.e.: media/developer attention) microkernels, but I thought the Mach in MacOS X really was simply "not a microkernel". Interested to hear more about this if you've got illuminating info.
https://en.wikipedia.org/wiki/XNU
https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
XNU is monolothic software since it (a) merges code like BSD in with the microkernel and (b) has a ton of kernel-mode code in violation of microkernel principles. It can be said that microkernels can still benefit monolithic heaps of kernel code by providing a consistent, simple way for pieces to internally communicate. Windows has a microkernel inside of it for that reason IIRC.
"witness Hurd[0]"
Hurd is another failure. So many microkernels, including commercial deployments, have happened during the lifetime of that project not achieving its goals. Situations like Mach and Hurd are why people think microkernels suck. You have to see good examples. Did you ever use a Windows 95/98 box back in the day? Remember how it would choke trying to do anything intensive or concurrent? Check out what microkernel-based BeOS does on older hardware in my UNIX alternatives list:
https://news.ycombinator.com/item?id=10957020
Tannenbaum has a nice paper describing the two biggest problems plus different styles of handling them. It includes the microkernel techniques that are reason we like them for robustness.
http://www.minix3.org/docs/jorrit-herder/computer-may06.pdf
On capability-security site, KeyKOS had fine-grained isolation, protected communication, and checkpointing of app's state in case of failures. Shapiro's successor, EROS, is described in this document along with many key principles to high-assurance reliability and security that good work must leverage:
http://flint.cs.yale.edu/cs428/doc/eros-ieee.pdf
Note: Unfortunately, project is dead as FOSS contributors had little interest and he got poached by Microsoft. Did deliver a more secure networking stack and GUI system on top of a prototype kernel. COYOTOS project papers have some lessons learned, too.
There actually are under common distribution and licensing models. I used to think Stallman et al were vastly overstating the situation. These days, I think he was mostly right based on what companies did & do. I'll give you a few data points for your consideration.
1. Privacy/security. Proprietary vs open-source is false dilemma given first, secure system was a proprietary system (Burroughs B5000) that shared source with users. You can share source for vetting, local builds, or whatever while charging for it. Yet, most software comes as a binary where devious things are easily hidden. Many easily prevented 0-days and backdoors (esp undocumented FTP or SSH) have been found in proprietary systems over time. Even firewalls per Grimes' regular assessments. People are running out of room trying to find all the places Windows 10 is tracking users. They can't even turn them off. Leads to next risk.
2. Control. This is really most important. A fully, OSS product lets you use it however you choose. A proprietary licensed product, esp if not perpetual, can arbitrarily change how your product is allowed to be used later down the line. They can legally shut you out of certain benefits. This is getting common with app stores, DRM restrictions, games. I used to get games I could use permanently. Now, I often have to get online to access profile for even single-player games. The vendor, despite protest of users, plans to take service down after some time to force us to buy more expensive stuff. They also put ads in there because we can't turn them off so why not. Control is very important and many major companies are abusing the fact that "our" devices/software are actually "their" devices/software we merely get licensed to use only how they want to. Future-proofed against this with FOSS.
3. Lockin. Proprietary vendors often use obscure storage formats or communication protocols to make it hard to extract your data. They use custom API's to reduce portability. The result is that, after you build on them enough, you're effectively stuck with them since a move would cost exhorbitantly more than just paying an obscene licensing fee again. Such lock-in lets companies effectively stop innovating and benefiting their customers while their customers are powerless to do anything since the business, its apps, or its data just go bye-bye. Open storage, protocols, and API's can mitigate this but they (esp Microsoft) have nasty habits of subverting those with extensions or undefined behavior. So, FOSS clearly has a win here as you can just use the source itself to get off the platform if you want or pay someone to improve it.
4. One company I know specializes in proprietary hardware they sell but with FOSS software. In a discussion, the lead engineer told me he refused to use proprietary in their products since he was burned badly by one. The issue is the right to inspect code to debug and fix the dependency. You don't have it with proprietary & the vendor might not give a shit once you've already paid them. He (and FOSS advocates) argue that the complexity & bug-rate with modern software make it imperative to have source to ensure anything you build on it works correctly now and later.
5. Legal risks. No secret that licensing is often a minefield where compliance can be tricky. Vendors make it hard unnecessarily & overcharge. Business Software Alliance represents them telling customers' employees they'll get bounties if they snitch about instances of this then suing the crap out of small and mid-sized firms that didn't pay Microsoft, Oracle, etc enough. Big firms stay patenting software stuff, even cut n paste is Microsoft's haha, that they use to sue any competition or even users cloning to escape a bad platform. Recently, Oracle's argument that API's are copywritten essentially says nobody can make an alternative that's backward compatible and Oracle's users should be legally forced to be stuck with them. All these risks, except patent suits, are nonexistent when you use FOSS software. Plus, working with predatory companies seems wrong on principle.
6. Abandonware/bankruptcies. Company gets tired of supporting something or goes out of business. They can force you to keep buying something while basically not updating or supporting it any more. Lots of games and old apps in that status that are still fun/useful today but have to use emulators due to no source or legal restrictions. Impossible with FOSS as someone can roll up sleeves and code.
So, there's some datapoints that have and currently are burning up companies that invested in proprietary instead of open solutions. The major FOSS techs from 10 years ago still exist in some updated form with many others in development. Clearly systemic risk on one side of the equation with very little on other. What you think? :)
https://news.ycombinator.com/item?id=11669500
As I went to look up SIP, I found this at the top of the results:
https://threatpost.com/os-x-zero-day-bypasses-native-sip-pro...
So, not looking great so far. ;) Anyway, I decided to look further to find a Wikipedia article on it with what looks to be great description.
https://en.wikipedia.org/wiki/System_Integrity_Protection
From what I see, this is Apple's answer to the Biba model for integrity protection that's intended to divide system up into trust levels where untrustworthy processes can't write files they shouldn't. This was in Orange Book B1-B3 & A1 class systems such as Compartmented Mode Workstations. LOMAC model, SELinux/SEBSD, Windows Integrity Control, Argus PitBull, and Trustifier all implement this scheme to protect files integrity.
Let's just say it's a technique that helps but doesn't guarantee security by far. The reason is that the check is in the kernel. That can be bypassed by a 0-day attack on the kernel or below. Trusted processes that manage it might also be hit. Less likely, the person with control over it might be conned into installing something rogue. Seems Apple uses signatures to address that to some degree. So, one tool in the security toolbox just like it was in the 90's for CMW's. Gotta protect the privileged code and interfaces to it to make sure it's not bypassed.
One advantage of Biba and similar models are that they're conceptually simple plus very efficient in storage and CPU time. I think of it as an extra check to fall back on instead of primary protection. Cost almost nothing. Hope this write-up helps in your assessment of Mac security.
When my father-in-law bought a computer from Costco a year ago, it was full of malware from the start. He didn't care about the spyware--it was the constant popups, and the prompts to enter credit card info and login info that was the most worrisome. When my 'mom' sent me an IM message from her Hotmail account, claiming to be somewhere in Europe and needing emergency money, I had to call her up (she was not in Europe), get her to rotate her passwords on a bunch of accounts, work with her work IT team to investigate the security breach, etc. I've had one of my personal OpenBSD servers sucked into a DDOS zombie army (did I mention I'm a security newb?) and had to wipe the thing, rebuild, and ponder my mis-configuration sins. Security is hard enough (for me anyway) as it is without starting on a less than ideal foundation.
Criminals, for the most part, are (just) trying to steal money from people I care about...and when they're lucky enough not to lose their money, it can still cost a lot of time.
States have power over life and death, and there are plenty of examples in the US and elsewhere of bad people in government abusing their power to the detriment of relatively powerless people (and giving all the good people in government a bad name). I don't want to live in a police state, where saying the wrong thing over email can lead to bad things happening to me. We're not there yet (in the US), but we're not pointed in the right direction either. I think FOSS, secure software has a positive, important role to play. It cannot answer the larger political questions, but it can help, if only to buy us time to have the debate before the abuses get too far.
There are, to me, good reasons for using OpenBSD that have little to do with security. (I don't use OpenBSD as my primary OS, but that is a different story.)
What is most important to me is that the system is relatively simple as far as configuration/administration goes, and that it has very good documentation. It seems rather spartan at first, but on the other hand that means there is no hidden magic, which I have come to appreciate.
Also, the general approach OpenBSD takes towards security does not only improve security, it tends to result in software that is more reliable in general. One does not need to be paranoid to appreciate all that.
I really doubt the actual effect of using OpenBSD or whatnot on a PC users' security. It is a clean and beautiful OS, and if I wasn't blocked by hardware (ath5k, Atheros ARBXB63 on Asus X51RL, help appreciated) I'd use it (I use FreeBSD and I love love love it), but I don't think, as a PC user, it is necessarily considerably more safe in practice than a well-built Linux distro. _Server is another story though_.
So, yes, configurations and sharing will still be a problem compromising many users. But, no, the malware problem would be greatly reduced. That everything else is built on top of that integrity guarantee makes it the most important. Then, users can choose what they share, how they configure, and so on from there. Also, systems can be designed without need to share secrets to operate. Systems can also be largely self-configuring. We've seen both in market and FOSS. So, it's common issue but not inherent.
The morale is an ignorant user can easily be exploited even on OpenBSD, while a security-savvy user can secure himself even on an insecure OS. Thing is, the former is way more prominent, they're in billions. I don't dismiss advantages to secure OSs, but say that the more important problem is inept users.
They are and they aren't. What you're seeing is a combination of economics and improvements in software quality. Economics says they focus on whatever gets them the most zombified PC's since competition drives prices of each individual PC down in black market. To get this, they target apps with most widespread use. This is why almost all 0-days were found in Windows, IE, Firefox, Java, Adobe Acrobat, etc.
Microsoft's SDL & QA tools did them a 180 on code quality. Low-hanging fruit in major apps might be drying up because so many bugs were found. Attackers shifted focus to backend databases via hits on web apps as that's new low-hanging fruit (read: shit security) with huge rewards (eg million records at once) for success. So, it's not that it's gone away so much as not as popular while low-hanging fruit exists for their purposes. Organized crime, esp targeting online banking, plus nation-states continue to find, sell, and use 0-days for malware. It's still a thing except stealthier and more targeted.
"Aren't these more easily exploitable in practice than say a stack overflow somewhere in my programs (not a rhetoric question)?"
Oh yeah. Skilled hackers look for all of that. They'll look for that kind of stuff first since it saves time.
"The morale is an ignorant user can easily be exploited even on OpenBSD"
No argument from me there.
"while a security-savvy user can secure himself even on an insecure OS"
That's been disproven by too many pentests. You can cover lots of known risks but then get hit by something inherent in poor foundation you built on. I liken it to building your castle on foundation of quicksand. Security properties work layer by layer, piece by piece, from bottom up plus interactions with other systems via protocols. I might be able to secure DOS apps but DOS's intrinsic properties might eventually do me in. See what I'm talking about?
I'll add that user education has mostly failed. The recent consensus in INFOSEC is we need to design solutions where it's hard to do it insecurely and still easy to use. Signal messaging app is a great example of that. Another is Combex's PowerBox scheme for permissions on files where file dialog transparently grants a single file's access to app when user uses it. OS or runtimr protects its security. But, what user is giving to what application is clear even without technical knowledge.
So, education plus better design like I described is next steps.
The OS is partially to blame for that. I've got all my external services separately jailed in FreeBSD, with firewalls tuned to each service. Unless they come packing a 0day jailbreak exploit - a compromised service will spread no further, the web server isn't going to be SSHing into the kerberos server. Having your DB dumped sucks, but the really embarrassing compromises (HackingTeam, AshleyMadison, HBGary, etc) involved establishing a beachhead on a vulnerable service and then pushing in further.
You can manually set these thing up in any OS, but the easier an OS makes it to be secure - the more likely it is that the machine will be secure.
Also there is this https://github.com/tony/steam-freebsd-client but not sure how good it works.
This might or might not be of interest to you, since chances are it might I thought I'd share. I don't think FreeBSD is much more secure (if any) than some of the better GNU/Linux distributions though. So it's easier to just run Gentoo or something similar.
I don't think FreeBSD is much more secure (if any) than some of the better GNU/Linux distributions though
I do, and I've look through the source code of both.
Edit: too early in the morning. I misread FreeBSD as OpenBSD in that sentence
This way you can run Wine... PC-BSD users have done so for a long time now as far as I know.
Of course, I watch these communities from a distance. I'm not in the trenches over there. So, I could be way off. :)
Of course software is never perfect, but it's nice to know the (small) subset of OpenBSD developers working on OpenSSH are still working on keeping the proverbial doors locked.
EDIT: Morning brain made context shift unclear. They do OpenSSH and now LibreSSL. Also pf and more too.
In case you haven't used it, it's dead-simple, command-line based, and it may take a few times to get it right if you don't know what you're doing. It's nearly featureless.
But after you figure it out, you can automate installs, and roll your own distro by changing the contents of tar files, or add your own software and configuration the same way.
It's quite possibly the most satisfyingly transparent OS install method I've ever used.
Alpine needs a little work in the desktop OS department, and is painfully lacking in a few essential packages for daily computing, but it's come a long way in a short time. Meanwhile, Slackware is due to drop 14.2 on us any day now, and has seen vast improvements over the past few years. Both are worth a look if OpenBSD for some reason doesn't work on one's system.
But having said that, OpenBSD is a cut above any other open source OS when it comes to stability, clean code, and well written, complete, thorough documentation.
1. Boot up - this is very machine-dependent ("MD") so you'll find it in each architecture's source code. Look for files named "locore.s" or "locore.S" in places like src/sys/i386/i386.
2. Kernel - the machine-independent ("MI") part, or where the fun begins... this is in src/sys/kern/init_main.c, look for the function main(). You'll see the different subsystems initialized, from the lowest level (auto configuration of hardware devices and console initialization) through fundamental subsystems (virtual memory, disk, network, processes, etc.), all the way to the scheduler. The scheduler will only have one process to work with (PID 1) which is init (src/sbin/init), so that's what gets executed.
3. Userland - /sbin/init is the first process that runs, and it takes care of running everything else, like daemons and eventually your login prompt. Your points of interest in init.c are runetcrc(), read_ttys(), and multi_user().
There is also a presentation on openbsd.org/papers that seems relevant "OpenBSD Kernel Internals: The Hitchhiker's Guide". Direct link to PDF : http://atmnis.com/~proger/openkyiv/openkyiv2009_proger_sys.p...
Even if you don't run OpenBSD, you benefit from it.
One of them is not like the others -- OpenSSL is not an OpenBSD project and the code quality is markedly different :-)
and yes, OpenSSL is a bit of a code quality difference than the OpenBSD norm.
I do believe Ted Unagnt's comment is included in the https://www.youtube.com/watch?v=GnBbhXBDmwU LibrSSL first 30 days along with quite a lot of other oddities.
http://www.openbsd.org/innovations.html
^_^
My main problem with OpenBSD development is that all development is decided solely by the developers and there doesn't seem to be much care for what others want.. which is fine, they're doing all the work for peanuts.
Sometimes you just have to do things that aren't well suited for OpenBSD (imagine updating and ensuring hundreds of OpenBSD machines are up-to-date, and running high performant threaded applications). Many things work, but that is all they do. Sure it may be much more secure than other unix or linux offerings, it may be all there is. Much of the ports are just "get this to compile and work". That isn't always good enough. Truly evaluate if it fits your needs. If there is something you want on the platform, it may be up to you to fix it.
--
Unrelated, I find it interesting that NetBSD isn't mentioned once in this entire thread.
> all (OpenBSD) development is decided solely by the developers and there doesn't seem to be much care for what others want
This implies this is not the case for every other project.
To pick on your SMP performance example, Linux doesn't have better SMP because "developer saw that people want SMP, and decided to implement it". Linux has better SMP because some people came and implemented it. Not at other's people request, that is never relevant.
Different open source projects attract different (developer) audiences, and different project have different audience sizes, but don't make the fallacy that some projects chose what to work on (architecturally speaking) because user demanded it. That is never the case. Everything big happens because developers want it.
Many projects have different approaches to development. Sure, many people work on bugs most of the time, but there are big decisions about where the limited resources are going to be spent on new features. Those are the ones that truly matter.
There are examples of amazing things people have just done on a whim, but that isn't truly a standard and much of those things are generally huge.
Also, why OpenBSD specifically, and not FreeBSD for example?
That's not to say there aren't distros and contributors to Linux that care deeply about security--clearly there are. I just don't find the overall ecosystem nor the most popular distros nearly as focused on or as trustworthy on security and privacy. And as the stakes get higher with more of our lives going digital and more companies, states, and criminals trying to take advantage of that trend, I worry.
As for OpenBSD vs FreeBSD, I've had an easier time getting OpenBSD working on my hardware and OpenBSD seems to me more concerned with, focused on, and practically innovative on security--that is to say, they don't just introduce new security features that can be configured and used by someone smarter than me, the OpenBSD folks work hard to introduce new security tech that's on by default with no special knowledge required by the end user, i.e. pledge, W^X.
OpenBSD is actually no different. The developers care a lot about security and quality. Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. It's just the kernel and select userland that gets their attention to quality due to limited staff (and their preferences).
Are these "shoddy applications" not more secure on OpenBSD due to the various mitigations applied to userland software?
Don't you love reasoning by precedent? Makes these judgment calls so much easier. :)
[0] https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt
https://www.usenix.org/system/files/conference/usenixsecurit...
http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf
Note: Native Client, which protects Chrome, is a form of Control-flow Integrity. Hence, me using it as an example.
At least, that's the way I see it.
Now, are you saying that because it's possible to bypass the mitigations in some other cases, preventing that vulnerability (and others) doesn't matter?
Or, are you saying that it would be possible to craft an exploit that bypassed the stack protection for that particular vulnerability? In which case I would love to see your PoC.
Or something else?
OpenSMTPD (email for short) is the target. Default are Windows, Linux, and OpenBSD on x86. OpenBSD devises a mitigation: use SPARC processor since x86 malware cant work. As you say, the malware works on everything but the SPARC box. You and others claim it means the mitigation is secure and so is what uses it.
Now, some guy named Nick claims it's no more secure than a BSD/Linux 0-day on x86: they just didn't target exploit for that environment. Sure, they have to learn SPARC ISA and how OBSD uses it. Sure there's work involved. Similar mitigations were beaten in the past by first person willing to invest effort, though. So, Nick posits reason SPARC is safe from x86 malware coders is that they don't care enough to deal with SPARC boxes. Maybe no market share.
See how that works now?
A. We stopped those vulnerabilities from working because nobody can bypass this mitigation.
B. We stopped those vulnerabilities from working because very little talent is working on beating our mitigation.
World of difference there as Chrome and SFI/CFI teams I linked up above found out when smart hackers and braniacs from CompSci began convergjng on their work. And shredding it.
Code-Pointer Integrity was last one standing after first round of peer review. I'll use it for medium-assurance if it survives 2-3 more. Check it out.
You're completely wrong, stack canaries have nothing to do with kernels, they're a compiler option, gcc has them enabled by default, clang has them enabled by default. So no, running OpenSMTPD on Linux or OS X would not make that vulnerability exploitable.
Dumb question: Do you mean the field of computer science in general, or some specific tech or organization that uses that name? The former doesn't exactly make sense, but I've not heard of the latter and would be interested ...
In any case, I can give you some links to illustrate engineering software vs merely programming it. The first gives the concept with good analogies showing why we need it and what the difference is. Others are examples of methods for doing it.
What is High-Assurance and Software Engineering? http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt
Cleanroom Software Engineering http://www.engr.mun.ca/~dpeters/7893/Notes/presentations/Cle...
High-assurance CA with Altran/Praxis' method http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...
Hope these help illustrate what I mean by engineering software. Although, my use of the CompSci term includes anything else scientific or cutting-edge that's coming out of academia. I'll toss in one more showing secure browsing done right (maybe). :)
https://www.usenix.org/legacy/events/osdi10/tech/full_papers...
> Nobody really objected to the patch series as a whole, but Linus hated the name of the configuration option; he asked that it be called CONFIG_LEGACY_VSYSCALLS instead. Or, even better, the change could just be done unconditionally. That led to a fairly predictable response from the PaX developer on how the kernel community likes to hide security problems, to which Linus said:
>> Calling the old vdso "UNSAFE" as a config option is just plain stupid. It's a politicized name, with no good reason except for your political agenda. And when I call it out as such, you just spout the same tired old security nonsense.
He may also be calling Linux insecure due to it being less uncompromisingly about security. Same could be said about FreeBSD--they aren't necessarily insecure, but they are not as explicitly focussed on that.
OpenBSD invests a great deal here. They have their own fork of Xorg (or was that XFree86?) that runs not as root. As far as I know that's unique amongst libre *nixen.
EDIT: this is what I get for starting a response, getting coffee and resuming my reply. We don't have to speculate what the author of is post intended, and his response is better than mine ;-)
It's a standard feature of Xorg nowadays, but it's only a feature of vanilla Xorg for a few years.
AMD only added KMS to their proprietary driver last year, and Nvidia this year (and IIRC only in a beta driver so far); and systemd makes the permission handling a lot easier. So Ubuntu will transition to it eventually, but didn't have all puzzle pieces until too recently for even 16.04 LTS.
IMHO, I found it unconvincing. It soured me on the rest of the episode and its not really my watch as soon as its out podcast anymore. I guess since every segment is basically a FreeBSD segment no matter what OS they are talking about, it had to go that way.
YMMV
some years ago fbsd was forked to hardenedbsd which has aslr, mprotect restrictions, non-exec pages on cpus w/o NX, randomized lib loading order, etc. i guess the freebsd project is too busy fighting meritocracy cus none of it has been merged as far as i can tell.
as for linux, plenty has been written on linus' stance on what he considers to be a "security circus"; and the mantra on lkml is still that "a bug is a bug". just watch oss-sec and see distro people wading through kernel commit logs (hyperbole) cus sec-related bugs usually aren't reported downstream
> FreeBSD lacks basic low-level exploit mitigation, such as Address Space Layout Randomization (ASLR)
the whitepaper you linked was published in 2014 by Shawn Webb, one of the people behind the hardenedbsd fork. that same year a submission for review was opened on phabricator[1] re. merging their aslr work in mainline fbsd.
it was closed on 2015-10-19:
> Closing this revision. FreeBSD is free to pull from HardenedBSD.
another aslr review request was then created on 2016-03-10 by Konstantin Belousov[2]:
> This revision needs review, but there are no reviewers specified.
that same day he sent a call for testing to freebsd-arch[3].
there is also a bugzilla ticket[4] for the people waiting for freebsd to catch up with 2001.
1: https://reviews.freebsd.org/D473
2: https://reviews.freebsd.org/D5603
3: https://lists.freebsd.org/pipermail/freebsd-arch/2016-March/...
I love FreeBSD, and use it a lot, and I wish these were all implemented, but until then, it pains me that FreeBSD has less mitigations enabled than Windows and good Linux distros.
As far as I'm concerned, it's good to have options and the OpenBSD developers have created software that I use daily (OpenSMTPd, SSH, PF, etc.) and for that, I'm thankful!
ps. I know that developing IPSEC backdoors is not easy by any means. But the subsequent Theo De Raadt answer, was that he can't tell if there are backdoors or not. That was my point.
No, no with the same ease. Every OpenBSD commit is throughly reviewed, and there is only a bunch of commiters. Compared with linux, with thousands of commiters and tons of code added every day, OBSD is way more difficult to backdoor.
You should observe that this didn't happen here.
Sam Leffler found that bug, fixed it, and sent OpenBSD the patch while bringing the "fast IPSec"stack to FreeBSD.
OpenBSD silently patched it.
The whole thing only came to light years later, when the accusations were made.
I bet it now happens.
Leads me to what I claim is dirty secret behind "only 2 holes in..." claim they have: OpenBSD just fixes bugs they find without serious attempts to determine if they'd be exploitable vulnerabilities. They just do accounting differently than the rest. So, by their numbers, they only had 2 vulnerabilities because they didn't assess whether other bugs were vulnerabilities in the first place.
They have good code quality but they're full of shit about how vulnerable it is or isn't.
Security problems are usually clearly marked in the changelog: http://www.openbsd.org/errata59.html
What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release.
For a normal user that's fine, but if you have a bunch of servers you'll need a sophisticated build/deploy infrastructure to stay updated.
"What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release."
Yeah, that sounds like it could be annoying. They should have both options available given they already have to trust OpenBSD team to not backdoor their stuff.
And - architecturally - OpenBSD's kernel isn't that different from Linux, both being UNIX-style kernels; to the extent that OpenBSD's kernel has better security than Linux, it's mostly because OpenBSD tends to have fewer (and, sometimes, better-considered) features.
(There's an interesting argument to be had about Linux+grsecurity vs. OpenBSD - focusing on having some cutting-edge parts vs. solid engineering throughout - but that's not the argument we're having.)
Maybe because his comment had the tone of:
"For this, I have found a truly wonderful proof, but the margin is too small to contain it."
kernel exploits for OpenBSD are neither theoretical nor impractical.
You put that out there as a bare, standalone statement. No elaboration, no proof.
Your comment might be true, but I would have liked to see some more "meat" in it. Some supporting evidence, some inkling of a truly wonderful proof.
There are a bunch of local kernel exploits, all very practical and reliable. Kernel protections are something OpenBSD lacked until very recently.
That timeline isn't pretty. The OpenBSD guys really needed to be dragged, kicking and screaming, to calling it a "security fix" rather than something milder like a "reliability fix".
And you link to that not happening? Seems a bit silly.
How awesome is it that we have dedicated operation system geared towards the niche of the market that cares deeply about security?
The market doesn't work here. The OpenBSD people aren't responding to market incentives; they aren't earning much (AFAICT). They appear to be responding to internal incentives. The market's incentive for talented developers is to work on something else and get paid more.
That is, they appear to be doing this despite the marketplace, not because of it.
1: https://www.qubes-os.org/ 2: https://en.wikipedia.org/wiki/Chrome_OS#Security
RHEL (and thus, CentOS) does a pretty good job of configuring and enabling SELinux for packaged software.
There is a Hardened Gentoo. All the fun of normal Gentoo, but with fewer companions to find the compiler bugs. ;-) Still, they've built quite a stack of security patches, including grsecurity.
There is (used to be?) Hardened Linux From Scratch. Educational, but not practical.
OpenWall Linux is dead-ish, but - as you'd expect from a Solar Designer product - introduced several interesting patches (some backported from OpenBSD). You may be interested in http://www.openwall.com/presentations/Owl/.
I recommend - and use - OpenBSD, but there are definitely people interested in security in the Linux world.
> applying the grsecurity patchset will make your box more secure.
It also might not. Correct me if I'm wrong, but while grsecurity does a good job in kernel hardening, it won't protect from attacks like recent imagemagick system() injections, or from something like wordpress exploits, where you don't necessary touch kernel space or even binaries at all -- so it might be possible to have grsec enabled system and still be part of a botnet, or leak user data.
> enabling SELinux for packaged software.
This is a double edged sword also. Good thing is that a lot of software does have SELinux policies for it. Bad thing is that a lot of software runs in unconfined domain and that can give a false sense of security. For instance, if I recall correctly, systemd runs unconfined, while being itself a a) rapidly changing and b) half a million plus LOC software. And to err is human, you know -- SELinux won't "contain the bomb as it goes off" in unconfined domain.
Another example of bad approach with SELinux would be grepping for something in the audit.log and making policy module, which is even recommended in the official docs [1]. I do understand that its a major PITA to find good balance between convenience and security, but this particular example trains users bad practice from the start. Its worse than dismissing UACs -- its as bad as grepping for dropped packets in firewall logs and autocreating permissive firewall rules. Attacker calls her rootkit "yoursoftware.sh", tries needed functionality so that denials appear in audit.log, waits until sysadmin greps for "yoursoftware" and voila -- SELinux is perfectly ok and silent with rootkit. Its simplified, but you get the idea.
> Hardened Linux From Scratch. Educational, but not practical.
If we disable unconfined domain -- and hence be forced to formalize literally every syscall in our access matrix -- then any MAC system also can be called unpractical.
I think every statement of a "Use X its more secure" kind is very dangerous, unless you explicitly specify against what kind of threats its more secure. Otherwise, statement just adds false sense of security, and then human laziness kicks in, and we end up with a mess. Like, if I harden the system kernel, but fail to protect the user data -- or vice versa -- I simply end up without any sensible result, while thinking otherwise. Or I can start with perfectly reasonable defaults (same examples like OpenBSD or SELinux) and with few "convenient" commands open up huge security holes, and again, end up with not what I expect.
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
With respect to SELinux: I'm not a fan in all regards, but if you want to use SELinux, the fact that RHEL has pre-made policies for you does help.
As for someone like me, I used to build computers (more than a couple hundred) back in the 80s and 90s with alternate OSs to Mac (classic) and Windows but never tried BSD. I did try BeOS and OS/2 and Corel and close to a dozen different Linux distributions (I have the Penguins to prove it).
At the time I didn't know anyone else that used BeOS or OS/2 other than me. Personally I mean. So that isn't my excuse for not using BSD. Mostly I rarely heard about it. Now I'm old (laughing) at 55 and left BeOS and OS/2 behind years ago and moved to Mac Classic and then Mac OS X which runs on top of BSD. That's the closest I've gotten.
If you want more people to use BSD you really need to promote it more. Not just in nerd magazines but put out flyers around companies (don't ask, just leave them) with an explanation of what OpenBSD is and why they should be using it instead of Mac or Windows.
It needs to be brief and clear and you need to make VERY clear how they find and install OpenBSD and not just, "Go out and buy a computer and install it." That's like telling most people, "Go out and buy a nuclear reactor and install for the OS for it." It's not going to happen unless you are clear and you make it as easy for them as possible. People like easy and they want to feel like someone cares and that they will be taken care of if they have ANY questions.
Personally I feel that one of the biggest bad jokes is that "Microsoft cares". Really? Would you like to buy the Brooklyn bridge? Because it's for sale for $1.
If you get everyone you know to lay out flyers at businesses with what I describe above then you may get a few more people to use OpenBSD. But be prepared to support them in not nerd languages and without any attitude. If you have emotional problems (low self esteem, and I'm not saying that YOU do, well those people shouldn't be helping anyone else with anything) then I would suggest leaving support to other people.
Speaking freely is essential to democracy. The more restricted your conversations, the more careful you are about what you say. And being careful leads to less candor, less criticism, and less innovation. Thought and free speech are the breeding ground for new, sometimes controversial ideas. They are how we prototype, think new ideas through, refine them, and get them ready for wider distribution and discussion.
The actions of many 21st century activists seem to be diametrically opposed to this ethos and designed create a social landscape of civic censorship and extra-legal punishment for "thoughtcrime." I think a society with laws supporting free speech on the books, but largely made of authoritarian and censorial organizations is no more democratic in spirit than the Jim Crow south was inclusive with its "technically" enfranchised non-white population. (It doesn't so much matter what laws are on the books, if society at large thinks something opposed.)
For democracy to work, there needs to be freedom to dissent. I think many young people who grew up with web forums were exposed to so much draconian censorship, they've come to unconsciously feel that censorship is a key means of expressing power and "justice." I just hope that enough of them work out how intellectually bankrupt such a society would be.
That same libreboot article[1] says that AMD is not any better. Is there any alternative I'm not aware of? An ARM Chromebook is unfortunately not fast enough for me.
A bit of warning... I've seen this go wrong when people who don't know OpenBSD do this. Adding an additional OS means learning and "supporting" it.
* If learn your way around, get it set up well, keep your system updated the way you do for anything else, then you'll be in good shape.
* If you learn just enough to get it working and then set it on the back burner for when you can find the time to learn more, don't update it, etc., then you're better off going with an OS that you know and can keep secure.
I'm not trying to dissuade you, but I'd like you to evaluate if you will devote the time to using a new OS on a border device that it deserves. If you will then I think you'll be quite happy with your choice. :)
As secure as the machine is, its security slowly degrades the longer it is out-of-sync with updates (especially security ones) and/or admins administering the machines aren't good enough.
System administration isn't a set-it-and-forget-it type of thing.
Use a blobless OS like Trisquel, Guix and get libre hardware from the FSF.
Doesn't the former sentence negate the latter?
At this point, it seems just about all systems are hackable, given enough resources.
Hm. How is Phineas Fisher[1] is still on the loose then?
In general: In userland yes, in kernel yes and no and working on whatever seems too slow.
HN seems to love the anti-Linux FUD though. Anything that further fractures the OSS community is upvoted fast.
I like the BSDs too, but there are a ton of reasons Linux is the most popular kernel in the world, it's not just because the NSA makes it so.
personally I felt rather shafted by systemd, not because it's bad, but because my arguments were never even met, it was just a brushing off from some of the people who had already accepted it.
So I tried the BSD's and they were significantly better than I imagined they would be, I would put money on this being the case for other people who are upvoting these topics.
My laptop (thinkpad X201s) used to idle very rough under FreeBSD and suspend didn't work, but under openbsd it did.
Also there were some hardware drivers which appeared not to work at first but running 'fw_update' caused openbsd to download the device drivers I needed and they started working perfectly.
I'm still shocked how easy it was, sure I miss all my software that depends on /proc and I miss zfs.. but I can't think of an operating system that would fit my thinkpad better.
But that wasn't enough. They had to hijack bootloading, logging, device management, network, etc. For reasons that nobody seems to be able to actually explicate.
Or perhaps, since Poettering et al. are Red Hat employees:
Red Hat want to control it all ... for reasons
[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/stand/boot/
[2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/syslog...
[3] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/atactl/
[4] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/ifconfig/
Sadly though this has been done multiple times over, but then discarded because of CADT.
Pop over to Freedesktop.org and you will find the remains of a number of discarded projects. Most of them discarded just as they are 99% feature complete and the devs face the prospect of doing janitorial maintenance.
It's a nightmare. And it's incredibly ironic that the solution seems to be that you should migrate to operating systems where the userland and kernel are coupled together.
And that's the crux of the argument against systemd. Is clean service management more important than portability? Of course not! Linux has always been interesting because it's portable, not because it's easy or streamlined or standardized.
Pretty sure Tanenbaum would disagree. That said, I do agree that portability really is important. For that matter, I'd really like a decent FOSS microkernel.