Table of Contents
Introduction
Secure by default
Security practices and philosophy
No way to thoroughly lock down a system
The need for extended access controls
Extended access controls are too complex
Conclusion
References
Introduction
Firstly, I would to apologize for, and clarify the title of this article. I wanted to use a title which would hold attention and encourage discussion while remaining true to the argument I make. I certainly don’t mean to imply that OpenBSD is a horribly insecure operating system – it isn’t. I do however need to highlight that OpenBSD is quite far removed from a secure operating system, and will attempt to justify this position below.
To start, we must clarify at a bare minimum what a secure operating system can be considered to be. Generally, this would be taken to mean an operating system that was designed with security in mind, and provides various methods and tools to implement security polices and limits on the system. This definition cannot be applied to OpenBSD as OpenBSD was not designed with security in mind and provides no real way to lock down and limit a system above standard UNIX permissions, which are insufficient.
Despite this OpenBSD is widely regarded as being one of the most secure operating systems currently available. The OpenBSD approach to security is primarily focused on writing quality code, with the aim being to eliminate vulnerabilities in source code. To this end, the OpenBSD team has been quite successful, with the base system having had very few vulnerabilities in "a heck of a long time". While this approach is commendable, it is fundamentally flawed when compared to the approach taken by various extended access control frameworks.
The extended access control frameworks that I refer to are generally implementations of MAC, RBAC, TE or some combination or variation of these basic models. There are many different implementations, generally written for Linux due to its suitability as a testing platform. The most popular implementations are summarized below.
- SELinux is based on the FLASK architecture, is developed primarily by the NSA, and ships with some Linux distributions by default, such as Debian and Fedora. SELinux implements a form of MAC known as Domain and Type Enforcement.
- RSBAC is developed by German developer Dr. Amon Ott, and is an implementation of the GFAC architecture. RSBAC provides many models to choose from such as MAC, RBAC and an extensive ACL model. RSBAC ships with the Hardened Gentoo distribution.
- GRSecurity is not primarily an access control framework, but a collection of security enhancements to the Linux kernel, such as JAIL support, PID randomization and similar things, as well as having an ACL and RBAC implementation.
- AppArmor is a simple yet powerful MAC implementation, which relies on pathnames to enforce policies. Relying on pathnames is a weaker approach than that used by the above frameworks; however this is considered acceptable because it is easier to use. AppArmor ships with and is enabled is versions of Ubuntu and OpenSUSE.
There are other simpler implementations such as SMACK and Tomoyo which are officially in the Linux kernel, as well as implementations for other platforms such as TrustedBSD and Trusted Solaris. Each of these access control frameworks provide for additional security to be setup when compared to what can be done with OpenBSD by default.
Secure by default
OpenBSD is widely touted as being ‘secure by default’, something often mentioned by OpenBSD advocates as an example of the security focused approach the OpenBSD project takes. Secure by default refers to the fact that the base system has been audited and considered to be free of vulnerabilities, and that only the minimal services are running by default. This approach has worked well; indeed, leading to ‘Only two remote holes in the default install, in a heck of a long time!’. This is a common sense approach, and a secure default configuration should be expected of all operating systems upon an initial install.
An argument often made by proponents of OpenBSD is the extensive code auditing performed on the base system to make sure no vulnerabilities are present. The goal is to produce quality code as most vulnerabilities are caused by errors in the source code. This a noble approach, and it has worked well for the OpenBSD project, with the base system having considerably less vulnerabilities than many other operating systems.
Used as an indicator to gauge the security of OpenBSD however, it is worthless. The reason being is that as soon as a service is enabled or software from the ports tree installed, it is no longer the default install and the possibility of introduced vulnerabilities is equal to any other platform. Much like software certified against the common criteria, as soon as an external variable is introduced the certification, or in this case the claim can no longer be considered relevant.
It is important to note also that only the base system is audited. The OpenBSD ports tree is not audited, and much of the software available in the ports tree is several releases behind current versions, meaning that there is a strong possibility that software will be obtained from outside of the ports tree. Given that a default install of OpenBSD has all network services are disabled by default, it is very likely that software will be installed or a service enabled if the server is going to be used to actually provide any kind of service.
Since the majority of attacks are not against the base system but against software operating at a higher level actively listening over the network, it is likely that if an OpenBSD machine were attacked, it would be through such software. This is where OpenBSD falls down, as it provides no means to protect from damage in the event of a successful attack.
Providing a default secure configuration is an important practice, and one that is employed by the majority of operating systems these days. OpenBSD followed this practice in the early part of the last decade when most other operating systems did not bother, and for that the OpenBSD team should be praised. While it is a good practice it is specious at best to take this as a measure of the actual security OpenBSD provides.
It should also be noted that the OpenBSD team uses a different definition of security vulnerability, limited to vulnerabilities that are allow for remote arbitrary code to execute. While most people may consider a DOS attack or local privilege escalation problems to be vulnerabilities, the OpenBSD team disagrees. If we use a more generally accepted definition of security vulnerability, OpenBSD suddenly has a far greater number than two remote holes in the default install a heck of a long time.
Security practices and philosophy
The OpenBSD team seems very reluctant to actually admit security problems and work towards fixing them. One such example is this CoreSecurity advisory from 2007. Instead of working and testing to see the extent of the damage that could be caused by a particular vulnerability, they prefer to dismiss and assume arbitrary code execution is impossible until pushed by Core releasing proof of concept code to show otherwise. This is similar to behavior observed by many corporations. Unfortunately this seems to be typical behavior rather than an exception going by the various mailing list threads when a vulnerability is reported.
OpenBSD was never designed with security in mind. OpenBSD was started when Theo de Raadt left the NetBSD project, with the goal of providing complete access to the source repositories. The focus on security came at a later stage, along with the “secure by default” slogan. As noted above, a secure operating system is not synonymous with a lack of vulnerabilities, and certainly not with a lack of vulnerabilities limited to the base install. This should be contrasted with the various extended access control frameworks, which despite being patches to an existing project, were designed from the ground up with a focus on security.
OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions. OpenBSD is often credited with pioneering many advances in security when this is not the case. OpenBSD tends to add protections much later, and only when absolutely necessary as they continue to erroneously believe that eliminating vulnerabilities in the base system is sufficient.
It is also odd that for a project that claims to be focused on security, sendmail is still their MTA of choice and BIND is still their DNS server of choice. Sendmail and BIND are old, and they both have atrocious security records. To look through OpenBSD’s security history, many of the vulnerabilities can be attributed to BIND or Sendmail. Why would anyone choose these programs for a security focused operating system, when far more secure alternatives designed from the ground up to be secure are available? Examples might include Exim or Postfix and MaraDNS or NSD.
It is interesting to compare OpenBSD to its cousin, FreeBSD. While FreeBSD does not claim to have a focus on security, it is in fact a far more secure operating system than OpenBSD due to its implementation of the TrustedBSD projects work. FreeBSD implements proper access control lists event auditing, extended file system attributes, fine-grained capabilities and mandatory access controls which allow for a system to be completely locked down and access controlled as necessary to protect against users or break in attempts.
Despite the TrustedBSD codebase being open and available for OpenBSD to implement or improve, they reject it simply because they consider it to be too complex and unnecessary. Even if the OpenBSD team did not want to implement extended access controls they could implement proper auditing through the OpenBSD project, which they still reject as unnecessary.
It is no wonder then that when governments or organizations look for a secure operating system, they look to systems that have proper access control lists and auditing, something OpenBSD is not concerned about. A good example of this is China choosing FreeBSD as the base of their secure operating system, as OpenBSD was considered insufficient to meet the criteria.
The library calls strlcpy and strlcat should also be mentioned here. These library calls were developed by Todd Miller and Theo de Raadt as a way to eliminate buffer overflows by ensuring strings are always null terminated. However this approach is controversial, and can actually result in further problems and security vulnerabilities than they solve. While they may have their place, they should certainly not be relied on, and doing so shows a poor understanding of computer security.
No way to thoroughly lock down a system
This is the main problem with OpenBSD, and what prevents it from being able to be considered a secure system. No matter how quality the codebase or how free of vulnerabilities, there is no sufficient way to restrict access other than with standard UNIX permissions. OpenBSD team leader Theo de Raadt has openly stated that he is against anything more powerful such as MAC being implemented which is a shame. There is no good reason to avoid implementing extended access controls when the greater security and control they provide is irrefutable.
OpenBSD does offer some basic protections to protect a running system, namely the chroot functionality, chflags and securelevels. The chroot implementation is a secure version much improved over the standard UNIX chroot, but still far lacking when compared to a proper jail implementation such as that provided by FreeBSD. The consensus among OpenBSD developers and community is that you can achieve the same result using chroot and systrace. Which means they rely on a third party tool to implement a secure design that is present by default in FreeBSD, NetBSD and numerous other unices.
Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc. These protections do absolutely nothing to stop information leakage. Making files immutable or appendable only is a poor option when contrasted with the ability to prevent reading and writing/appending to only specific users or processes.
The OpenBSD project and community had access to a tool for policy enforcement named systrace. Systrace is a third party tool developed by Niels Provos, and has never been embraced by the OpenBSD team. Systrace lacks the versatility of a proper MAC implementation, and had similar weaknesses to AppArmor since it relies on pathnames for enforcement. Systrace is a form of system call interposition, which has been shown to be insecure.
The only software even close to a MAC implementation is rejected by the OpenBSD team, and is insecure. Despite this, systrace is still maintained and offered/recommended by the community as the preferred way to sandbox and restrict applications. Given this obvious deficit, it would seem even more prudent for OpenBSD to make use of the TrustedBSD project.
This is the main reason why OpenBSD is unable to offer a secure environment in the event an attacker is successful. Instead of implementing a form of extended access controls and ensuring the system is secure even in the event of a successful attack, they prefer to remove as many vulnerabilities as possible. This approach is naïve at best and arrogant at worst.
The need for extended access controls
The main argument against OpenBSD is that it provides very limited access controls. OpenBSD attempts to remove the source of vulnerabilities by producing quality code, and has such faith in this approach that very little is provided to deal with a situation when a machine is exploited, and root access obtained. Perhaps inevitably. It is this lack of access controls and protection mechanisms that prevent OpenBSD from being the secure system it is often credited as being.
It is also the reason the aforementioned frameworks such as SELinux and RSBAC have an inherent security advantage over any OpenBSD machine. Due to the use of some sort of MAC, RBAC, TE or other advanced access control used by these frameworks, a level of control is possible above that in traditional DAC systems. With a traditional DAC system, the user has complete ownership over their files and processes, and the ability to change permissions at their discretion. This leads to many security concerns, and is the reason most attacks can be successful at all.
When a computer is hacked regardless of if it is due to a drive by download targeting an insecure browser on a user’s computer or a targeted attack exploiting a server process, the malicious process or user will inherit the access of the browser or process that was attacked. The prevalence of the DAC architecture throughout most operating systems is still the primary cause of many security issues today. With many server processes still running as a privileged user this is a large concern.
It is also something that is hard to fix without changing to a different design paradigm. Many of the technologies that were developed to help prevent attacks such as privilege separation; executable space protection and process ID randomization help, but are not sufficient for a majority of cases. This is why the need for an extended access control framework is present. With the use of something like SELinux or RSBAC, the significance of individual user accounts or processes as an attack vector is decreased.
With these systems every single aspect of your system can be controlled to a fine grained level. Every file, directory, device, process, user, network connection etc can be controlled independently allowing for extremely fine grained policies to be defined. This is something that simply is not possible with current DAC systems which include OpenBSD .
As an example of what is possible with extended access controls, it a web server process running as root could be set to only have append access(as opposed to general write access available in a DAC system) to specific files in a specific directory, and to only have read access to specific files in a specific directory. If some files need to execute, then that file itself (or the interpreter if a script) can be restricted in a similar way. This alone would prevent web site defacement and arbitrary code execution in a great many cases.
On present systems using DAC if a targeted attack is successful and access to the root account is gained, there is nothing the attacker cannot do. Run their own malicious executables, alter files etc. This is why OpenBSD is necessarily less secure than any system making use of advanced access control frameworks, and also why OpenBSD is not a secure system. While OpenBSD has many innovative technologies that make it harder for an attacker to gain access, it does not provide any way to sufficiently protect a system from an attacker who has gained access.
It is possible for example to restrict something like perl or python with extended access controls. On OpenBSD if a user or an attacker has access to perl or python, then they can run whichever scripts they like. With extended access controls, it is possible to restrict only certain scripts to have access to an interpreter (and additionally make those scripts immutable), and prevent the interpreter from running at all unless called by those specific scripts. There is no equivalent fine grained granularity on OpenBSD.
Another way in which extended access controls can help is to protect against users. Even on a desktop system there is a significant security advantage. At the moment most malware requires or tries to obtain root privileges to do damage or propagate. What most people don’t realize is that even malware running as a normal user can do significant damage as it has complete access to a users files under the current DAC model. With some form of MAC, if a user decided to demonstrate the dancing pigs problem and run an untrusted piece of malware, it could be restricted from having any access to a users files or being able to make network connections.
Even windows implements a form of MAC – Mandatory Integrity Controls. While not terribly powerful, and not used for much at the moment, it still provides increased protection and allows for more security than an OpenBSD box can provide. If even Microsoft can understand the need and significance of these technologies after their track record, why is OpenBSD the only project still vehemently rejecting this technology?
Extended access controls are too complex
Some people are of the view that extended access controls are simply added complexity, which increases the scope for vulnerabilities without providing any meaningful additional security. This position makes little sense. While it is true that adding extended access controls increases complexity, the meaningful increase in security cannot be denied. There are plenty of examples of exploits being contained due to such technology…exploits that would have allowed full access to the system if OpenBSD had been the targeted platform.
It has also been said such systems only serve to shift the attack point. Instead of attacking a particular piece of software, they simply have to attack the access control framework itself. This is simply a myth. While the frameworks themselves can be attacked and even possibly exploited, the increase in security far outweighs any risk. The extended access control framework can be extensively audited and made secure while allowing policies to be enforced. Having one relatively small section of code that is easily maintained and audited and responsible for maintaining security is not a decrease in security, but an increase.
Ideally, a proper extended access control framework would also be formally verified, as I believe is the case with SELinux and RSBAC, based on the FLASK and GFAC architectures respectively. This basically means that these systems have been mathematically proven to meet all of their specifications, making it extremely unlikely that it will be possible for the systems to fail in an unexpected way and be vulnerable to attack.
In almost 10 years, there have been no vulnerabilities reported for these major systems that allowed the framework to be bypassed. The times when there has been a problem, it has been due to poor policy. The example everybody likes to mention is the cheddar bay exploit that Brad Spender(author of GRSecurity) made public in July 2007. It’s true that this exploit allowed for disabling SELinux, but this was due to a stupid policy that allowed 0 to be mmaped for the purposes of allowing WINE to work. Only the RHEL derived distributions were affected. This is not a valid example of the framework being vulnerable, and it certainly does nothing to discredit the technology as a whole.
Due to limitations of certain hardware platforms, it is possible that with the right kernel level vulnerability, an extended access control framework could be subverted. These cases however are quite rare, and with the use of technologies like PaX they become even more unlikely to succeed. In fact, as of writing this article, I am not aware of example of an extended access control being able to be successfully subverted to the contrary. There are however, examples of extended access controls successfully protecting against certain kernel vulnerabilities such as SELinux preventing a /proc vulnerability that could lead to local root.
Some of these frameworks have been criticized for being too complex, in particular SELinux. While I don’t think this is entirely justified, as the SELinux team has made great progress with making this easier with tools such as setroubleshoot and learning mode, I can understand it may be a valid concern. Even so it only applies to a specific implementation. RSBAC, which is just as powerful as SELinux has far clearer error messages and is much easier to craft a policy for. Other implementations such as that of GRSecurity are far simpler yet again. The point here is that the technology is powerful and should be embraced as the added security advantaged is undeniable.
If complexity and user unfriendliness was the main concern the OpenBSD team had then they could still embrace the idea while making the implementation simple to use and understand Instead, they flat-out reject the idea, believing antiquated Unix permissions are more than enough. Unfortunate in this day and age this is no longer the case. Security should not be grafted on, it should be integrated into the main development process. This does not mean patching in protections for specific attacks along the way which is the approach favored by the OpenBSD team. The OpenBSD approach has resulted in a very impressive and stable fortress built upon sand.
Conclusion
While the implementation of various policy frameworks will mature and grow as needed, OpenBSD will remain stale. With a refusal to implement options for properly restricting users or a system in the event an attacker does gain access, the OpenBSD system will be considered a less reliable and trustworthy platform for use as a server or user operating system.
Extended access control frameworks should not be considered a perfect solution, or the be all and end all of security. There are still many situations where they are insufficient such as large applications that necessarily require wide ranging access to properly function. Even so, the level of control these frameworks provide are the best tools we have to secure systems as best we can.
It is interesting to note that even with Linux not really caring about security and having a non disclosure policy, things still end up being more secure than OpenBSD because of the presence of extended access controls. Being able to restrict access in such a powerful way which reinforces that simply trying to eliminate all bugs at the code level while noble, is an inferior approach.
As much as I am disappointed with the fix silently without disclosure approach to security the Linux kernel project has taken since Greg K-H took over, and having to rely on sites like xorl.wordpress.com to learn about security problems that were fixed, Linux is the only real project making progress with testing and improving extended access control frameworks. With continued development and support the implementations will become easier to use and the problems eradicated until such technology is common, as it should be.
OpenBSD cannot be considered a secure system until it makes some effort towards facilitating locking down a system with more than the standard UNIX permissions model which has been shown to be insufficient, and stop discounting the possibility that a system will be secure because all bugs have been removed. While well intentioned and accurate to a small extent, it is ultimately meaningless if even just one vulnerability is present.The OpenBSD team consists of highly skilled programmers who have an interest in security and have shown excellent skill at auditing code and identifying and fixing vulnerabilities in software. Unfortunately, they have shown no interest in extending OpenBSD to implement extended access controls as almost all other operating systems have done, leaving their system inherently more vulnerable in the event of a successful intrusion. The OpenBSD serve a useful role in the community, similar to dedicate security analysts or advisors, and for this they should be celebrated.
Note: I am aware that many people use OpenBSD for nothing more than a router, and for this it indeed ideal. For the use of a router, extended access controls would not provide much benefit. I wrote this argument however because many people seem convinced that OpenBSD has suerior security in all instances and including as a network server or user operating system. I became tired of reading these comments and people simply dismissing extended access controls as too complex and not providing any real security.
References
- SELinux – http://www.nsa.gov/selinux
- RSBAC –http://www.rsbac.org
- GRSecurity – http://www.grsecurity.net
- AppArmor – http://developer.novell.com/wiki/index.php/Apparmor_FAQ
- The TrustedBSD Project – http://www.trustedbsd.org
- Core Security OpenBSD Advisory – http://www.coresecurity.com/content/open-bsd-advisorie
- Marc Espie talking about security complexity and calling MAC security theater- http://thread.gmane.org/gmane.os.openbsd.misc/129217/focus=129371
- Theo de Raadt stating that MAC should not be included in OpenBSD – http://www.eweek.com/index2.php?option=content&task=view&id=30680&pop=1&hide_ads=1&page=0&hide_js=1
- An older similar argument on the OpenBSD misc mailing list – http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Security
- A simple argument now out of date, that makes a similar argument without going into detail – http://www.seifried.org/security/os/20011107-openbsd-linux.html
- Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools – http://www.stanford.edu/~talg/papers/traps/abstract.html
- Exploiting Concurrency Vulnerabilities in System Call Wrappers – http://www.watson.org/~robert/2007woot/20070806-woot-concurrency.pdf
- Bob Beck talking about systrace – http://thread.gmane.org/gmane.os.openbsd.misc/160797
- China chooses FreeBSD as basis for secure OS – http://blogs.techrepublic.com.com/security/?p=1682
- An example of SELinux preventing an exploit on RHEL 5 – https://rhn.redhat.com/errata/RHSA-2007-0960.html
- Dan Walsh talking about SELinux successfully mitigating vulnerabilities – http://danwalsh.livejournal.com/10131.html
- The start of the thread where Brad Spender’s Cheddar Bay exploit is introduced and discussed – http://thread.gmane.org/gmane.comp.security.dailydave/3905
- Details on the SELinux policy that allowed for the Cheddar Bay exploit – http://eparis.livejournal.com/606.html
- SELinux preventing a kernel vulnerability from succeeding – http://lwn.net/Articles/191954/
- A second example of a vulnerability that SELinux prevented, due to the users not having the required socket access- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0127
- A Phrack article detailing the ways current security frameworks can be exploited, and how to prevent against this – http://www.phrack.com/issues.html?issue=66&id=15
- A primer on OpenVMS security, a highly secure OS designed with security in mind at every level – http://www.blacksheepnetworks.com/security/resources/openvms/
- Presentation introducing Strlcpy and strlcat – http://www.usenix.org/events/usenix99/millert.html
- Start of a mailing list thread where strlcpy and strlcat are discussed and criticized – http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html
Update 1 – January 23rd 2010
I have updated the article to talk about the benefit of formal verification, and address the possibility of an EACL framework being bypassed with a kernel vulnerability.
Update 1 – April 23rd 2010
I have updated the article to reflect the correct status of the Openwall project (i.e. not abandoned), thanks to a comment by Vincent.
All that is wrong with the world... 
[…] This post was mentioned on Twitter by ximad, sam280. sam280 said: "The insecurity of OpenBSD" http://is.gd/6JcYi <- nice debunking of the "most secure OS" claims […]
Pingback by Tweets that mention The insecurity of OpenBSD « All that is wrong with the world… -- Topsy.com — January 21, 2010 @ 7:06 am
ACLs do not provide any additional security. It allows knobs to play with knobs making them feel smart. I have no idea who wrote this but it is ill informed and lacks any sort of substance. Any UNIX I have ever touched had them disabled within minutes of installation because some stupid app didn’t work. Claiming otherwise is naive at best.
Comment by marco — January 21, 2010 @ 9:29 am
Some facts you have wrong: OpenBSD did implement various forms of address space and other randomization (e.g. shared lib location, stack gap, heap, TCP sequence numbers and PID randomization) AND enabled them by default as a pioneer. All these techniques do implement various forms of exploit mitigation WITHOUT the admin having to do ANYTHING.
Your piece basically goes around is circles: DAC is not enough, MAC is the only way because DAC is insufficient and the “added security [of MAC] advantaged is undeniable”.
That’s all fine. If DAC plus things like privilege separation plus all the measures to catch remaining bugs in programs doesn’t cut it for you, then use something else. But i find your idea of running a web server as root plus MAC pretty dangerous.
Oh, and your reference to the thread re strcat and strcpy is just laughable.
Comment by Otto Moerbeek — January 21, 2010 @ 10:06 am
Of course I meant strlcat and strlcpy in my last sentence
Comment by Otto Moerbeek — January 21, 2010 @ 10:07 am
Thanks for the lengthy diatribe. What your anonymous ranting fails to mention is that no one on the OpenBSD team actually recommends using systrace to secure a system—and the man page actually calls this out and defines how a systrace policy might be subverted. In addition, all these complicated security measures you mention—are almost always disabled by default. Why? They are too complex, break too many things and would yield an avalanche of supports calls if they were ever turned on. In contrast, almost all of OpenBSD’s security features are enabled by default—and the ports tree does not break when they are in use. This is where the secure by default mantra shines—and you aren’t relegated to some special OpenBSD build, patch kit or obscure Linux distribution to have a secure environment (although the Linux community is making some strides here).
Comment by Bink — January 21, 2010 @ 12:57 pm
@marco – That is rubbish. It is naive to ignore the increased security that ACLs and MAC can provide. There is simply no other way to implement similar granularity with plain old DAC, which is required for proper security.
@Otto – Thanks for your reply. I actually did try to find instances of OpenBSD pioneering the protections you mention, but was unable to find anything. If you would be happy to provide me some source, I will be happy to update my piece.
I am aware I repeat myself a few times, and hope to refine my article over time. However my point still stands, which is that OpenBSD’s resistance to anything even resembling MAC is preventing it from being a secure system.
The thread on strlcpy/strlcat is quite interesting, and there are other similar threads. Good points are made and examples provided, so why is it laughable?
@Bink – Did you actually read the piece? I actually point out in the article that the OpenBSD team rejects systrace, and provide a reference to them doing so.
You also miss the point of my article. Yes, SELinux may often be disabled by default, however that is a problem with one implementation, not with the technology. AppArmor, RSBAC, GRSecurity – none of these have to be disabled by default and provide far greater security than OpenBSD could hope to.
Don’t let SELinux give the technology a bad name.
Comment by allthatiswrong — January 21, 2010 @ 1:45 pm
“The modified system calls strlcpy and strlcat should also be mentioned here. These system calls were developed by Todd Miller and Theo de Raadt as a way to eliminate buffer overflows by ensuring strings are always null terminated. However this approach is controversial, and can actually result in further problems and security vulnerabilities than they solve. While they may have their place, they should certainly not be relied on, and doing so shows a poor understanding of computer security.”
Some issues with this statement. First, they are library calls, not system calls. This is a fundamental difference and it seems odd that such a fundamental mistake was made here because where str* routines are implement would have big security implications if they were in the kernel…
Second, they were added, not modified (code using strcpy, et al was modified to use the new code). A small point, but still a pedantic one.
Third, my experience as the FreeBSD security officer for a number of years a while ago leads me to question the conclusion of this statement. While semantic differences can occur with this interface, buffer overflows are indeed stopped. The number of vulnerabilities fixed by blocking the buffer overflows was large, and I didn’t see a single case where a truncated string caused real problems. Could you site some study or otherwise provide evidence of number of each category to back up this statement? If flies in the face of experience.
While I agree with the need for MAC, and that having MAC makes the base OS more secure (FreeBSD includes the TrustedBSD framework by default, for example), some statements like this are definitely over reaching.
Warner
Comment by Warner Losh — January 21, 2010 @ 3:49 pm
Wow.. just wow..
First off, the Apache 1.3, Sendmail, and BIND daemons in OpenBSD are not your typical code. They do undergo extensive code auditing and OpenBSD specific patching, but that’s besides the point.
Apparently you don’t understand the first thing about the licensing between qmail, djbdns and OpenBSD.
Sendmail isn’t set to listen to ANY host but localhost. They’ve also made their own smtp now (opensmtpd) which has been committed to the source tree – and nsd has replaced bind.
Who runs a web server as root anyways? You really shouldn’t be an admin if you do. OpenBSD’s Apache runs in a chroot by default anyways.
You also failed to mention any of the projects the OpenBSD team created – OpenSSH, OpenBGPD, OpenNTPD, OpenCVS to name some.
Anyways.. Later.
Comment by Piranha — January 21, 2010 @ 4:02 pm
This is obviously written by someone that does not have much real world experience as a systems administrator. The idea behind “secure by default” is that you can deploy an OpenBSD system in to the wild as an exposed server with active services and not expect it to get rooted within a few minutes or hours of going live. The same can not be said for most Linux distributions — regardless of what kind of additional access controls have been deployed. That is not to say that these operating systems can not be deployed securely but they do take some additional time to harden than what one might expect from an OS like OpenBSD, Hardened OpenSolaris, or other systems that make an effort to lock things down by default. Besides, it’s a poor workman that blames his tools.
I also see much ignorance displayed in the comment that sendmail and BIND being included in the OS are solid examples of OpenBSD’s insecurity. As core components of the OS these, too, undergo rigorous security audits. If you look through the list of the project’s security advisories then compare them with, for example, BIND’s own list of advisories, you will find comparatively few issues are actually issues with the OS itself. And in the cases where it’s an application advisory like BIND, sendmail, Apache, etc. — you’ll also find that OpenBSD’s implementations of these services have far fewer problems that their parent projects own releases.
I also take issue with the comment that BIND is an insecure name service application. If that were true, why are ten of the thirteen root servers still using BIND? The other 3 are using NSD but don’t you think that if BIND were as insecure as you suggest that their maintainers would trust it to run on a root server? In fact, most of the contributors to BIND actually have a hand in _running_ the root servers and see more hijinks on their systems in a day than you or I will probably see in our combined lifetimes.
I’m also curious what you mean when you say that “many server processes still running as a privileged user … is a large concern.” Have you actually installed OpenBSD? init and sshd are the only processes that run as root — everything else has its own unprivileged user. Though you might be of the opinion that not using additional access controls leaves OpenBSD “inherently more vulnerable in the event of a successful intrusion,” that’s just not the case in actual practice. Have a look at OpenBSD’s list of exploits — remote or otherwise — and compare them to any other OS’s security advisories. You will find that OpenBSD stands out from the crowd.
Before you go frothing at the mouth falling over backwards about how secure something is or isn’t, I would strongly advise that you back up your statements with actual research, facts, and experience.
Comment by Gary D — January 21, 2010 @ 4:21 pm
> The idea behind “secure by default” is that you can deploy an OpenBSD system in to the wild as an exposed server with active services and not expect it to get rooted within a few minutes or hours of going live.
No. No that’s not what it means. It means that if you DON’T install anything or activate anything that not activated by the base system, then it’s secure.
So basically if you don’t intend to use the system for anything then it’s secure.
So… why is the system even turned on? A windows 95 machine that is turned off is more secure than an OpenBSD machine that’s turned on.
As soon as you install wordpress the machine will get owned. And without proper ACLs you have just exposed way way way more than you should.
Comment by Bob — May 25, 2010 @ 4:47 pm
Wait a minute… You’re saying that if I install WordPress on an OpenBSD machine, that OpenBSD machine will get owned? How can that be if apache is chrooted in a read only environment? Can you back your statement up with facts other than the person who installed WordPress and got his box rooted is a moron and turned off security features as a quick-fix rather than reading the man pages and learning how to set it up right?
A system is only as secure as the admin makes it. That includes OpenBSD. I’ve used OpenBSD as firewalls, routers, web servers, mail servers, intrusion detection, and have even used it on my laptop for a time. If you think for one minute that I would be more secure with (for gits and shiggles) windows, you’re out of your damn mind.
Furthermore, using things like SELinux is a great idea, and I have nothing against adding another layer of security… I use it on my Linux servers as well as my desktop… But the bottom line is simply this… If the admin does his job correctly (hello!), then afterthoughts like SELinux is not necessary.
Learning the environment you are working in is imperative, regardless of what environment that may be. If you don’t learn it, you’re bound to screw up.
Get a clue and read the manuals. Don’t assume that OpenBSD is set up the same way that the other BSDs are, and don’t assume that OpenBSD should be set up like Linux. If you do, you’re in for a long and disappointing ride.
Comment by Mike — August 7, 2011 @ 3:22 am
Just because the admin is doing his job doesn’t mean that SELinux isn’t needed. The admin can secure an FTP sever all he likes, but if a remote security vulnerability is found, but not reported, and exposed, count yourself hosed. Things like SELinux can stop the attack in its tracks.
Comment by Aaron Toponce — August 7, 2011 @ 12:21 pm
Mike, the version of Apache OpenBSD includes is fairly ancient at this point. What if you need a later version for some reason, that isn’t audited? Or, what if there is a vulnerability in the OpenBSD version of httpd? My point is that OpenBSD takes the approach of trying to eliminate all vulnerabilities and offers very little to protect the system if and when a vulnerability is successfully exploited.
Things like SELinux are pretty far from an afterthought. You say you use such systems, but I would suggest you actually get familiar with them (if you were you would understand they are not afterthoughts) and then you can see why the functionality should be offered as a matter of course.
Also, security is a lot more than just fixing vulnerabilities. Something the OpenBSD team seem to limit their definition to.
Don’t assume I’m not familiar with OpenBSD. I am — it’s why I’m able to criticize it so thoroughly.
Comment by allthatiswrong — August 7, 2011 @ 3:06 pm
So u disagree that prevention is the best cure? People around the globe have had a local synonymous phrase [US-An ounce of prevention = a pound of cure] many hundreds of years [Its as old as Latin]. It holds true across fields like medicine, economics, education, or even in ur kitchen so yeah Im glad u said “Also, security is a lot more than just fixing vulnerabilities. Something the OpenBSD team seem to limit their definition to”
Because this’s my preferred definition. Dealing with a problem sucks if u can just avoid it.
*Im simply researching this software as an option supplying solution to deal with an jackoff neighbor who keeps hackin our wireless hub’s “secure” password and dedicating bandwidth. [a friend recommended Nessus in OpenBSD vs Ubuntu etc… more configs less open to retribution he said; my ISP’s been less than helpful] but anyway; I almost scraped the plan based on this essay as u do seem technically knowledgeable on the subject even when i’d understood OpenBSD protocol/code to provide a basis for many aspects Apple, Win, Linux. security ie firewall or network interface but i was almost convinced and ready to backtrack…
Thanks especially to the people and the cogent replies they posted [Also to the Author’s thoroughness; right or wrong a lot of interesting reading for me looks to come out of it]
Comment by justa-x1 — November 1, 2012 @ 8:12 am
It’s a noble cause to try and eliminate bugs in the first place, but it is foolhardy and arrogant to have no contingency plan.
Comment by allthatiswrong — December 11, 2012 @ 5:05 am
have you heard about the Titanic!? The UNSINKABLE Ship! 😛 had very few lifeboats… because they said it would never sink!
Comment by Adam — July 21, 2015 @ 1:43 am
Dan Bernstein’s projects were removed from the OpenBSD ports repository almost 10 years ago due to a licensing dispute over its redistribution; http://archives.neohapsis.com/archives/openbsd/2001-08/thread.html#2543. However, like any other application available as source code, that doesn’t prevent you from installing qmail or djbdns from source if you want to run it on OpenBSD.
Comment by Gary D — January 21, 2010 @ 4:36 pm
@Warner – Thanks for your reply! not sure how I missed the mistake of referring to strlcpy/cat as system calls, but that how now been fixed.
My main argument was for the need of MAC, and the OpenBSD’s teams resistance to include it. As for arguments against strlcpy/cat, I felt good points and examples were made in the various threads I linked to. I have nothing more than that, as I have not looked into it further.
@Piranha – I understand the versions of Sendmail and BIND etc included have apparently been audited, however as I mentioned in the article, many of the vulnerabilities of OpenBSD can still be attributed to these pieces of software.
Why not choose software which was designed to be secure, and audit that to make sure?
I am aware of the licensing dispute between Bernstein’s software and OpenBSD, but don’t consider this relevant. Qmail was not the best example to use, (which I will remedy), but the point still stands. Why not use software designed to be secure, instead of auditing known insecure software?
I am aware that Sendmail listens to only localhost by default, but this doesn’t help if someone wants to use OpenBSD as a mailserver using the provided sendmail beliving it to be secure, and it then gets hacked.
I didn’t mention the side projects the OpenBSD team has created, because while impressive they are not relevant to an article on the security of the OpenBSD operating system.
@Gary – I understand the significance of secure by default. Indeed, in the article I state that it is a good practice. My point was that the OpenBSD track record based on the secure by default configuration should not be used to gauge the security of OpenBSD.
Unfortunately I felt that was necessary to say, as I have encountered far too many people who do just that.
You make many of the same points as Piranha. I understand that the OpenBSD versions of BIND and Sendmail are audited, but this hasn’t removed many of the vulnerabilities, as can be seen by the errata pages.
Why not choose software which was designed to be secure, and audit that to make sure?
Are you really going to say that BIND is not insecure? It has an atrocious history. I would assume this is not as much as issue for the root nameservers as they are monitored constantly, and have a chance to patch before most other people.
It doesn’t add anything to the argument that there are far more secure alternatives available.
I have installed OpenBSD and used it. When I say many processes still run as a privileged user, this was not specific to software that ships with OpenBSD. In general, for server software that people may want to install much still runs as privileged code.
I also don’t know how you can be of the opinion that OpenBSD is NOT more vulnerable in the case of a successful intrusion. OpenBSD’s entire approach is based on trying to make exploits near to impossible, not on restricting access in the case of a successful attack.
I tried to make this point in my article, but apparently it evaded you, or you chose to ignore it. There are plenty of examples where using a form of MAC, an attacker would be unable to do anything, while on OpenBSD they would be at the most inconvenienced.
If you would like me to elaborate on anything or provide further references for a claim I have made, please let me know. Otherwise, perhaps you could actually provide an argument, instead of dismissing mine.
Comment by allthatiswrong — January 21, 2010 @ 5:33 pm
I’m a system admin of around 100 Unix and Linux machines at work. Formerly, I was a trainer for system admins all over the world.
RBAC, MAC and other increased security controls are more than just knobs to turn knobs. I can give you a dozen examples, where buffer overflows, privelege escalation, and other attack vectors succeeded on systems not taking advantage of MAC, but stopped dead cold with MAC enabled. The reality is, MAC enables tight, fine-grained security control that otherwise isn’t available.
In terms of OpenBSD, it’s really not a solid operating system for system administrators. It might work great as a network router, or firewall, but it’s missing far too many tools to be of any significant use to serious admins. For example, there is no supported automated installation method. There is no volume management similar to LVM. The installer is highly lack-lustre, making it difficult for admins to rescue systems.
I’ve run, configured and administered OpenBSD systems, and it was always a chore. I also agree with the comment about “secure by default” when nothing is installed on the system. Once a single package goes down that binds to a front door port, it’s no more secure than any other system running that same service. Unless that system is running MAC. That’s the cold hard reality. OpenBSD doesn’t have FreeBSD jails, MAC, or any other method of hardening the system.
Comment by Aaron — January 21, 2010 @ 7:27 pm
Well, I can see where you are coming from, but you completely ignore the concept of “simple code is easier to maintain, audit, etc…” which basically leads to higher security.
You say that only writing bug-free code is not the way to make a system more secure…
Don’t you think something is fundamentally flawed, too, in saying “we might have an insecure Linux, but instead of fixing it, we put another shitload of code on top of it, and call it SELinux, of course the added extra code is 100%-bug free… sort of”.
But as I said – I see where you are coming from, there is some truth is somewhere in between…
@ Aaron: without wanting to bash you, but… I don’t know how technical you are, but the OpenBSD installer is a 100% what I would expect from a decent installer – you decide exactly what you want to have configures, it takes 5 minutes to have a fully running system, and well… it makes you aware of your settings instead of having a “default” button installing all sorts of convenience-crap.
Comment by Tassilo — January 21, 2010 @ 7:57 pm
Who said anything about a default button? What am I looking for in an installer as a system admin?
* The ability to do automated installs.
* Have the flexibility to install from multiple sources (PXE, CDROM, hard drive, USB, floppy).
* Have the flexibility to install from multiple locations (NFS, HTTP, FTP, CDROM, ISO, SMB).
* Have a rescue environment should booting not complete.
* Have the flexibility to manipulate the install outside of the installer through a shell.
* Complete partitioning tool (partitions, volumes, filesystems, encryption).
* Total control of exactly what packages are installed.
* Verbose logging of the installer, kernel and user actions.
* The ability to do remote installs through VNC or SSH.
That’s just to start. The installer should provide an environment for the administrator that gives them complete control over the installation and configuration of the new or running operating system.
I don’t know of a BSD installation method that provides this level of flexibility and control. I only am aware of openSUSE, Debian/Ubuntu and Fedora/RHEL/CentOS that provide this level of flexibility. The rest of the installers I’ve had to deal with just install, with little else.
So, do you still want to bash me?
Comment by Aaron — January 21, 2010 @ 9:47 pm
“The rest of the installers I’ve had to deal with just install, with little else.”
I’ve worked with some stupid NT AND UNIX admins, and that’s gotta be the stupidest thing I’ve heard. You’ve apparently misunderstood the only purpose of an installer, while at the same time displayed a complete lack of any core UNIX principles. Good job…I smell a management position for you somewhere down the line.
Comment by paul — January 21, 2010 @ 10:51 pm
Well, …
* drop to shell and run a script
* you can for every part of the base install from where it should get the sources
* every single package might come from another location
* drops to shell automatically in that case (besides that, if you waste the “whole 5 minutes” you’ll ever spent on an install, I’d much rather reinstall and still have the system ready quicker than any Linux distribution)
* don’t know exactly what you mean, but how about just modifying just logging on and change the your dotfiles and /etc? I mean, it’s not 5000+ files the install generates, and you get full flexibility
* BSDs don’t have that many supported filesystems, the rest is fully there
* totally there, even more control than what other systems, because less gets installed by default – hell, the installer even lets you decide if you want to have ‘base’ installed at all
* boot> set tty com0 (or wherever you want to log it to), dmesg, /var/log, etc. – that’s not only verbose, but “full”
* http://www.daemonforums.org/showthread.php?t=526
Well, I wasn’t and I am not out for blood, excuse my inital wording. If all this is not convenient enough, there are alternative BSD installers out there – e.g. for OpenBSD you have YAIFO.
Comment by Tassilo — January 22, 2010 @ 1:13 am
For more notes about how to automate, or just have your own installer catered to whatever you want to do, without any limitation, look up release(8)
Comment by Tassilo — January 22, 2010 @ 1:40 am
@paul- you clearly have no idea what you’re talking about. rather than making yourself look more foolish, you might want to be familiar with the technology of an installer, rather than making half-baked random comments.
@Tassilo- My main point is not whether or not OpenBSD or any of the others have these technologies. My point is, I don’t want a default button. I want 100%, fine grained control over the installation. If I’m going to put down an operating system, trust my users to the data, and hope to keep some sanity during my administration, I had better have complete control, as well as an escape path, with the installer.
I know you can PXE boot an OpenBSD installer, boot from CDROM and from USB/Floppy. That’s good, but can I tell the OpenBSD installer that my software is on NFS, SMB, FTP, HTTP or some other location? What about rescue environments? Does the OpenBSD installer provide an ability to rescue my installation, should something horrible happen? I honestly don’t know. I haven’t dug deep enough into the installer to find out. It’s good to know that I can do remote installs, however.
Anyway, I’ve labored the point long enough. Operating system providers should give the system administrators all the tools necessary to install, configure and administer their system. From my experience with the three main BSDs, many of the tools I’m used to using, like LVM, simply don’t exist for BSD. I wish they were. BSD is a clean OS, and I like many of the philosophy choices that have been made, such as the BSD init, and /usr/local. I just wish there was more.
Comment by Aaron — January 22, 2010 @ 4:58 pm
NetBSD does have LVM. http://blog.netbsd.org/tnf/entry/netbsd_lvm_enabled_by_default
Comment by Hugo — January 26, 2010 @ 6:36 am
This is very new, like 2 months new. Good to see it in at least NetBSD. FreeBSD has vinum and ZFS, but what about OpenBSD? ccd is NOT a volume manager, before anyone here says that it is.
Comment by Aaron Toponce — January 26, 2010 @ 8:04 am
@Aaron – well, then we are in the same boat. I didn’t want to have a default button, either. Yesterday, I had to install Win7 Ultimate at work, and I couldn’t even chose neither the installation path nor the time zone, anymore. Heuristically, it set the time zone to Pacific Time, which was wrong – mine is Central.
I mean, IMHO, all your requested features exist with the OpenBSD installer and/or is doable via dropping to the shell, etc. You can drop to the shell at anytime, and if something horrible happens, you are in single user mode and have a shell.
I mean, you are completely free to use whatever you want to achieve your goal – I don’t see where you can get more flexibility.
Anyways, your point about LVM is valid – however, you have ccd(4), which comes close for the majority of the tasks people try to accomplish with LVM.
Comment by Tassilo — January 23, 2010 @ 10:48 am
@Tassilo – I completely agree that simple code is easier to maintain, and that code should be well maintained and audited.
But that has to go hand in hand with being able to protect against the damage an attacker can cause if successful in breaking in.
Given a system that provides a strong way to do that, which extended access controls do, then buggy code is less of a concern.
Comment by allthatiswrong — January 21, 2010 @ 8:18 pm
Like I said, the truth is somewhere in between. More access control doesn’t lead to anything, unfortunately, if the ac code is buggy itself… (I’m not implying that SELinux is buggy, etc.). Personally I think it might be even worse. You have more “critical” code to maintain, and SELinux, etc. is not that picky about audits and code quality as OpenBSD is.
Comment by Tassilo — January 22, 2010 @ 1:17 am
It’s nice that you mentioned many security frameworks like RSBAC which don’t get a lot of light these days, yet are very good
Comment by name — January 21, 2010 @ 8:24 pm
[…] — Tags: tweets — admin @ 6:52 pm January 21, 2010 The insecurity of OpenBSD RD: @olhe: https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ #openbsd #bsd #foss #os Comments […]
Pingback by Mis tweets | casidiablo.net » The insecurity of OpenBSD RD: … — January 21, 2010 @ 8:39 pm
On the whole, I agree with this article. I’ve been an OpenBSD user for the majority of the last 10 years, and I’ve grown to understand that it’s secret purpose isn’t so much to be an every day machine or even really a server, but a firewall or gateway machine for VPNs. The default install comes nearly ideally suited for being a firewall: it has possibly the most flexible and capable firewall service devised (pf), and that *IS* installed and enabled by default because it designed by the OpenBSD team for OpenBSD. That firewall can be easily configured to defend any number of systems behind it, offer a wide range of nat and port forwarding options, and even do MAC address based filtering.
Use it as your gateway and/or firewall, and you’re fine. Not many user accounts are necessary, it requires a strong password for accounts (it complains and generally prevents you from using weak ones), and by default, the root user can only log in from the console (the keyboard and monitor attached to the machine).
OpenBSD is *NOT* ready to be an everyday use sort of operating system. Getting X up and running is fairly simple, but getting GNOME or KDE up and running is a chore, and making them look like what’s now a default install on any Linux flavor is taxing to say the least. And as mentioned, a lot of the ports are several years old, and you sometimes need to have a good grasp of programming skills or at least compiling software to get a lot of other programs (especially newer releases) to run on it.
So in summary, whether OpenBSD is secure enough for you really depends on your intended use. If you intend to use it as a firewall in front of your various servers, it’s going to be more than secure enough for you. If you intend it to be your server, it’s a good start, but not necessarily the most secure thing on the market. Desktop replacement? Forget about it.
Comment by Raymond — January 21, 2010 @ 9:56 pm
You miss the point. OpenBSD was never designed for casual users. It was designed for higher end users, users who want certain things from their machines.
Besides, you can’t deny the short turnaround for certain tasks. I put my OpenBSD CD in, and within 10 minutes, I have a computer routing packets between my wired network and a wireless router, and all I had to change was one line in a file. The same sort of thing enables the web server, and with a few more commands, that web server has PHP. Try that with any other OS.
Comment by thirdwheel — January 21, 2010 @ 10:38 pm
“OpenBSD is *NOT* ready to be an everyday use sort of operating system. Getting X up and running is fairly simple…”
uhhh yeah: startx
but getting GNOME or KDE up and running is a chore, and making them look like what’s now a default install on any Linux flavor is taxing to say the least.”
uhum: cd /usr/ports/x11/gnome && make install ( to compile from source, better off setting make prefetch and letting this “taxing” os fetch and install all the dependencies for you)
Comment by paul — January 21, 2010 @ 10:58 pm
Could you cite a better source for strl{cpy,cat}’s drawbacks than a Redhat rep calling it “inefficient BSD crap” please? You present no evidence to support this claim and neither did your source.
Comment by thirdwheel — January 21, 2010 @ 10:33 pm
Oops, I missed the part about strlcpy returning the same length even if it got truncated.
One thing they didn’t mention was that strncpy only NUL terminates strings if the length of the input string is less than that specified of the buffer it goes into. That’s a problem.
If log entries and important strings are getting truncated, then that’s a problem with the program, not the function. A poor builder blames his tools.
Comment by thirdwheel — January 21, 2010 @ 10:58 pm
@thirdwheel, strl* are _supposed_ to return the length of the string they tried to create precisely to make it easy to detect overflow. Their idiomatic usage is:
if (strlcpy(dst, src, sizeof(dst)) >= sizeof(dst))
overflow();
The fact that every modern operating system had adopted these function (including the Linux kernel) is evidence that they are useful.
Comment by djm — February 24, 2010 @ 2:25 pm
> I also don’t know how you can be of the opinion that OpenBSD is NOT more vulnerable in the case of a successful intrusion. OpenBSD’s entire approach is based on trying to make exploits near to impossible, not on restricting access in the case of a successful attack.
In my book, avoiding the exploit in the first place is a lot better than relying on Access Control mechanisms. An attacker with arbitrary code execution can still do a lot of damage from within the restrictions and even bypass them given enough time and target complexity.
You may have a point or two, I think POSIX permissions and user separation are crap too, but other systems are not more secure than OpenBSD as by default they are forgiving to exploit vectors that OpenBSD defused years ago. If the code isn’t there in the first place, it can’t harm anything.
Comment by youarewrong — January 21, 2010 @ 10:50 pm
“OpenBSD’s entire approach is based on trying to make exploits near to impossible, not on restricting access in the case of a successful attack.”
There are several things wrong with this statement.
First, define successful attack. A lot of work has gone into OpenBSD to provide chroot’d and privilege separated environments to default services. A successful attack on one of these services does not breach containment without the need for further local attacks that provide some kind of privilege escalation. Attackers who even get to this point are further deterred by mitigation techniques like W^X or the other methods built into OpenBSD by default. If OpenBSD only cared about blocking attacks from happening and not what happens after, then none of these things would have been implemented.
MAC doesn’t necessarily protect you here when you define attack as gaining successful root access. In a more recent vunerability on Linux, bugs in SELinux actually made an exploit possible where as if SELinux was disabled it would not have been (this is where code complexity hits you in the face). Furthermore, this bug led to Linux being more vunerable to an entire class of bugs. Also, there have been several examples disclosed with exploits on how to disable SELinux as it is a kernel module (search google for mmap_min_addr). Linux even more recently brought back the ping of death. Good stuff.
So, where does MAC save you here? http://security.freebsd.org/advisories/FreeBSD-SA-09:16.rtld.asc
Where is the magic incantation (policy) to save your FreeBSD box from that?
Don’t get me wrong. I think MAC can be useful. Given the amount of unaudited code changes that happen in linux daily, it needs something to cover it’s ass. Ever hear the NSA talks about SELinux? It exists because there are LOTS of bugs in the Linux kernel.
OpenBSD does not follow the Linux development model. Criticizing it for focusing on squashing bugs rather than containing them is ridiculous. It’s an entirely different world. It’s not to say bugs won’t happen, but there are far fewer.
Comment by Daniel — January 22, 2010 @ 12:01 am
Hi Daniel
I define a successful attack as gaining access to an account. This does not have to be a root account, a user account would be sufficient to steal or destroy information, or attempt to get root.
I feel that you contradict yourself. You highlight protections that are designed to mitigate attacks as proof that OpenBSD does not only care about mitigating attacks.
I agree that it is harder to attack an OpenBSD box, but once someone does, perhaps exploiting a hole in 3rd party software such as say, mysql, then OpenBSD doesn’t help at all.
This is not the case with a system using MAC.
I also believe you are mistaken when you say there were bugs that allowed SELinux to be disabled. This was a problem with the policy, not a shortcomming or vulnerability in the framework itself. Otherwise, could you provide a link to support your claim?
For the vulnerability you posted, there is actually a hell of a lot you could do to curtail what is possible. Keeping in mind I don’t actually think it is a good example of a serious exploit, you could as an extreme measure prevent the root account from executing anything not explicitly whitelisted.
I certainly have never criticized OpenBSD for not following the Linux development model. I criticize them for continually rejecting a powerful method of providing real security to their operating system, as dismissing it simply as security theater or being too complex.
Comment by allthatiswrong — January 22, 2010 @ 1:16 am
“I define a successful attack as gaining access to an account. This does not have to be a root account, a user account would be sufficient to steal or destroy information, or attempt to get root.”
Here is where OpenBSD differs from Linux again. It is *much* harder to get root than on linux once you’ve gained access to that system.
“I feel that you contradict yourself. You highlight protections that are designed to mitigate attacks as proof that OpenBSD does not only care about mitigating attacks.”
In a way, yes. Take OpenNTPD for example. It’s privilege separated and isolated into it’s own empty directory. If you breach OpenNTPD and gain access, what are you able to do? There is no shell. You do not have privileged access. You’re the _ntpd user locked in an empty directory. Access is contained, just like you want to do with an effective MAC system. Now, an attacker can continue to try and break containment, but that’s where the other local exploit mitigation techniques kick in. The same is true of a system that deploys a MAC system. The attacker will continue to try and break confinement. For SELinux, it usually means attacking it’s modular nature and trying to disable it. The systems you’ve mentioned do not provide any protection against that. They rely completely on the MAC to be sane, infallible, and working as expected. Linux w/ PaX provides much of the same protection, but that is not the default on many distributions and they will offer no support if your favorite application breaks. OpenBSD just works. There is no need to disable any of the protection to make an app work.
“I agree that it is harder to attack an OpenBSD box, but once someone does, perhaps exploiting a hole in 3rd party software such as say, mysql, then OpenBSD doesn’t help at all.”
What part of OpenBSD does not help? 3rd party software is not exempt from OpenBSD’s exploit mitigation techniques. Despite the weaknesses in systrace, it can also help here. What you’re failing to notice here is that rather than a bug in MySQL resulting in unauthorized remote access or privilege escalation on other systems, it’s more likely just a DoS on OpenBSD much in the same way it would be simply a DoS on Linux w/ PaX.
“I also believe you are mistaken when you say there were bugs that allowed SELinux to be disabled”
I told you what to search for. If you’re a linux user or even in the security field, then there is no way that you missed that. It wasn’t quietly covered up. Furthermore, having SELinux on is what made the bug exploitable. The system was more vunerable due to it. Look up Brad Spengler or GrSecurity. They’ve even mentioned it.
“This was a problem with the policy, not a shortcomming or vulnerability in the framework itself.”
You’ve already criticized systrace for shortcomings in systrace policies allowing for reduced protection and you’re somehow excusing MAC systems here. Also, the bug I’m referring to DISABLES all of your MAC policies. I don’t know how you missed it.
“I criticize them for continually rejecting a powerful method of providing real security to their operating system,”
No one has actually presented one. Where is the code? Point to it in the mailing list archives. Nada. There is nothing. Porting TrustedBSD is non-trivial. I also do not see anyone stepping up to make that port happen.
Comment by Daniel — January 22, 2010 @ 9:37 am
> It is *much* harder to get root than on linux once you’ve gained access to that system.
Who cares? Bob already has access to the company secrets (he’s in the tech group, and the marketing group) and you’ve compromised his browser.
Now the question is “why can the *browser* access company secrets? It should only be able to surf the internets, save to download directory and read/write its settings/cache directories”.
Hint: the answer is NOT “The browser should have been audited, sucks to be you”.
Comment by Bob — May 25, 2010 @ 5:04 pm
Whoever said this was 100 % correct:
In my book, avoiding the exploit in the first place is a lot better than relying on Access Control mechanisms. An attacker with arbitrary code execution can still do a lot of damage from within the restrictions and even bypass them given enough time and target complexity.
If an intruder was able to break into a system, there is no other solution than to analyze the break and reinstall the system. People who trust ACLs/MACs in such cases are dangerous themselves.
Comment by foobar — January 22, 2010 @ 3:30 pm
This is 100% incorrect.
A proper EACL implementation will be formally verified. This means that practically, they will not simply be able to be bypassed, irrelivant to how much time an attacker has, how how complex the implementation may be.
It is also not true that an attacker could do a lot of damage when restricted by MAC. If set up correctly, an attacker will have next to no power at all, despite having successfully exploited various bugs.
Of course, I am open to examples or scenarios that may show otherwise.
Comment by allthatiswrong — January 22, 2010 @ 4:32 pm
> If an intruder was able to break into a system, there is no other solution than to analyze the break and reinstall the system.
Yes, and when the military notices that someone got into a part of the lobby where they weren’t supposed to be (and there is no gate beyond the lobby gate. It’s a strong gate but still) they burn down the whole base and rebuild it.
Spot on. *clap clap clap*
You do see the point of dividing networks into zones, right? Or when someone has a LAN account can they log into any router and do anything?
Comment by Bob — May 25, 2010 @ 5:09 pm
I know it’s been said before, but you repeat yourself, over and over, repeating; did I mention you repeat yourself?
I spent 7 minutes wondering when you’ll get to the point.
What you’re suggesting is practically non-existent in the “real world” and highly unrealistic :-). You sound young, but ambitious (keep this quality of yours in mind, we’ll come back to it).
You honestly believe an average organization’s sysadmin group has the time available to implement any form of MAC on their UNIX servers? Really? Honestly? I haven’t seen any form of it used anywhere to tell you the truth. I’ve seen a lot of UNIX boxes over the last 10 years 😉 and none of them with anything resembling MAC turned on, ever. Wait, I believe once someone turned SELinux on, only to turn it off an hour later.
Comment by paul — January 21, 2010 @ 11:14 pm
…and now the ambitious part.
I’m not sure if others reading this have picked up on the very subtle undertone of your article. Admit it, you want extensive access controls in OpenBSD, and you want it now. Very very very clever. This is the most elaborate “feature request” I’ve seen put together.
Unfortunately, it also seems you’ve missed the OpenBSD mantra “shut up and hack” aka “put up or shut up”. Not going to be that easy, you’re going to have to write some code. I look forward to tracking your progress in the OpenBSD tree soon.
Comment by paul — January 21, 2010 @ 11:19 pm
> I know it’s been said before, but you repeat yourself, over and over, repeating; did I mention you repeat yourself?
And yet the comments are full of people who were just plainly unable to read what he kept repeating.
Comment by Bob — May 25, 2010 @ 5:10 pm
@thirdwheel – I don’t have further sources than various threads where strlcpy/cat are discussed. I never meant to link to Dreppers original message, bur rather the start of the thread.
I agree with the basic argument however, which is to say forcibly null terminating every string is not the best approach and can in itself cause problems. The best approach is to check what you are doing, thus making the use of strlcpy/cat unnecessary.
@paul – I am not a professional writer, and I am sure that I could refine my article a lot better. I think I get the point across however, which is what is important.
Based on the claims you make and your assumptions, I have to guess that you don’t have much real world experience. Some form of MAC, or *at least* an ACL is quite common, if not required in high security environments.
Do you really think it is purely a hobbyist technology?
I also have no ambition about wanting extended access controls in OpenBSD. I think if OpenBSD included them it would be a lot better for it, but since the developers continually completely reject even the notion, I prefer to use operating systems I can actually trust to be secure.
Comment by allthatiswrong — January 21, 2010 @ 11:54 pm
“Do you really think it is purely a hobbyist technology?”
Of course not. However, not having it does not make OpenBSD any less secure. Which bugs on OpenBSD’s errata pages would not be bugs thanks to some form of MAC? When you’re referring to 3rd party software like BIND/sendmail/Apache, default installs of Linux distributions or FreeBSD were not any more secure than OpenBSD thanks to having some sort of MAC.
“but since the developers continually completely reject even the notion”
Notions get rejected a lot because there is no code to follow up on those notions. If someone presented good, clean, and working code that didn’t radically change the expected behavior of traditional POSIX system calls, or introduce a huge mess of complexity or bugs into the OpenBSD kernel, I’m sure they would seriously look at it. Notions, however, are not serious.
“I agree with the basic argument however, which is to say forcibly null terminating every string is not the best approach and can in itself cause problems. The best approach is to check what you are doing, thus making the use of strlcpy/cat unnecessary.”
strlpcy/cat would not have been made if programmers would check what they are doing in the first place. Sometimes it can be non-trivial. Also, how does string truncation make OpenBSD less secure of an OS? Looks like you found some rants on OpenBSD and regurgitated it.
Comment by Daniel — January 22, 2010 @ 12:18 am
Better yet, go here http://marc.info/ , search the mailing list archives and point out strlcpy/cat causing any breakage or security holes, or even any MAC code the developers rejected. FUD. Pure and simple.
Comment by Daniel — January 22, 2010 @ 12:32 am
Hi Daniel, thanks for your comments.
I would say that most of the vulnerabilities listed on OpenBSD’s errata pages would be less damaging with some sort of MAC.
Of course they would still be bugs, and still able to be exploited, but the important thing is no damage would be done.
What good is a root shell if you absolutely cannot read, write or execute anything?
You say notions get rejected alot because there is no code to back them up, however this is not entirely true in this case. If the OpenBSD team wanted, they could make use of the TrustedBSD project, as I point out in my argument. Or even something like RSBAC which is clean and simple, and designed to be portable.
Comment by allthatiswrong — January 22, 2010 @ 1:06 am
The vulnerabilities may well be less damaging with MAC, but MAC is not without its costs. Most MAC policies shipped with Linux are either extremely permissive, or need to be disabled at the first deviation of their target’s configuration from that the MAC policy was developed for.
The OpenBSD team has decided not to pursue MAC and put their energies instead into exploit mitigation (providing the first complete OS that shipped W^X, gcc stack protection and some ASLR), securing userland (e.g. writing secure routing daemons, a new smtpd, improving OpenSSH, etc.) That doesn’t make the OS “insecure”, despite what you would like to believe, it is just a different approach.
Comment by djm — February 24, 2010 @ 2:42 pm
MAC is not the only type of EACL. They could use any number of simpler models such as those available in RSBAC, AppArmor, SMACK etc.
OpenBSD *is* insecure in far too many situations because it relies on simple DAC. A very simple example of where OpenBSD is insufficient is in the example provided by Robert above.
It is not just a different approach, it is an irrational rejection of a powerful technology due to a lack of understanding.
Comment by allthatiswrong — February 24, 2010 @ 3:21 pm
“What good is a root shell if you absolutely cannot read, write or execute anything?”
Is this not what OpenBSD does with it’s privilege separated and chroot’d daemons? In fact, you do not get a root shell even.
I’m not dismissing MAC as useful for sandboxing applications. Just be aware that it’s not the only method.
“If the OpenBSD team wanted, they could make use of the TrustedBSD project, as I point out in my argument. ”
Sure, if they wanted. Motivation is the key. It’s non-trivial to port it. It would take a lot of work. It’s not limited to OpenBSD developers. You want it, spend your time or money getting it.
Comment by Daniel — January 22, 2010 @ 9:44 am
I’ve only been a full time UNIX systems administrator for 6 years, and before that a measly applications admin running on UNIX for 6 years. Does that qualify as “much real world experience”???
I’ve administered a UNIX environment of about 4000 boxes in my prior job. No ACLS, no MAC anywhere. Currently administering environment of about 400 servers and 400 workstations (all UNIX), no MAC anywhere (ok ok, we’ve got one application group using ACL’s on Solaris as a hack, because they couldn’t figure out a good way to lock down their web app logins).
So now you know how much experience I have. How much experience do you have administering UNIX systems, and what do you currently do?
“Do you really think it is purely a hobbyist technology?”
I never mentioned anything about it being a hobbyist technology…I said it’s not implemented in the 99.9999% of UNIX servers I’ve seen.
“I prefer to use operating systems I can actually trust to be secure.”
Uhhh, which operating systems do you prefer to use? Have you mentioned them? What do you use for a desktop/workstation?
Comment by paul — January 22, 2010 @ 9:08 am
Just something I wanted to point out – there’s so much more about security:
* great man pages telling you exactly where the config files are, etc. (and not like Debian’s, oh, we moved file x to y because we think it’s more intuitive there, but didn’t correct the man page)
* no feature creep (“evolution instead of revolution”), making the system predictable and less confusing after an update
* great release cycle with long testing phase and absolutely predictable releases which lets you prepare and plan your update instead of just rushing it
* prebuilt binaries using the exact same libraries, meaning less versioning issues, etc
* removal of unmaintained ports
* guaranteeing that every single port, driver, etc. is free and open giving you the possibility to modify/patch it on your own, if really needed
* own audited versions of popular software that follow the same principles (e.g. apache), by the same team, instead of feature-creep
* security-focused community helping you out quickly when it’s about security
* …
All this adds to a secure system, whithout being in the code itself…
Comment by Tassilo — January 22, 2010 @ 1:28 am
sorry, have to correct myself and exclude “port” from being always open (opera would be a counter example)
Comment by Tassilo — January 22, 2010 @ 1:33 am
A non exhaustive list on various security features introduced in OpenBSD, in the order
Feature, release, year, url relative to http://www.openbsd.org
Random PIDs 2.2 1997 (plus22.html)
Stack smash protection 3.3 2003 (plus33.html)
Randomize shared lib location 3.4 2003 (34.html)
Randomize heap 3.8 2005 (38.html)
I also must stress that these features were introduced in releases, enabled by default (often not possible to switch off) and require no configuration by the admin at all.
Your statement that OpenBSD waited with these features is plain wrong.
Comment by Otto Moerbek — January 22, 2010 @ 3:16 am
Ugh a typo in my name. Make that Moerbeek.
Comment by Otto Moerbeek — January 22, 2010 @ 3:18 am
“To start, we must clarify at a bare minimum what a secure operating system can be considered to be. Generally, this would be taken to mean an operating system that was designed with security in mind, and provides various methods and tools to implement security polices and limits on the system.”
You start off with a recursive definition of security. This is not good.
Comment by Chris — January 22, 2010 @ 3:26 am
So Linux will let 50% of the exploits in, in the first place and have the MAC stop 90% of the bad effects later, whereas OpenBSD code audits and secure design stops 90% of the exploits and the chroot/unix-perms only stop 50% after the break-in.
So lets pick on OpenBSD then for having a poor second-line defense.
Comment by Janne Johansson — January 22, 2010 @ 3:39 am
@Otto – It seems OpenBSD did implement PID randomization first in 1997. For the rest of the features you list, they were implemented previously in various places, such as the Openwall patch for Linux.
I am simply tired of people giving the OBSD team credit for inventing these protections, when this is not the case.
@Chris – I start of with a definition of a secure operating system, not security.
@Janne – Or, how about have OpenBSD stop none of the exploits targeting non audited code, and allowing much more damage to occur because of a lack of a strong second-line defense?
Comment by allthatiswrong — January 22, 2010 @ 4:50 am
You missed all his stressing.
People don’t give OpenBSD for inventing the features, but for actually implementing them. OpenBSD didn’t *invent* SSH but they provide the reference version.
Trusting MACs over code execution prevention is like trusting eating with a murderous convict that has only been allowed to use a plastic spoon over not eating with a convict in the first place.
Comment by apalau — January 22, 2010 @ 5:39 am
The main point is not that we did invent or not. The point is that we introduced these features not as an optional patch avaiable soewhere on the internet, but as an integral part of a release.
Comment by Otto Moerbeek — January 22, 2010 @ 7:37 am
A secure operating system must be written with security in mind. Yes, that’s much better.
“A foo operating system must be written with foo in mind.” Does that make it clear to you what I think a foo operating system, or foo, happens to be?
Comment by Chris — January 23, 2010 @ 2:34 am
I think that is a false analogy. As I have said, I am defining a secure OS, not security.
A better analogy might be: To talk about matchbox cars, we must define what a matchbox car is. A matchbox car is a toy car, generally the size of a matchbox.
You see then, it is possible to define a matchbox car, without having to define matchbox, just as it is possible to define a secure operating system, without having to define security.
Comment by allthatiswrong — January 23, 2010 @ 4:52 am
You’re mixing up adjectives and nouns. (“foo” can not be used to represent both.)
Comment by Mr. Big — February 23, 2010 @ 9:18 pm
First off excellent article. 5 stars.
“The modified system calls strlcpy and strlcat should also be mentioned here. These system calls were developed by Todd Miller and Theo de Raadt as a way to eliminate buffer overflows by ensuring strings are always null terminated. However this approach is controversial, and can actually result in further problems and security vulnerabilities than they solve. While they may have their place, they should certainly not be relied on, and doing so shows a poor understanding of computer security.”
I’d like to know more about this statement. Making sure strings are NULL terminated definitely has solved a huge bunch of vulnerabilities.
Could you point me in the right direction to learn more about the problems to this approach? Because I’ve not seen any.
Thank you.
Comment by Ramshankar — January 22, 2010 @ 5:58 am
You can invent examples like strcpy() “rm -rf /my/temp/dir” to a 8-9 char destination and think that strlcpy() would turn this into “rm -rf /” which you (without checking) run as root and shoot yourself in the foot.
Comment by Janne Johansson — January 22, 2010 @ 6:52 am
But only if you missed the advice to actually check the return values.
Comment by Otto Moerbeek — January 22, 2010 @ 7:41 am
Well if you knew that then why didn’t you just use strncpy() correctly?
Yes yes, I know. strlcpy() is easier to use correctly. It’s unquestionably better. I think the author is saying they do have their own issues. Which they do. All string handling in C does. Indeed all user input handling anywhere does.
Comment by Bob — May 25, 2010 @ 5:21 pm
“Linux is evolution, not intelligent design.”
And for a long time that evolution rejected things like SELinux, but nowadays on things like new Fedora boxes there is very little reason to turn off SELinux.
So essentially an uptodate Linuxbox is way more secure than OpenBSD, because they provide a lot of profiles for potentially exploitable services.
Comment by Tim — January 22, 2010 @ 7:02 am
lol – that’s why linux has a couple of remote exploits in a single year, and openbsd had two in 12 years – yes, makes total sense your statement…
if you want facts, just look it up on vulnerability database sites like secunia.com
Comment by Broom — January 22, 2010 @ 9:29 am
Oh, but the author already dismissed facts like that in the original article.
The author spends too much time attacking OpenBSD for it’s differences than spending any effort actually trying to prove OpenBSD is insecure. That’s what they do in politics. Just attack with nonsense.
Comment by Daniel — January 22, 2010 @ 9:53 am
Don’t be stupid. You know “linux” doesn’t. You’re talking bullshit and you know it.
When I install Debian boxes the fresh install only has openssh listening.
What what? Does the portable OpenSSH have “a couple of remote exploits in [a year]”?
The problems start when you start installing applications. And OpenBSD is the same in this regard.
But Linux has better second level defense.
Comment by Bob — May 25, 2010 @ 5:24 pm
[…] aunque bastante largo el análisis que ha realizado el blog AllThatIsWrong sobre la seguridad en OpenBSD. Tradicionalmente se ha considerado que los sistemas BSD destacaban […]
Pingback by OpenBSD no es tan seguro | MuyLinux — January 22, 2010 @ 8:32 am
[…] dejo un enlace a un análisis que ha realizado el blog AllThatIsWrong sobre la seguridad en […]
Pingback by Linux-OS » OpenBSD no es tan seguro — January 22, 2010 @ 9:59 am
I remember when NetBSD was just a kernel and a compiler. If you wanted Apache installed, you had to compile the prerequisite libraries then the web server. The advantage of this approach was that you knew everything that was running on your system. When I install a bloated Linux distro now — even a JeOS version — I’ve no idea how much crap gets installed with it. I also don’t know what attempts have been made to secure it. Back in the Solaris 2.X days when I worked for a tier 1 bandwidth provider, we had a Jumpstart server with a minimal base set of packages, a script and/or checklist of post-install steps for shutting off unwanted services, and a few manual procedures for enabling software RAID 1. None of these systems were outside of a firewall but there were a small handful that were loaded with Checkpoint and became firewalls. Some of those servers — including most of the perimeter and HQ firewalls — are still in production ten to fifteen years later. Also, I’ve deployed plenty of OpenBSD perimeter firewalls in the last 10+ years and not a single one of them has been compromised.
When the trusted extensions for Solaris came out (v2.4 or .5?), we found that most of its procedures were already in place in our own in-house installations and we didn’t have need for the extra orange book security features. But several thousand man hours have been spent on the trusted extensions which is what makes it less of a bolt-on than something like SELinux on Fedora. My point is that any operating system can be secure if deployed properly — even Windows. For some examples of projects that take a more serious approach, have a look at Wikipedia’s entry for “Security-focused operating system.”
As for the comment that OpenBSD is largely geared toward deployment as a firewall/VPN box, that may have come about as a result of them being the first to write drivers for various crypto accelerator cards over the years and duplicating “proprietary” features usually found only in commercial firewalls. But that discounts the fact that several people — and orgs — use it as a secure desktop as well. Personally, I’ve never found much use for resource intensive window managers like E but it’s certainly possible to build them yourself if it’s not already available in ports. A friend of mine used to make Solaris packages of E and all its supporting libraries on a regular basis so whenever I hear someone complain about what a pain it is to configure GNOME or KDE I can’t help but laugh.
Over the years I’ve also seen OpenBSD and FreeBSD used as kiosks or secure workstations in University libraries and labs, book stores, and coffee shops. The same things can be done with Linux but most desktop distros want to install every open source game and office app possible by default so it takes some work to remove the cruft or roll your own base system. Again, no matter what OS you choose it can still be deployed securely regardless of whether you’re using access controls or not.
I’m seeing little evidence to back up the notion that every OS should meet Common Criteria or TCSEC requirements in order to be secure and that any OS that doesn’t is worthless. To reiterate my previous proverb, it’s a poor workman that blames his tools.
Comment by Gary D — January 22, 2010 @ 12:16 pm
@Daniel – “Is this not what OpenBSD does with it’s privilege separated and chroot’d daemons? In fact, you do not get a root shell even.”
No, this is not what OpenBSD does. First of all, anything in the chroot can be read and accessed(information leakage) or destroyed/defaced.
Also, chroot and privilege separation are nice ways to mitigate an attacker from getting to the rest of the system, as I argue MAC is, or at least can be.
“Take OpenNTPD for example. It’s privilege separated and isolated into it’s own empty directory. If you breach OpenNTPD and gain access, what are you able to do? There is no shell. You do not have privileged access. You’re the _ntpd user locked in an empty directory.”
For OpenNTPD, this is mostly true. Keep in mind though, a lack of a shell simply makes it harder to execute commands, not impossible. Also assuming there is no local privilege exploits that are possible, then yes, practically this is the same result as with strong MAC.
For something like Apache however, this is not the case.
“The attacker will continue to try and break confinement. For SELinux, it usually means attacking it’s modular nature and trying to disable it”
I have yet to see an actually vulnerability in these frameworks, that was not an error in policy.
“What you’re failing to notice here is that rather than a bug in MySQL resulting in unauthorized remote access or privilege escalation on other systems, it’s more likely just a DoS on OpenBSD much in the same way it would be simply a DoS on Linux w/ PaX.”
That may be true a lot of the time, and that is a good thing. In the event of a breakin however, all bets are off. You simply can’t equate a chroot environment to the level of security you can implement with MAC.
“I told you what to search for. If you’re a linux user or even in the security field, then there is no way that you missed that.”
Oh, I have looked it up, and followed it closely. It is also the only example anyone ever gives.
It was not a vulnerability in the framework at all, it was an error in policy, that was a deliberate(and stupid) choice.
See here: http://eparis.livejournal.com/606.html
With at least 4 mains security frameworks, all of them having been around for almost 10 years, you think there would be many more examples of vulnerabilities in these frameworks.
“You’ve already criticized systrace for shortcomings in systrace policies allowing for reduced protection and you’re somehow excusing MAC systems here.”
Systrace uses system call interposition which is known to be insecure. See the papers I linked to in my references. The extended access control systems are generally formally verified, and have no such inherent vulnerabilities.
“I also do not see anyone stepping up to make that port happen.”
Considering how they rejected systrace(not because it was insecure, but because they did not believe it improved security), if someone did port TrustedBSD it would be similarly rejected.
It is not an issue of not having code, but of rejecting the underlying idea and concept.
@Broom – You seem to have missed the point of what extended access controls can accomplish.
I would rather have a system with 10 remote exploits and strong MAC, than a system with 1 remote exploit and no MAC.
@Gary – Thanks for your reply.
You seem to be basically saying that OpenBSD is secure and fits well in areas it works well in, such as a router or firewall. I agree here, as I said at the end of my article.
What I don’t agree with however, is that OpenBSD is secure in the way that you can limit the damage done by untrustworthy software or users. Something that is true for every other secure operating system.
I certainly don’t mean to say that every OS must be CC certified to be considered secure, but they must provide a way to properly lock down and restrict the system to be considered secure. This is where OBSD falls short.
Also, I get tired of the argument that extended access control frameworks are “bolted on”. Many of the frameworks have been in development for close to 10 years, are tightly integrated into the kernel, and are not simply “bolted on”.
Comment by allthatiswrong — January 22, 2010 @ 1:55 pm
“No, this is not what OpenBSD does. First of all, anything in the chroot can be read and accessed(information leakage) or destroyed/defaced.
For OpenNTPD, this is mostly true. Keep in mind though, a lack of a shell simply makes it harder to execute commands, not impossible. Also assuming there is no local privilege exploits that are possible, then yes, practically this is the same result as with strong MAC.”
That’s why there is nothing in the chroot, like OpenNTPD does and the slew of other default daemons. Yes, pending any local exploits to gain extra privileges, the bugs are contained. Just like a MAC. Pending any bugs in the MAC implementation, bugs are contained. You’re blindly trusting the MAC and you’re missing that OpenBSD simply took a different approach. This is because in OpenBSD, local privilege escalation bugs are rare, unlike in Linux. Two different approaches to security for two very different development models.
“Oh, I have looked it up, and followed it closely. It is also the only example anyone ever gives.”
It’s the most recent example, so why not give it? Also, if it’s simply from a bad policy, then why was the kernel patched rather than provide a patch for the policy? Did you also notice the exploit disabled SELinux in it’s entirety? What policy mechanism is going to save you from that?
http://www.milw0rm.com/exploits/9191
The link you provided also states that SELinux is less effective against local malicious users, which is what you’re claiming is one of it’s strengths.
Have you even researched the criticisms of LSM or SELinux? There’s plenty out there, and more than just complaints about complicated policies. You don’t need links from me to show you. Look and develop your own opinions, though it seems you would rather simply stay ignorant in believing having a MAC system makes you infallible.
“Considering how they rejected systrace(not because it was insecure, but because they did not believe it improved security), if someone did port TrustedBSD it would be similarly rejected.”
systrace was not rejected. It’s in the base system. It’s also not considered a security feature. No one has presented TrustedBSD in a usable form to OpenBSD. They’re volunteers. If you want it, you do it. I don’t see anyone outright saying they’ll reject it before any work is even done to port it. You’re grasping at straws here.
Comment by Daniel — January 22, 2010 @ 2:24 pm
Would you buy a car, if the manufacturer tells you “well, a tire might fall off, every once in a while, but don’t worry, it has a steel frame it can slide on”…
You have a valid point, but really nobody guarantees you that this always protects you from damage in case of a successful attack. Your chances are just higher, compared to doing it right the first time with a correctly deployed OS. And sorry, when it’s about security, I don’t like to gamble and feel secure by looking at statistics.
I agree with Gary D, that a correctly deployed system is secure. Do you think another batch of config files and rules for each and every single application really helps in doing it _right_?
Apparently you like statistics, so it should be a no brainer to you, that there’s a higher chance having some misconfiguration, if you have more to configure.
Comment by Broom — January 22, 2010 @ 2:25 pm
> Would you buy a car, if the manufacturer tells you “well, a tire might fall off, every once in a while, but don’t worry, it has a steel frame it can slide on”…
Hahaha. AWESOME analogy.
YES! My car has AIRBAGS thank you very much!
Comment by Bob — May 25, 2010 @ 5:28 pm
“For something like Apache however, this is not the case.”
Apache was made with the thought of users easily sharing information. The exact opposite of what you’re trying to do here, which is contain information leakage. SELinux does very little to protect you and isolate users from each other in say a shared hosting environment.
Also, Apache drops privileges on most systems nowadays. Unless you do something stupid, like give CGI processes elevated privileges through suexec, the apache user does not have write permission to deface html files, etc, because those files are owned by a separate user.
I’ll concede that a MAC can give you finer grained control in this situation, but it is still not the only solution, and it’s not the epitome of security.
Comment by Daniel — January 22, 2010 @ 2:44 pm
@Daniel – “Yes, pending any local exploits to gain extra privileges, the bugs are contained. Just like a MAC. Pending any bugs in the MAC implementation, bugs are contained. You’re blindly trusting the MAC and you’re missing that OpenBSD simply took a different approach.”
This is simply incorrect.
In a MAC protected system, a local privilege escalation bug would do absolutely nothing. You could exploit it all you like, it would make no difference.
What is more, these EACL systems are formally verified. Which means they can be ensured not to have any bugs. I am still waiting for an example of a real vulnerability in these systems, that was not just poor policy.
@Broom – Of course I agree, that a correctly deployed system is secure. That is not an argument against my point however, and I don’t see it’s relevance.
I would rather be sure that in the event someone gains access, minimal damage is done rather than gambling that no one will ever get in, because I have an abundance of faith that my system is immune.
@Daniel – “Apache was made with the thought of users easily sharing information. The exact opposite of what you’re trying to do here, which is contain information leakage. SELinux does very little to protect you and isolate users from each other in say a shared hosting environment”
You are showing you lack of understanding here.
The power and flexibility of EACL is that they can do exactly as you say they can’t. They can ensure Apache functions just as it should, or a shared hosting environment, while ensuring that no damage can be done, or information leaked to unauthorized people.
On OpenBSD< as hard as it may be, once you succeed you have root and full access to the system.
"Two different approaches to security for two very different development models."
No. It is an inferior approach to security, by continual rejecting and misunderstanding a particular technology.
"It’s the most recent example, so why not give it?"
Because it is not an example of a vulnerability in an EACL framework.
"Also, if it’s simply from a bad policy, then why was the kernel patched rather than provide a patch for the policy?"
Because it was a bug even without SELinux.
With SELinux enabled, it was only a bug through poor policy.
With a correct policy, then the bug was meaningless.
My link only states that it is harder to protect against an untrusted yet authenticated user, then it is against an unknown remote attacker.
If you accept this, MAC is still able to provide much more of an increase in security than DAC.
"Have you even researched the criticisms of LSM or SELinux?"
Of course I have. Which is why my argument is not for LSM or SELinux, bur for the underlying concept. I much prefer RSBAC, which does not use LSM at all.
"systrace was not rejected. It’s in the base system."
It is rejected in the sense that the developers openly dismiss it and do not support it at all. As per the email thread I provided as a reference.
"You’re grasping at straws here."
I've made a consistant and coherrent argument. You continually bring up unrelated points and argue against points I did not make. Who is grasping at straws?
Comment by allthatiswrong — January 22, 2010 @ 3:48 pm
“What is more, these EACL systems are formally verified. Which means they can be ensured not to have any bugs.”
You still believe in the tooth fairy? Odd.
Comment by Matthias Kilian — January 22, 2010 @ 4:36 pm
“In a MAC protected system, a local privilege escalation bug would do absolutely nothing. You could exploit it all you like, it would make no difference.”
Sure, ideally. Your point isn’t lost. You just have a lot of faith in the people who implemented the MAC protection system.
“What is more, these EACL systems are formally verified. Which means they can be ensured not to have any bugs.”
Who is ensuring them not to create additional bugs as the example already given? SELinux opened up an attack vector that simply was much harder to exploit without it. Passing formal verification suggests it was working as intended. I for one would be more convinced by a demonstration of stopping that particular exploit with SELinux.
“You are showing you lack of understanding here.”
No, it’s not that. I understand completely what you’re saying. I know what MAC is. I know what it does. I’m simply telling you Apache wasn’t designed to isolate users. Sure, you can force a MAC upon it, but why? There are far easier ways to isolate users or sites, none of which involve a MAC. That is, if you really want to force Apache into that role. If your only tool is a hammer, I guess you use it for everything.
“I’ve made a consistant and coherrent argument. You continually bring up unrelated points and argue against points I did not make.”
Nothing has been consistent about your argument at all. You claim OpenBSD wasn’t designed with security in mind from the start, but since that also applies to Linux, NetBSD, FreeBSD, and just about any Unix clone or derivative, what’s your point? That’s a minus for all of them, not just OpenBSD.
You claim OpenBSD makes no attempt to restrict containment after a successful attack, when in fact they do. You just dismiss it because it’s not your preferred method of containment.
You keep asking for bugs in EACL, but that’s not the title of your post. You claimed OpenBSD was insecure. Back that up. Show OpenBSD’s method of containment isn’t enough. Show breaching OpenNTPD, following up with a local privilege escalation bug, and breaking containment. The task isn’t to prove you wrong when you haven’t even provided any solid arguments to begin with. The task is for you to prove your statement correct, which you have yet to do. You’re talking about hypothetical situations just as much as the people arguing against your statements regarding MAC protected systems.
When it comes down to it, you claim OpenBSD is less secure due to the lack of any type of MAC. But it’s just that, a claim. You’ve provided no evidence or facts to back that up. Just simply what would happen in a hypothetical situation. I would be stupid to say those situations are impossible, but OpenBSD makes them very unlikely.
I’m not grasping at straws, you’re just simply failing to connect the dots. I’m glad you feel warm and fuzzy with your MAC based protection. Myself, I’ll just respectfully disagree with your assessment and remain the paranoid skeptic.
Take care.
Comment by Daniel — January 22, 2010 @ 6:15 pm
@Daniel – “You just have a lot of faith in the people who implemented the MAC protection system.”
Perhaps, but that faith is based on the frameworks being formally verified, and not having had any vulnerabilities in almost 10 years.
“Who is ensuring them not to create additional bugs as the example already given?”
Crafting a dumb policy has nothing to do with the framework. In the case of the exploit you refer to, they chose to allow access so WINE could function.
Nothing to do with the framework itself, just a stupid policy akin to making an anonymous ftp server writable without limits.
“I’m simply telling you Apache wasn’t designed to isolate users. Sure, you can force a MAC upon it, but why?”
Because there is no other method as sure and reliable, or as flexible as using some sort of EACL.
I can give you many examples of setting up different levels and types of access to restrict users and processes in a way which is simply not possible on a DAC only system.
“You claim OpenBSD wasn’t designed with security in mind from the start, but since that also applies to Linux, NetBSD, FreeBSD, and just about any Unix clone or derivative, what’s your point? That’s a minus for all of them, not just OpenBSD.”
The point was that systems that are designed with security in mind from the ground up offer ways to restrict access, above and beyond only DAC.
The EACL frameworks can do far more to actually prevent damage than the protections which were added on to OpenBSD.
“You claim OpenBSD makes no attempt to restrict containment after a successful attack, when in fact they do. You just dismiss it because it’s not your preferred method of containment.”
Not at all. As per my article, I acknowledge the methods they provide to lock down a system. They are just subpar.
On OpenBSD, if I want to prevent the apache user from having access to the source for my web application while allowing apache to serve it, how would I do this?
“You keep asking for bugs in EACL, but that’s not the title of your post.”
Only because people keep claiming that they exist and that it is just another vector of attack. I ask people to back this up, and they are unable to, because it is simply untrue.
“The task is for you to prove your statement correct, which you have yet to do”
For any given attack situation, I can logically show a form of EACL provides far more security than is possible with ordinary DAC. You already acknowledge this point, so I am not sure why you keep arguing that OpenBSD is not less secure despite refusing any form of EACL.
You are right though, my argument is reliable on hypothetical combined with the current technology.
I’m happy for us to agree to disagree, and I will take comfort in the fact that I am using a system that even if the worst were to happen, no real damage could be done.
Thanks for the discussion though.
Comment by allthatiswrong — January 22, 2010 @ 7:47 pm
“Perhaps, but that faith is based on the frameworks being formally verified, and not having had any vulnerabilities in almost 10 years.”
I don’t think you understand what formally verified means. That doesn’t mean some 3rd party audited the code for correctness.
“Because there is no other method as sure and reliable, or as flexible as using some sort of EACL.”
Sure there is. Virtualization. Physical separation. I can go on and on here. You still aren’t connecting the dots. The original design of mixing confidential information between different users was broken to begin with. A MAC or EACL doesn’t make that design any better.
“For any given attack situation, I can logically show a form of EACL provides far more security than is possible with ordinary DAC. You already acknowledge this point, so I am not sure why you keep arguing that OpenBSD is not less secure despite refusing any form of EACL.”
And for any given attack situation, I can logically show a form of bypassing those EACL protections. You were even shown a real world example.
The only point I acknowledged was the merits of a MAC system as it stands on paper. It sounds really good on paper. It just doesn’t work out that way.
You excuse it though as poor policies. Why is it so hard to get the policy right then? Do you really think you’ve gotten it right when a corporation like RedHat cannot? Where are your policies? Where are your real world examples? You still haven’t backed up your statement.
“I’m happy for us to agree to disagree, and I will take comfort in the fact that I am using a system that even if the worst were to happen, no real damage could be done.”
Having used OpenBSD for the last 10 years, that is certainly a statement I would apply to it. I can’t say the same for any other platform. Then again, that’s real world experience, something that doesn’t exist in your little world.
Comment by Daniel — January 23, 2010 @ 10:34 am
@Daniel – “I don’t think you understand what formally verified means. That doesn’t mean some 3rd party audited the code for correctness.”
Err, I never said or implied that it did. Rather, a consequence of being formally verified is that we know how the software will act in all situations.
“Sure there is. Virtualization. Physical separation. I can go on and on here. You still aren’t connecting the dots”
You are listing alternative methods which may have their own set of advnatages, but they are still not as flexiable as EACL, and they can not solve the problems I gave as examples in the same way EACL can.
Your only argument to address this so far is “X software was not designed to do that anyway, why bolt it on top?”
“And for any given attack situation, I can logically show a form of bypassing those EACL protections. You were even shown a real world example.”
Sorry, but this is just crap. There has been no real world example at all, no vulnerability for the major frameworks in nearly 10 years, and no known way to bypass an EACL system with a correct policy.
If your only argument against this is the fact that RedHat chose to ship an insecure policy for the sake of making WINE work which them backfired, then it just shows your not willing to actually consider you may be wrong.
“It sounds really good on paper. It just doesn’t work out that way.”
OK, why not? There are numerous examples of exploits being constrained and mitigated, where as had they worked on an OBSD system far more damage could have been done.
“You excuse it though as poor policies. Why is it so hard to get the policy right then?”
It was a poor policy. For the sake of making WINE work. Otehr distributions with SELinux did not have the same problem, and other frameworks such as GRSecurity and RSBAC were immune.
Just because one particular implementation, SELinux, might be considered too complex is not enough to dismiss all implementations as too complex.
“Having used OpenBSD for the last 10 years, that is certainly a statement I would apply to it. I can’t say the same for any other platform. Then again, that’s real world experience, something that doesn’t exist in your little world.”
I have plenty of real world experience. Which is why it was frustrating everytime people claim how OpenBSD is the most secure OS the world has ever known, when all it takes is someone running one peice of insecure software to get root, and then all bets are off. Not so on an EACL system.
Thanks for playing though.
Comment by allthatiswrong — January 23, 2010 @ 1:44 pm
“Err, I never said or implied that it did. Rather, a consequence of being formally verified is that we know how the software will act in all situations.”
Does that include when 3rd parties tinker with those implementations in unknown ways?
“You are listing alternative methods which may have their own set of advnatages, but they are still not as flexiable as EACL, and they can not solve the problems I gave as examples in the same way EACL can.”
Of course they do not solve the problem in the same way. That’s the point. In fact, physical separation provides far greater security than an EACL. If you think my only argument is that “X software was not designed to do that anyway …”, then you aren’t listening or comprehending. I was just going along with the tangents you threw out there.
“Sorry, but this is just crap. There has been no real world example at all, no vulnerability for the major frameworks in nearly 10 years, and no known way to bypass an EACL system with a correct policy.”
I’m glad you see that it’s crap. You fail to see that it is your argument, just with the positions reversed. You haven’t proven, even in the slightest, that OpenBSD’s current methods are not enough for what OpenBSD is generally used for. You also have not proven any current vunerabilities in OpenBSD. From your statement, are you implying that there are none?
“… to actually consider you may be wrong.”
Not at all. I’ve already conceded to the merits of a MAC based system. Ideally, if sounds really good. Ideally. Realistically, they’re complicated to implement correctly. Even the people calling it complete garbage in these comments have more than likely tinkered with it previously (because it does sound good). It’s you who is unwilling to see the otherside of things. That’s fine. No one really cares in the end. You also keep attacking people in your comments rather than stating any technological evidence to supoprt your claims about OpenBSD. You would rather point the finger at me, call me irrational, incoherent, and now “not willing to actually consider you maybe wrong” (close minded I guess). Is it that you have nothing to support your very bold statement that OpenBSD is insecure? So what if I do not consider that I maybe wrong? WTF does that have to do with your “the insecurity of openbsd” post? Nothing. I thought you might actually provide an intelligent and meaningful discussion, but it appears you have some other agenda. And sure, I’ll attack back. *shrug* It passes the time.
“OK, why not? There are numerous examples of exploits being constrained and mitigated, where as had they worked on an OBSD system far more damage could have been done.”
That’s not helping your case any. “had they worked on an OBSD system …”. “had they worked …”. So, OpenBSD’s protection, so far, had been effective in those cases? Real world cases? I suppose you can add to your argument “AND IF systrace wasn’t used, AND IF it wasn’t sandboxed”. Your argument is “what if”? I intentionally gave you a “what if” statement in my last reply to see your response, and you noticed right away it was bull. Are you really not seeing what you are writing?
“It was a poor policy. For the sake of making WINE work. Otehr distributions with SELinux did not have the same problem, and other frameworks such as GRSecurity and RSBAC were immune.”
It was a little more than a poor policy. I’m serious when I say that if you really want to prove the merits of an EACL, then demonstrate that bug being stopped with SELinux. I was also hoping you would notice that all MAC implementations are not created equally. You’re almost saying it in the above, but not quite. You can’t deny that they’re different, and provide different strengths. Which also means, they each have different weaknesses. Yes, they have weaknesses.
Take your reasoning in the quote above. “For the sake of making WINE work”. How many policies are going to fail because usage of the system is required? In fact, you can’t even say the policy failed, or was poor. The policy did what it was supposed to do. AFAIK, there is no way in SELinux to say “allow WINE to run, unless you have malicious intentions”. It’s kind of of an all or nothing thing. You either allowed that particular access, or you didn’t. I don’t really care to elaborate any further on that example. You get it or you don’t. I’ve also conceded and acknowledge the merits of an EACL, no need to retort with an EACL can contain the damage done. Possibly, but I’m not confident that once you’re able to poke around in the kernel that further attacks will be prevented. Formal verification be damned. The policy allowed it go get that far.
“Just because one particular implementation, SELinux, might be considered too complex is not enough to dismiss all implementations as too complex.”
First, the complexity is what OpenBSD rejects. Next, I’m explicitly picking on SELinux. Finding out your policy was bad (human error, etc) is also a little too late in the game. It also does not incur confidence that a policy can be written correctly.
I’ll point out GRSecurity here. It wouldn’t have happened, and it’s not because of the included RBAC.
“Which is why it was frustrating everytime people claim how OpenBSD is the most secure OS the world has ever known, when all it takes is someone running one peice of insecure software to get root, and then all bets are off. Not so on an EACL system.”
Which EACL system prevents that out of the box?
And well, those people are fools. No one from OpenBSD claims that. Read what it states on their home page. Absolutely nothing about being better than the next guy. Most experienced users in the OpenBSD community are very realistic about it’s feature set. They know very well what it can and cannot do. Know it or not, you have several developers quoted in your comments as well.
Also, http://en.wikipedia.org/wiki/Straw_man
Project XYZ having an EACL or MAC does not in itself prove OpenBSD is insecure. Project XYZ has nothing to do with OpenBSD. OpenBSD is not insecure because Project XYZ simply exists. You might feel that Project XYZ is a better choice given it’s features, but it still does not hold your statement true. Saying that it’s feature set falls short compared to others is one thing, saying it’s not able to perform the task is another.
MAC and EACL are not the only way to sandbox an application. FreeBSD has sysjail. Linux also has various virtualization techniques. There is still physical separation of services. There are too many methods and platforms to even list here.
You could have simply stated that OpenBSD does not have those features. It’s not even debatable. OpenBSD, currently, does not have those features. Instead, you choose a blanket statement about the insecurity of OpenBSD.
People using OpenBSD, are also not completely limited to only using OpenBSD. It can compliment other systems quite well.
It’s pretty clear that you intended an attack on OpenBSD and it’s community. You even admited your article is in retaliation to OpenBSD zealotry. Boohoo. Other platforms have zealots, too. There’s no shortage of them.
“Thanks for playing though.”
Is this a contest of some sort? Did you just pronounce yourself the winner? Too funny, champ.
Comment by Daniel — January 23, 2010 @ 11:35 pm
@Daniel – This is going to be my last reply. You are continually twisting words and arguments, and ignoring what I have written in the article and in comments to others.
I will attempt to clarify some of the myths you have stated.
There is no reason to assume that 3rd parties will tinker with an EACL framework, than there is to assume your copy of OpenBSD has a backdoor. That argument is a perfect example of grasping for straws.
“physical separation provides far greater security than an EACL”
No, it doesn’t. It doesn’t stop information leakage or destruction. For that you need Granularity, at least with an ACL and preferably with MAC.
I have certainly not resorted to attacking you. There are only so many times I can point out your examples are incorrect or not relevant before I go blue in the face however.
You then go on to seeimingly arguea against EACL systems due to their complexity. That due to this complexity, policies will always be wrong. I’m sorry, but that is just short sighted. Not all implementations have to be complex to administer, and the time taken to properly author a policy is a worthwhile investment.
Also, as far as your vulnerability and WINE is concerned the problem was allowing mmap to 0 for the general policy. The fix would be to restrict mmap to 0, and to allow it only for specific WINE instances.
Lastly, I never made the claim that systems with MAC prove OpenBSD is insecure. That would be an example of putting words in my mouth.
You raised some good points, and it was interesting discussing things with you. Unfortunately, you had to resort to attacking men made of straw.
If you have a valid counterargument for a claim I have actually made, that isn’t made out of ignorance like repeatedly relying on the SELinux vulnerability, then I will happily respond.
Comment by allthatiswrong — January 24, 2010 @ 5:06 am
“There is no reason to assume that 3rd parties will tinker with an EACL framework, than there is to assume your copy of OpenBSD has a backdoor. That argument is a perfect example of grasping for straws.”
… and there is no reason to assume a program contains a trojan, etc, etc. Seriously, you have a very trusting nature. It’s not natural in the security field.
“No, it doesn’t. It doesn’t stop information leakage or destruction. For that you need Granularity, at least with an ACL and preferably with MAC.”
Information that was never on that system cannot be leaked or destroyed by a compromise of that system.
“I have certainly not resorted to attacking you. There are only so many times I can point out your examples are incorrect or not relevant before I go blue in the face however.”
But you haven’t proven them wrong. Very early in this conversation I asked you which bugs would not be bugs with some sort of MAC on OpenBSD. You obviously did not even look, and you’re still using your pretend perfect MAC implementation and pretend known vunerabilities in OpenBSD to back up your very false claim. The fact that you think this is unrelated or doesn’t contrast your points is astounding. Do you really need this much hand holding? Shall I go over the current errata page with you? Okay, let’s do that, because you aren’t a capable person.
>> 001: RELIABILITY FIX: July 29, 2009 All architectures; A vulnerability has been found in BIND’s named server (CVE-2009-0696). An attacker could crash a server with a specially crafted dynamic update message to a zone for which the server is master.
What MAC policy would have changed that fact, or made that fact less damaging? So, as a service provider, my users would not be subject to hijacking if I employed a MAC or EACL on our name servers? The MAC protection would stop BIND’s cache from being corrupted. Eh? You really didn’t look at all. It’s obvious, and it’s hard to take you seriously.
>> 002: RELIABILITY FIX: October 05, 2009 i386 only; XMM exceptions are not correctly handled resulting in a kernel panic.
What MAC policy would cause the kernel to not panic?
>> 003: RELIABILITY FIX: October 28, 2009 All architectures; getsockopt(2) with any of IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL, IP_IPCOMP_LEVEL will crash the system.
And here?
>> 004: SECURITY FIX: November 26, 2009 All architectures; The SSL/TLS protocol is subject to man-in-the-middle attacks related to renegotiation (see CVE-2009-3555, draft-ietf-tls-renegotiation-00).
And this one?
They’re your words, champ. I didn’t put them in your mouth. You simply aren’t getting it.
“You then go on to seeimingly arguea against EACL systems due to their complexity. That due to this complexity, policies will always be wrong. I’m sorry, but that is just short sighted.”
I acknowledge their merits. I won’t put blind faith in them, though. It is also related to your post, but I guess you just don’t see it. OpenBSD doesn’t reject them. It’s the complexity in current frameworks that is rejected.
Yes, you don’t twist words or misinterpret what people are telling you at all. What I was doing was complete different than you. *rolls eyes* Quote me saying policies will always be wrong. I’ve been saying they’re tedious, which makes it difficult to get them correct. In the real world, people only find out they got it wrong after something damaging has happened. How you draw conclusions is hilarious. Your brain is very damaged.
“Also, as far as your vulnerability and WINE is concerned the problem was allowing mmap to 0 for the general policy. The fix would be to restrict mmap to 0, and to allow it only for specific WINE instances.”
Then WINE becomes the attack vector. I’m talking to an Eliza bot, aren’t I? Damn it.
“If you have a valid counterargument for a claim I have actually made, that isn’t made out of ignorance like repeatedly relying on the SELinux vulnerability, then I will happily respond.”
They’re all valid. You wanted real world issues, but then dismiss real world issues.
While you haven’t used the exact words, one of your arguments against OpenBSD is that an undiscovered bug could be extremely damaging (I can quote you, but why, you know you said it). That’s not disputable, because it can’t be supported or denied. However, the same goes for the frameworks you praise. Just because bugs haven’t been discovered, does not mean they won’t ever be. I still don’t know if you get it.
You wasted your whole response, because you still would rather redirect the attention of your audience to things like what I’ve said, rather than the point, supporting your own claims. I could simply quote my favorite poems here, and in the end, you still haven’t provided support to your claims at all. What I say is irrelevant. You’re the one that made the claim. You haven’t supported it at all, which is very telling.
And hey, you write troll bait, you get trolls. Not sure what you expected here.
Comment by Daniel — January 24, 2010 @ 7:46 am
“Unfortunately, you had to resort to attacking men made of straw.”
*whew* I finally stopped laughing long enough to make another reply.
http://www.fallacyfiles.org/strawman.html
Comment by Daniel — January 24, 2010 @ 9:00 am
“What is more, these EACL systems are formally verified. Which means they can be ensured not to have any bugs.”
Formal verification on which level?
Design, specification, implementation? Are the interfaces and the _underlying kernel_ also verified?
“ensured not to have any bugs” may be L4.verified (http://ertos.org/research/l4.verified/), but a quick search on the SELinux ML archives brought up patches with code (even labeled RFC) but nothing about matching specification to the implemented mechanisms.
My guess would be the (initial?) design and specifications were verified but today half of the trusted computing base is gone.
Assuming the code was verified, too.
Comment by etalas — February 3, 2010 @ 5:34 am
“Considering how they rejected systrace(not because it was insecure, but because they did not believe it improved security), if someone did port TrustedBSD it would be similarly rejected.”
For it being rejected I clearly remember it being committed when I was part of the OpenSSH team, I clearly see it installed on my 4.6 box, and I clearly see two default rules (bind and lpr).
In comparison, are we suggesting that Sun has rejected MAC in Solaris 10 because by default they do very few to no rules?
I’m not going to argue the pros/cons of systrace. I remember the discuss of the flaws on the internal lists, and how in the end they were limitations of a still very powerful tool. Otherwise, Theo would have had it stripped.
However, I find it disingenuous you keep saying “OpenBSD rejected it” when clearly they didn’t. They just don’t provide many default rules. Leaving it to the community and the system admin to make the choice on how to correctly deploy the tool.
Comment by Mouring — February 24, 2010 @ 2:41 pm
I am certainly not trying to mislead or be disingenuous by saying the OpenBSD team has rejected systrace, but it is my understanding.
The developers seem quite critical of it, and it is my understanding that while it is in ports, it is not in the base system and never will be.
I don’t have my OpenBSD 4.6 Vm available to check and so would appreciate clarification.
However if it is included in the base install, I find the comments by the OpenBSD developers even more perplexing.
Comment by allthatiswrong — February 24, 2010 @ 3:18 pm
1. If you don’t understand what OpenBSD is about, don’t use it.
2. If you do understand what security is about, (help) implement it yourself.
3. Else, shut up.
Comment by Maxim — January 22, 2010 @ 2:00 pm
Well thank you anonymous clown for making a strawman argument based on no facts or coherent thought. EACL buys you nearly nothing and it is obvious you have never written a single line of code in your life. I am happy that people like you exist to provide entrainment for the rest of us on a crappy Friday.
Comment by poopy the clown — January 22, 2010 @ 2:18 pm
I am more than happy to engage in debate and defend my argument, but not when people only leave insults.
Further comments of this kind will simply be deleted.
Comment by allthatiswrong — January 22, 2010 @ 3:53 pm
[…] insecurity of OpenBSD RD: @olhe: https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ #openbsd #bsd #foss #os # Comments […]
Pingback by Mis tweets | casidiablo.net » Tweets hechos en 2010-01-22 — January 22, 2010 @ 2:54 pm
Pavel Labushev, is that you?
I’ve noticed that you have had an agenda against OpenBSD for a long time.
Comment by foobar — January 22, 2010 @ 3:32 pm
No, I’m not allthatiswrong. I just googled up this article and should say its point is mostly opposite to mine. Because I think privilege separation, jailing and MAC don’t work as long as your kernel itself is not protected from exploitation. Vanilla Linux, OpenBSD and FreeBSD kernels are not protected, with reservation that OpenBSD kernel has sane enough code to be considered moderately secure these days. So if I would be the author, I would say, with no regard to availability of MAC frameworks, that OpenBSD is more secure than vanilla Linux and FreeBSD, not the reverse.
Yet you, whoever you are, remember not any significant details of my point, but my name and your personal overgeneralized rough conclusion that I “have had an agenda against OpenBSD”. That’s very clarifying, thank you (no irony).
Comment by Pavel Labushev — April 10, 2011 @ 10:49 am
Hi Pavel,
I actually agree with you, that as the kernel is still vulnerable it needs to be audited very carefully.
Of course, this isn’t the case with Linux, and given the development teams poor attitude toward security in general is unlikely.
Still, more often than not I’d take a hardened MAC solution over OpenBSD, for the reasons I point out in the article.
Limiting the attack area only to kernel exploits is preferable to assuming that you have eliminated all the bugs from your code, leaving you defenseless in the scenario where you missed an important vulnerability.
Comment by allthatiswrong — April 10, 2011 @ 3:31 pm
The various implementations of MAC on Linux (viz, SELinux and apparmor) were defenseless against the sendpage vulnerability in all linux kernels from 2001 to 2009. I am not aware of a comparable bug ever being found in OpenBSD–that is, one that allows root privilege escalation in the OS for all versions deployed over that long a time period.
Comment by pgarcia — January 22, 2010 @ 4:02 pm
No, not all MAC implementations were vulnerable. This myth needs to die.
The default SELinux policy that shipped with certain distributions was vulnerable.
Comment by allthatiswrong — January 22, 2010 @ 4:29 pm
> The default SELinux policy that shipped with certain distributions was vulnerable.
… in direct contrast to the fact that OpenBSD is secure by default. No extra crap that could open security holes, when you install your system, it is secure at that point in time. Your article attacks holes opened up by third party applications that are installed and enabled afterwards, while missing the point of “secure by default”. Granted, a system like that isn’t of much use, but at least you know your box won’t be hacked while you’re still setting it up – and you have an established base to begin with in terms of keeping your machine secure.
Also, I think you’ve taken pgarcia’s comments out of context -the straw man you lament Daniel for attacking lies in your assertion that MAC implementations are not vulnerable, but rely on the configuration. Yet you consistently refuse to provide a case where MAC prevented a kernel panic or incorrect implementations of system calls. Until you do, people are going to continue to attack you.
Comment by thirdwheel — January 24, 2010 @ 7:35 pm
That is exactly the problem though, and I addressed it in my article. I already admit that OpenBSD is quite secure if only sticking to the audited base system.
The problem is exactly that if you do install 3rd party software(likely), or there is a remote vulnerability in OpenBSD(less likely) that there is no adequate way to restrict the damage that can be caused.
As for Daniel, he is arguing a strawman, and nothing more. I have never claimed that an EACL system is capable of preventing a DOS or MITM attack.
Of course there are certain situations where these frameworks would not be of use(also already addressed in my article), but in the context of thoroughly restricting access to information they are the only real option.
Comment by allthatiswrong — January 24, 2010 @ 9:16 pm
Any system designed to be secure can be compromised if you don’t select the correct software – this is good sense, even the dimmest among us can recognise that. If you put a hole in your boat and plug it up with something else, there’s a good chance that something else will either break down faster than the boat’s material or be weaker than the rest of the structure, causing the boat to sink.
> in the context of thoroughly restricting access to information they are the only real option.
I’d like to see evidence to suggest that compartmentation and privilege separation is worse than EACLs. EACLs are, by their nature, quite complex and with higher complexity comes greater chance of failure. Compartmentation (chrooting) and privilege separation (dropping to an ordinary user) are good and easy, but unless the kernel prevents the program from accessing memory allocated to other programs, even EACLs can be rendered moot.
EACLs are a classic case of attempting to fix security issues through the addition of new code. OpenBSD’s devs chose to fix the existing code rather than add layer after layer of security abstraction, each one adding more complexity to the problem. If EACLs actually solved the problem, the number of compromised systems would be going down, not up.
There are clueless Sysadmins who basically throw in the install CD for (insert OS here – though I will say M$ operating systems rank quite highly in this context) and hope for the best. No amount of EACLs is going to help them because they’re unlikely to apply them.
There are people in the world who can safely say that the server they installed OpenBSD on, had the company’s crown jewels placed on it and walked away for a year, and been confident that it’s never fallen or been compromised. Anyone who says this about their other OSes either don’t do their job properly or are extremely lucky (most likely the former).
Of course, applied properly and extensively tested, EACLs are a valuable companion in the fight against undesirables, but this usually implies a policy of Penetrate and Patch which, if it was the way to go, would have worked a long time ago.
Comment by thirdwheel — January 26, 2010 @ 11:27 pm
I suppose with your analogy, plugging it up would be refering to EACL frameworks? That is just a poor way of looking at it. A more accurate analogy would be for the boat to have two layers, so even if one layer gets a hole, it won’t be possible to penetrate through the boat and it won’t sink.
“I’d like to see evidence to suggest that compartmentation and privilege separation is worse than EACLs”
I have provided many examples of SELinux preventing exploits from being able to do any damage. Exploits, hat if they were to suceed against an OBSD box, would be able to do a lot more damage.
There are also many cases where you can logically restrict access with an EACL system that in a way that is simply not possible with ordinary DAC.
For example, preventing information leakage or destruction/defacement. If I manage to get root on OpenBSD, then I can copy all the files I encounter, as well perhaps modify them.
Now, backups may help here, but they don’t help against information being leaked, and potential damage which can cause real problems.
I don’t really even understand why people are bothering to claim that anything you can do under MAC, you can do under DAC, when that is very simply, very provably, not the case.
The people who continue to dismiss EACL frameworks and say that DAC is just as powerful clearly don’t understand the technology, which is evident with them considering ACL’s to be a form of MAC.
I don’t think I will be making any more comments, because I am ending up to just repeat myself, as people are making the same arguments over and over.
“EACLs are a classic case of attempting to fix security issues through the addition of new code.”
Sure, but then so is W^X or any other preventative measure OBSD has added.
The argument against the systems being too complex is weak, at best. Even systrace would provide increased security if the underlying method were trustworthy, and that is simply enough to use. The technology does *not* have to be complex to code or administer, however that is not the reason the OpenBSD team reject the technology.
They reject it primarily because they consider MAC security theater(see the Marc Espie reference), which shows that they have a poor understanding of the underlying theory.
If they were to acknowledge that they can provide greater security, as you do, but that there are too complex and not worth the increased security then you would have a point. Instead, they flat out reject any implementation of the technology, which is much harder to excuse.
An EACL system can limit access in ways that is simply not possible with DAC. Due to this, it can provide for greater security in many instances, where a DAC system would fail. If you disagree with this simple statement, then you shouldn’t be discussing this issue.
(Thirdwheel, that is not directed at you specifically, I have just gotten sick of a lot of the attacks. Your posts have been well written and with good content, so thankyou.)
Comment by allthatiswrong — January 27, 2010 @ 1:09 am
I still don’t see any data pointing to OpenBSD having a larger list of known security risks than any other OS — Unix or otherwise. Until then, the original article doesn’t even qualify as an abstract for a research article but merely an editorial or letter to the editor.
q.v. http://openbsd.org/security.html, http://www.sans.org/top-cyber-security-risks, http://www.commoncriteriaportal.org/products_OS.html#OS, and http://en.wikipedia.org/wiki/Abstract_(summary) vs.http://en.wikipedia.org/wiki/Letters_to_the_Editor#Misrepresentation
Comment by Gary D — January 22, 2010 @ 4:31 pm
This article makes a good song and dance about secure operating systems, but the author obviously has no actual experience in the development of one. I suggest reading Trent Jaeger’s “Operating System Security” as a starting point for further research (especially the chapter about MULTICS and the hardware/software challenges it faced).
Comment by Nick — January 22, 2010 @ 4:41 pm
That’s one interesting editorial piece. I see you list a lot of references at the end, but I would to see more citations in the article when you’re making claims. I see no real data exect for the Core Security Advisory from 2007. The rest of your evidence is based on general OS lectures and opinions, neither of which count as solid proof.
Comment by Dan — January 22, 2010 @ 5:47 pm
@Gary – My article was never designed to be anything more than an opinion piece. It certainly should not be taken as serious research!
If you think the list of vulnerabilities of OpenBSD is relevant to crediting or discrediting my argument, then you may have missed the point I was trying to make.
@Dan – Well, yes, it is just an opinion piece. I provide examples of exploits being mitigated by EACL’s, examples of the OpenBSD’s teams dismissal of EACL technology, links showing systrace is insecure, a reference to OpenVMS security, widely considered to be one of the most secure OS’s available, and other links I thought were relevant.
What would you suggest as further evidence for an opinion piece?
Comment by allthatiswrong — January 22, 2010 @ 6:02 pm
http://lmgtfy.com/?q=privilege+escalation+attacks
Where’s your “ACL” now, b1tch?
Comment by Henry Sieff — January 22, 2010 @ 6:05 pm
Intelligent reply. As mentioned over, and over, and over, privilege escalation attacks can be effective on any bug, ACL, MAC, or otherwise. The point of hardening a system is minimizing the success of the attacks, not eliminating them. So, is there more intelligent conversation in that cranium of yours?
Comment by Aaron — January 22, 2010 @ 7:09 pm
Oh, let us not argue quality, it is so hard to define and defend. Those who see and understand quality know when they have it. Things of quality don’t always meet every need but withstand the test of time and abuse. OpenBSD is quality software and hopefully always will be.
Comment by bgr — January 22, 2010 @ 10:17 pm
Let’s say you are a SELinux guru, you do know what you’re doing and you *think* your policy is 100% correct.
[else, security might be weakened or ineffective]
A vulnerability in one of your service is successfully exploited by an attacker, you know that and nothing else.
Isn’t it a bit presumptuous not to reinstall the full system immediately ? I am just asking here… An attacker who owns one of your front box and manage to gain maximum/enough privileges will spread up elsewhere and be able to do more damage|steal more information without you noticing anything.
But wait, I’m a wise admin, I decide not to rely on the skills of the attacker or the NSA’s crap, but to reinstall a clean system in 5 minutes (with particular attention to the vulnerable service that caused this security problem). Game over for insecurity.
ACL will save you in most cases, but I’d rather spend 30 minutes reinstalling and backing up data than several hours designing additional policies to make sure the *patched* linux crap won’t enable privilege escalation.
In terms of security, the best thing to do is not to permit arbitrary code execution.
ACL is just cool, it may be a pain in the ass for the attackers, but that’s another discussion, forget about OpenBSD. I expect this OS to be clean, and simple. This will produce security more than adding crap over and over until someone realizes that security is being compromised by a confidence overflow attack :).
Comment by Tora — January 23, 2010 @ 12:43 am
+1. You can’t make a silk purse out of a sow’s ear, unless the sow’s ear keeps getting patched up with silk until all you have is a sow’s ear made out of silk. Turd polish only makes the item look shinier in the short term.
Nothing is better for security than proactivity. Fix the problem, don’t make it impossible for it to happen. Make a foolproof system, nature makes a better fool. Once the “foolproof” system is broken, a bigger fool is produced: you.
Comment by thirdwheel — January 24, 2010 @ 7:40 pm
Your article: “The consensus among OpenBSD developers and community is that you can achieve the same result using chroot and systrace.”
A quote from Bob Beck taken from your own list of references: “Most of us don’t believe systrace is a be all and end all security tool. Most of us who work in the kernel do not want to go to the trouble and disruption in the kernel to try to “fix” something that in our opinion is broken by design.”
I’m not convinced that some of your ideas are completely without merit, but your article is, to be charitable, pretty brutal.
Comment by Chris — January 23, 2010 @ 3:51 am
Hi Chris. That may appear to be a contradiction, but I think that while the core developers may reject systrace, there are still many in the community and on the team who suggest it.
I do realize my article is brutal…but I really wanted to get my point across. It isn’t meant to be a perfect attack on the developers, as I am aware of a lot of the good work they have done, namely OpenSSH.
Comment by allthatiswrong — January 23, 2010 @ 1:56 pm
“I do realize my article is brutal…but I really wanted to get my point across. It isn’t meant to be a perfect attack on the developers, as I am aware of a lot of the good work they have done, namely OpenSSH.”
That’s what is so ridiculous with your point of view.
You say on one side that you should not trust OpenBSD as a secure operating system, but on the other side, you trust the OpenSSH security which is made by the same people.
Dude, if they are so stupid to not trust your *complex* MAC *implementation*, then they are so stupid to make crappy software and you should not use OpenSSH at all.
Comment by Duffman — January 25, 2010 @ 10:00 am
You do realize that with OpenSSH running under an EACL framework that even if it were to be exploited it would not be able to do any damage, right?
Comment by allthatiswrong — January 25, 2010 @ 3:23 pm
When you mean brutal do you mean poorly put together, or do you mean “I think it paints some people in a bad light but that’s OK because I think it’s accurate”?
If you mean the former, then get to editing – articles like this shouldn’t be static, especially when fundamental errors are pointed out.
If you mean the latter, please realize that you toss any credibility you have right out the window when you make these kinds of mistakes.
I have trouble seeing what kind of non-asinine purpose you might have in writing this article if you refuse to correct mistakes. “Consensus” has a clear meaning, and your use of the word is repudiated by your own references.
I’d like to think there’s something salvageable here, but each interaction I have with you here makes me more and more suspicious that you’ve no constructive purpose here, and are just being a baby about OpenBSD’s alleged “most secure” status.
Comment by Chris — January 29, 2010 @ 2:22 am
Bud, you cank think whatever you like. The facts are here for people to see.
The article is well put together as many people noted and remarked upon, and as many of the sites that carried a link noted.
The only error that was pointed out was when I referred to strlcpy/cat as system calls and not libary calls.
Simply because you disagree with my opinion does not make it erroneous. In fact going by some of the comments you posted, it seems clear you don’t actually understand the tech, and would rather jump into defensive mode than consider the argument.
FWIW, a consensus is in part defined as a general agreement. In that sense what I have written is correct, and the fact that a few core developers disagree in no way invalidates that consensus.
But hey, feel free to keep arguing semantics and laying out insults instead of bothering to educate yourself about these things.
Comment by allthatiswrong — January 29, 2010 @ 6:29 am
I think that fixing something that is already there, and making it close to perfect, is by far more important than saying “well, I don’t trust what’s there, so let’s build a second line of defense”.
I’m sure that in the future, there will be a third one, maybe a fourth, etc., because nobody wants to fix the other lines first.
Comment by Broom — January 23, 2010 @ 10:39 am
Security is a concept, not a software solution per se. The latter is just part of the whole system. OpenBSD is a concept, they _try_ to secure the whole system (and essential applications) as best as they can. SELinux e.g. is just a complex tool, which is even prone to fail if the maintainer of a certain distro isn’t able to implement this framework in a proper way. And this is just beginning, if the administrator isn’t able to cope with it, then your security is doomed.
Really, if this is your understanding of security, than lets hope you’ll will never experience a real problem in this context.
Comment by Oliver Herold — January 23, 2010 @ 11:09 am
Hooray for cowardly, anonymous, 100% opinionated FUD that will now be passed around by the ignoramus “community” as though it were real proof!
Total contribution to ANYTHING: 0
Comment by Flea — January 23, 2010 @ 4:19 pm
[…] The insecurity of OpenBSD Table of Contents Introduction Secure by default Security practices and philosophy No way to thoroughly lock down […] […]
Pingback by Top Posts — WordPress.com — January 23, 2010 @ 7:09 pm
I have updated the article to talk about the benefit of formal verification, and address the possibility of an EACL framework being bypassed with a kernel vulnerability.
Comment by allthatiswrong — January 23, 2010 @ 9:58 pm
Could you update the title to be “My insecurity of using OpenBSD”?
Comment by Daniel — January 23, 2010 @ 11:43 pm
Touché… 😉
Comment by Broom — January 24, 2010 @ 10:23 am
Theoretically, they would be equivalent. A fundamentally hardened DAC compared to a properly MAC hardened DAC.
I would not say OpenBSD is insecure. It might be a little bit more secure with some sort of Mandatory Access Control, but it’s not required – theoretically not needed.
Comment by cyphercell — January 24, 2010 @ 1:46 pm
[…] insecurity of OpenBSD RD: @olhe: https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ #openbsd #bsd #foss #os […]
Pingback by Mis tweets | casidiablo.net » Twitter Weekly Updates for 2010-01-24 — January 24, 2010 @ 5:59 pm
I only want to recall to people that dismiss MAC or RBAC methods, that sometimes it is much more important to protect information than systems. Kudos for OpenBSD, but sometimes even the administrator should’nt have access to certain data (military, medical, financial, etc.)
There are lots of scenarios where root or administrator simply cannot be trusted by default, much less be the only point-of-trust. Normal company networks may not apply, and i think that’s why some experienced administrators don’t gige MAC or RBAC credit.
Regards.
Comment by juan — January 24, 2010 @ 8:33 pm
Hi Juan,
That is a really good point, and something I did try to touch on in my article.
Security is much more than doing everything to prevent getting root; It is also being able to restrict exactly who has access to what information. Something that is not possibly with the ordinary Unix DAC system.
Comment by allthatiswrong — January 24, 2010 @ 9:18 pm
This is exactly my use case. I’m the administrator of a BSD system wich is internet facing because some people need to access the machine.
However, I’m currently looking at ways to make sure that nobody is able to read the confident documents I have on the system, only the intended users, so not even root.
There are not so many examples on the net witch describe this.
Comment by robert — January 25, 2010 @ 6:05 am
I’d like to know how anyone plans on doing this with SELinux. Who manages the SELinux configuration if root does not have access, if root does have access what prevents her from turning it off? It seems this is possible in theory, but not so much in practice.
Here’s what OpenBSD does.
http://www.openbsd101.com/security.html
You could use file encryption, but unless it’s run on the users’ machine and uploaded to the server it would still be vulnerable to inspection.
The policy of “locking down root” is security theater in this context. There will always be a user on the system that can change policy.
So there it is. Tell them to encrypt their stuff before they upload it or give ’em a show.
Comment by cyphercell — January 25, 2010 @ 9:14 am
Sorry, the point with the OpenBSD101 link is to point to the kernel flags section. The functionality you want is not currently available, but I think this would be the place where openbsd would implement your feature.
http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Security
An older version of this argument.
Comment by cyphercell — January 25, 2010 @ 9:50 am
Hi.
I don’t understand why you would say being able to take away the concept of one all powerful account is security theater.
Yes, there will be a user who can change policy, however that user will *only* be able to change MAC policy. Not read or change any documents, or perhaps even run any processes. As opposed to breaking just the root account, you would have to break the root account, the policy account, and any other account that had access to what you needed.
I would also like to hear more why you think the security of a DAC system is theoretically equal to a MAC system. I suppose in a best case scenario neither system would ever be broken into, but how is that relevant?
I have added the kerneltrap link to my list of references.
Comment by allthatiswrong — January 25, 2010 @ 3:16 pm
Security theater, because the NSA developed the system in order to approximate a hardware solution which is “theoretically” impossible to implement in software. Therefore the above poster would be better served by actually using two different machines to implement the security solution. It’s better security, if you really want, but it might be better to use MAC even if it requires building a new server depending on the particular business case. It’s kind of like somebody at Red Hat deciding they absolutely need support for 16bit windows applications and that is important enough to bypass default security measures in your kernel configuration.
I like your argument, I really do, it’s good for people to consider these things, but OpenBSDs ultimate goal is simply to not ship shite and slap a kludge on it later. This is what makes them far more resilient to things like misconfiguration.
Now more to the point. What is it exactly that makes OpenBSD insecure? Is it the features you want but can’t secure that is pissing you off? The inability to leave core and still lock things down?
Here’s a hint.
If you don’t want to leave core, you can use something else.
Comment by cyphercell — January 25, 2010 @ 3:57 pm
Don’t confuse the underlying technology with a specific implementation, SELinux.
I don’t believe there is any alternative to an EACL system that would meet the posters requirements, i.e. restricting the root account from having access to sensitive documents.
Having separate or physical machines would not help in this instance, at all.
Advising to encrypt documents instead is a hack to get around functionality that should be present in a secure system.
Now, you ask what makes OpenBSD insecure. If you take a look at my opening paragraph, I note that I am not saying that OpenBSD is insecure, bur rather talking about the insecurity of OpenBSD, i.e. the security limitations of the system that exist because the developers like it that way.
Comment by allthatiswrong — January 25, 2010 @ 4:57 pm
The bugs are always in the implementation, well, unless they are in the code. That’s what I appreciate about OpenBSD
“I don’t believe there is any alternative to an EACL system that would meet the posters requirements, i.e. restricting the root account from having access to sensitive documents.”
From an ACL perspective yeah sure, you’re right. From a use case perspective there is at least one instance where my hack is a bit more secure. I guess you could use my hack along with the MACs and that would be even more secure, but only if you can break the encrypted file. Therefore, the presumption that the encryption works is enough to ensure you do not need MAC to protect from root.
So, if I put OpenBSD out as a firewall and develop a decent maintenance strategy do I really need MAC? Probably not. Would it be more secure? Sure. I can’t say MAC is a bad idea.
To go again. If the MAC system is implemented correctly then it will be secure. Likewise, if an OpenBSD system is implemented correctly it will also be secure. The only true way to arrive at a solution is to audit them both, giving a great deal of attention to the “proper” implementation of both.
Oh to hell with it. If you port the damn thing (TBSD) I’ll tinker with it and ask you why such and such doesn’t work.
Comment by cyphercell — January 25, 2010 @ 10:12 pm
Hey, I agree with you. People *should* be proactive to try and eliminate bugs in the first place. The problem is that unless you are 100% confident that you have done so, then you should also have a method of restricting what can be done in the event of an intrusion. OpenBSD does not provide this sufficiently.
“From a use case perspective there is at least one instance where my hack is a bit more secure.”
What instance is that? Encryption may solve the OP’s need, but it isn’t more secure, in that having access to the file at all is still less secure than not having any access to the file.
There are also cases where you may want to provide different types of access to people at different times in different groups etc. Encryption is useless for more complex requirements.
“If the MAC system is implemented correctly then it will be secure. Likewise, if an OpenBSD system is implemented correctly it will also be secure.”
In some ways sure, but not ultimately. Ultimately, if both systems are audited and made as secure as can be, the MAC system will always be more secure because it can do far more to limit access. Such as remove the concept of an all powerful user account, which is a horrible concept in the first place.
For a firewall or router or such, I think OpenBSD is probably one of the best choices. For a Database or Web Server with sensitive informative – not so much.
The problem with porting TBSD is that the developers would reject it. That is my issue here, not that OBSD does not have MAC< but that it never will because the developers simply dismiss it as security theater.
Comment by allthatiswrong — January 26, 2010 @ 5:12 pm
One question,
you’ve said:
“you would have to break the root account, the policy account, and any other account that had access to what you needed”
But root is everything, right…so if an attacker breaks root, het can su to the other accounts, right?
Or is it possible to restrict even that with MAC?
Comment by robert — January 27, 2010 @ 9:39 am
With MAC, the all-powerful root account is no longer all-powerful. Policies are created, such that some administration accounts have privilege over some parts of the system, while other accounts have privilege over others. At this point, ‘root’ is just another account that can have privileges given or taken away, based on the policy. The only one who has total control over the system is the one who has physical access.
Comment by Aaron Toponce — January 27, 2010 @ 10:35 am
Yes, Aaron explains it quite well. Basically, on a DAC system you still have an all powerful user account, which makes it much harder to properly implement the principle of least privilege.
With a MAC system, the root account can still be used to set DAC permissions, and to do administrative tasks, but it does not have to be all powerful. You can take any access away from the root account to match your policy.
As an example, you could deny root access to any sensitive files that they should not have access to, while still allowing them access to administer the system as necessary.
You could also separate the root account into a lot of different accounts. For example you could have a network account, and only that account has access to change the firewall or bring up/down interfaces…root would not be able to.
To actually answer your question you can of course prevent root, or any account from suing to another account except for a specified list. You prevent this at the system level rather than by simply blocking access to su, even running any program as another user would be prevented.
Comment by allthatiswrong — January 27, 2010 @ 5:14 pm
Hi Robert,
If you can, have a look at FreeBSD which supports ACL’s and has access to MAC through the TrustedBSD project.
Otherwise, there isn’t a BSD solution to your problem.
Comment by allthatiswrong — January 25, 2010 @ 3:12 pm
Thanks!
I will.
Comment by robert — January 26, 2010 @ 4:29 am
Your claims are laughable. You bash OpenBSD for not being designed from the ground-up with MAC/RBAC, but Linux wasn’t either–al that stuff is bolt-on.
Also a lot of the early Win NT devs had worked on VMS and implemented a lot of the same kind of access controls in Win NT. We all know what a pinnacle of security Win NT is, right?
You apparently don’t know the three pillars of security: Confidentiality, Integrity, and AVAILABILITY. There’s no difference between a bad actor DoSing your server and the server refusing to perform it’s duties because you missed a corner-case when trying to setup the ACL.
Very few Linux distros have SELinux (or equivalent) enabled AND enforcing by default. Even when it is on, it’s the first thing to go when troubleshooting an app. No one is going to spend hours tweaking their access control policy for an app (and having no guarantee that some other unforeseen case won’t pop up) when it could work instantly by simply disabling SELinux.
You’re like a kid with a shiny new MAC hammer and everything in the world looks like a nail to you.
Comment by chort — January 25, 2010 @ 5:13 pm
I agree with all of this article except for those points that have already been mentioned that need to be corrected. I myself with my experience with openbsd and its community find the OS and its community to bitter jackasses that are unwilling to admit their OS has flaws.
Comment by irc.sindustries.org — January 25, 2010 @ 5:33 pm
Dude, the entire point of proactivity is to admit that the OS has flaws, and constantly looking for it… instead of patching when the damage has already been made and then saying “oops”.
Comment by Broom — January 25, 2010 @ 9:50 pm
@chort – Firstly, NT does not have a form of MAC at all. NT has an excellent ACL, and that is all. An ACL allows for more granularity, but it still ultimately DAC, and so your argument has no relevance.
Nor does equating a misconfigured policy with a DoS vulnerability. You may as well equate a misconfigured policy with allowing root access with a stupid password.
@irc.sindustries.org – What points still need to be corrected? I do think I have addressed them now, but would like to address any that still remain.
Thanks
Comment by allthatiswrong — January 25, 2010 @ 5:43 pm
Very entertaining. I think the title should have the word “users” added to it.
Comment by Paul — January 26, 2010 @ 9:42 am
A physically separate entity will only be more secure if either it doesn’t include the same exploitable flaws or isn’t accessible at all. Practice within organizations — ISPs, carriers, data centers, … — is to use the same operating system for as many systems as possible, be it OpenBSD or any other. If there *is* a hole, it *will* be found, and if all it takes is a hole, then the system is not secure, though it might be thought “secure enough”.
The user encrypting files on his own machine *then* uploading it is the *only* way that information can guaranteed to be secured from prying eyes (given a strong enough encryption), mind you, *after* it leaves the user’s computer, which assures the separation of concerns any sane admin would prefer and design according to:
“Your workstation’s security level is not my concern.”
As for the admin role: Either you lock down ability to change policies (say, at installation), or *someone* can change your “secure” system into a public playground. *Who* that someone is is not really important — an admin can get fired, choose to leave, be coerced at gunpoint, etc.
If you want a system that protects information from spreading, encryption is the only (currently) useful technique. That means encryption on a file level, of course, not file system level, as file system level (block) encryption merely protects you should your hard drives be stolen.
The OpenBSD way is a best-of-practice, which is laudable , but formal statistics is not “2 root exploits in 12 years” — that statement proves absolutely nothing. Could be because nobody cared to try. Could be because OpenBSD is typically not employed as platform for the services typically attacked. Add your own alternative explanations ad nausseum.
What it does say is that the developers are proud of their work, and rightly so. It’s a joy to work with within the domains it’s primarily suited for and an inspiration for the people who think security is an afterthought.
Good job, btw, p* off the community. Too bad comments always turn into personal attacks and link dropping.
Comment by Zombient — January 26, 2010 @ 7:48 pm
“Your workstation’s security level is not my concern.”
Thank you. This would be the exact use case I was considering. The author brings up some valid points. He’s offensive and gathers attention and I read some stuff that hadn’t occured to me.
Comment by cyphercell — January 28, 2010 @ 11:25 pm
How am I being offensive? Of course some people will take offense when I criticize something as popular as OpenBSD, but I should be able to do so without being offensive.
Also, I don’t see workstations being terribly relevant here. An EACL can help on workstations such as preventing malware or untrusted programs from having reign, but is quite a different case to limiting access on a server, which is where an EACL really shines.
Comment by allthatiswrong — January 29, 2010 @ 12:49 am
I think it’s possible your writing style has been influenced by trolling on the interwebs. I don’t necessarily fault that, because it can be well done. I think it’s a style of communication born of the Internet very well represented by the comic book anti hero Spider Jerusalem, he’s practically insane communicating what he refers to as “The Truth”, he’s usually quite right, but I digress. I call it a troll because you start out apologizing for the title. Why not delete the apology and change the title? First impressions count and yours is easily confused, it shows in the apology. Perhaps this is just the result of hyperfluid written communication, a hyperfuid written mis-communication rather than a troll? Either way it’s highly ironic that it would be directed at OBSD on this particular subject. A well done troll, though will always play devil’s advocate with popular opinion, with regards to a particular opinion. You’re not necessarily wrong, but no more right than any other fan-boy.
The idea itself could be isolated for a particular use case and specific implementation, so a port outside the tree would be given special consideration. I’m not an administrator, heck I haven’t even used it that much, but I know one of the great things about OSS is the ability to configure things to suit your purpose. Using different users for administration tasks, for example, you might deny the administrative actors physical access to the machine. An example might be the user-based package management system optionally used in Linux From Scratch. I’ve built with the user based package management and it can be quite impressive, solving the problem with a root account installing all the software on the system, as root is allowed to destroy roots stuff. The problem allows packages to interfere with one another. Generally, locking administrators out of a system they have physical access to is a bit awkward, especially if it’s a redundant system that can’t be specifically monitored from a separate physical location. Taking down the back up server and taking it elsewhere is always possible, especially if the system can be quickly replaced as it should be. OTOH, I have absolutely no problem whatsoever recommending Robert use Microsoft if that’s what his particular use case calls for and what he administrates. It sounds though he might be working with a particular system where he is not sure how to solve the problem in that case I highly recomend seeking another solution. However, if the configuration he is looking at is sufficiently difficult to implement elsewhere, he may be better off finding someone to port his software for him. This is really a matter of delegating responsibility to a third party that compliments the situation.
Robert might be better off looking for a developer rather than moving the system to a different platform.
The whole thing is rather theoretical at this point except for one person on this forum and that, by necessity of the subject requires a certain amount of trade secret.
So, the sum total of the argument is that OBSD sucks because it lacks sufficient market share to support this particular feature. I’ve saved money in the past moving DOS based systems to FreeDOS systems, but the problem remains a DOS based system lacks a certain amount of support. The mainstream solution is to buy a new program, but that is not always possible. Likewise, for this particular reason I tend to recomend either Suse Linux, Red Hat, or Unbreakable from Oracle, which 66% of the time required a recompiling of the kernel in order to secure with a MAC system (citing the notorious bug referenced in this thread.) Considering that, Solaris might be a better system than TrustedBSD. Tough pills to go around on this subject, blaming it all on OBSD just reads like a feature request, as was said earlier by paul.
I believe I criticized earlier for not using inline citations. I must apologize for not linking somewhat in this conversation, the tempo allowed me to lose concentration, this all being opinion, I’d like to retract that criticism. The items in particular I did not cite are the physical access statement regarding the NSAs research regarding MAC systems and the assertion that local encryption will always be accessable given a security flaw in the system. To reverse the argument you could say that a secure MAC implementation would solve this issue. The whole is better addressed with specific scenarios and very objective assesments of the assumption of security. OBSDs quote “only two *remote* holes in a heck of a long time” suggest that they are far more concerned with the physical security of the system than other platforms. So, we have two competing lines of thought, one preventing local attacks and one preventing external attacks.
This is where you’re inevitably correct OBSD is lacking a particular security feature, but from OBSDs perspective it’s only been an issue twice in a heck of a long time.
Anyways, it’s been an interesting conversation so thanks for the effort.
Comment by cyphercell — January 30, 2010 @ 6:11 pm
OK, so you have now resorted to calling me a troll. Albeit in a gentle and diplomatic way.
Instead of simply throwing around the word troll because someone disagrees with popular opinion, perhaps take a second to think about what a troll actually is.
A troll is someone whose primary motivation is to illicit a negative reaction from other people by various means. That’s it. While my article did illicit a negative reaction, that was not my primary motivation. My only motivation was to get my point and opinion across, and encourage debate.
Now, you go on to talk about use cases. Yes, people should use software appropriate for each case. I point this out in my article as well, noting OpenBSD is ideal for use as a router or firewall. My argument was against using OpenBSD for anything more than that because of it’s reputation for security. That’s it.
Now, you then go on to say that the whole thing is theoretical. This is nonsense. I have provided real, factual evidence of examples of exploits that MAC prevented, as well as scenarios where MAC would prevent damage in a way not possible with a DAC system.
The fact that Robert came on here with a personal example of the limitations of standard DAC only reinforces my point. Roberts case is actualy very simple – there are many more complex examples where people have to resort to hacks to get around DAC, when in a secure system this would not be necessary.
Also, I never once said OpenBSD sucks. I compliment the project in my article. The security aspect however, I do think is bunk. OpenBSD is excellent quality, which as less vulnerabilities as a result. This doesn’t mean it is secure.
I’m also not blaming OpenBSD because of a lack of a feature. I am attacking the point of view held by the developers(see references) that technology is useless, and just security theater. Even the OpenBSD proponents in this thread can admit that an EACL can grant better security, something the OpenBSD developers refuse to acknowledge after 10 years. To read an attack and criticism as a feature request takes a special kind of insight, I’ll grant you that much.
I don’t really understand how your reasoning lead to one platform being concerned with preventing remote attacks, and one being concerned with preventing local attacks. OpenBSD are only concerned with remote attacks – that’s it. A proper EACL will allow you to prevent both. Since you disagree, I would appreciate if you could elaborate on why.
I find the attitude of the OpenBSD developers inexcusable. To say that EACL systems are simply security theater shows a poor understanding, not simply a difference in philosophy. If they said they wanted to keep their system simple because it was better to audit, so while EACL systems have benefits they don’t fit in with the OpenBSD teams goals, I probably wouldn’t have been inspired to write the article in the first place.
As for remove the apology and changing the title, no way. The title is accurate, as I am talking about the insecurity of OpenBSD. I.E. the ways or situations in which OpenBSD can not be said to be secure. I wrote an apology to help mitigate the fact that too many people will simply jump to a conclusion of taking “the insecurity of openbsd” to mean “openbsd is insecure”, not because the title is inaccurate.
Thankyou for taking the time to write quality comments however. I, and I’m sure whoever may be following this discussion appreciate it.
Comment by allthatiswrong — January 30, 2010 @ 8:23 pm
Meh, Theo De Raadt’s a troll so you’re in good company. A lot of people consider Stallman a troll, it’s not necessarily an insult. Besides, I didn’t say you were a troll, I said the article was trollish.
Anyways, it would be interesting to see this argument after a port was made, then you’d have peoples attention.
Comment by cyphercell — February 1, 2010 @ 2:32 am
FWIW, I think if the OpenBSD developers were to actually learn about the technology ad concepts instead of dismissing them, OpenBSD could be the most secure OS around.
Comment by allthatiswrong — February 1, 2010 @ 6:14 am
Uh, what makes you think they _don’t_ know, in intricate detail, what your suggested technologies are and does, only they’ve chosen not to use it? The OpenBSD devs are highly skilled and experienced programmers and designers. They just didn’t come to the same conclusion as you have about the added benefits in balance with the added costs. That doesn’t mean they don’t understand the technology.
Comment by Meep — May 20, 2010 @ 3:37 pm
Hi Meep.
The reason I don’t think they understand the technology, is because of the comments they have made on mailing lists talking about it. I have a few key messages in my list of references shoing this. A good example is the message by Marc Espie stating MAC does not provide any additional security.
If you understand the technology, then it is impossible to come to that conclusion. It isn’t just different – its plain wrong.
I know that the OpenBSD developers are talented, but there is nothing to indicate that are knowledgable about security. Unfortunatly, despite what the OpenBSD developers may think, code quality is not synonomys with security,
It would be one thing if the developers gave a rational rejection of the technology, but they don’t. They reject something that they don’t understand as being needlesly complex, while being ignorant of what the technology is capable of or why it is used.
You can check the 2007 “SELinux Vs OpenBSD” discussion to see this, where they seem to be under the impression that MAC is simply DACv2 or something. If the team had shown they do understand it, and explained it was not useful for the goals of their project rather than attacking the technology, I probably would not have written the article.
Comment by allthatiswrong — May 20, 2010 @ 10:56 pm
I myself am an OpenBSD user, although not nor ever have been an admin. I don’t know whether or not that is relevant, but it may put my comments into context. I study cryptography, at an amateur level, on my laptop. So my experience with OpenBSD has been solely from a “workstations” perspective
I found the article to be very informative, and compliment allthatiswrong for his/her’s obvious grasp of the technology which they speak about. Also im slightly disappointed in the lack of serious counterpoint to the article, with cyphercell and parts of daniels responses being notable exceptions.
Security is a process not a product. I appreciate OpenBSD’s holistic approach to security, and their mindfullness in implementing it across all the component parts of the OS (documentation being a good example). To be truthful, i actually use OpenBSD not for the security, but for the integrated cryptography technologies developed by the project, and for its adherence to its principles of simplicity and maturity. Note that while these last two qualities are intrinsic in the proper application of the former, i beleive they stand on their own merit as requisite components to an ideal OS (“ideal” used here in the sense of ideal for your needs, your mileage may vary).
I can see very plainly the benefits of a properly implemented MAC framework, and not just a “thrown together/bolted-on” selinux implementation as many people seem to enjoy jumping on, however i still cannot understand how the resistance of such frameworks invalidates across all deployments the security of OpenBSD.
MAC is not a magic bullet, nor is OpenBSD, however when considering the implications of any given security solution across the wide variety of needs, OpenBSD deserves as much merit as it has gained.
I understand your intention was not an attempt to claim OpenBSD as in anyway “hackable despite claims to the contary”.
The title of your post was validated in your first paragraph and you have gone on further since to qualify this as an opinion piece, so i understand the aim of an incendiary title to encourage debate.
But i guess what it comes down, really, is that OpenBSD works for me, and many others. It presents real, provable, reliable solutions to wideband security concerns.
But then MAC provides an elegant solution to granular security concerns. 😉 So we come to the conclusion, which i merrily paraphrase from Bruce Schneier, security is a process, not a product.
Choose a glove which fits.
Comment by Lionsong — January 29, 2010 @ 7:37 pm
Hi Lionsong,
I just wanted to thank you for the kind compliments, and providing a well written and interesting perspective.
Cheers 🙂
Comment by allthatiswrong — January 29, 2010 @ 8:39 pm
[…] reading here: The insecurity of OpenBSD « All that is wrong with the world… Posted in: Bug Report ADD […]
Pingback by The insecurity of OpenBSD « All that is wrong with the world… | Linux Affinity — January 30, 2010 @ 2:55 am
Your welcome, the day everyone agrees is the day no one thinks for themselves.
FYI as an aside – from my understanding the “2 root exploits in 12 years” claim expanded on by zombient, while i agree completely with him/her that such a claim at face value has no value at all, is in fact derived from the internal code audit done by the OpenBSD team, cross referenced with the number of known bugs tracked in the same software used in the “wild”. Basically i think its meant to read “we’v only broken in ourselves twice”.
To keep this short ill only briefly mention that in this pro activity in finding flaws that i applaud the OpenBSD team. Not to say this effort is not mirrored by other developers, but for OpenBSD it is made extremely sympathetic to the other elements of the OS, and finely integrated into much, if not all, of the project.
Comment by Lionsong — January 30, 2010 @ 7:29 am
>Basically i think its meant to read “we’v only broken in ourselves twice”.
Au contraire – those bugs were found by outside sources.
http://www.iss.net/threats/advise123.html
Exhibit A – disclosed by ISS X-Force.
http://www.coresecurity.com/index.php?action=item&id=1703
Exhibit B – discovered by Alfredo Ortega of Core Security Technologies.
http://www.milw0rm.com/exploits/8406
Exhibit C – discovered by milw0rm.org.
Need I go on?
Comment by thirdwheel — January 31, 2010 @ 11:37 pm
Well i certainly didnt claim it was the outright truth, so your gun-ho response is a little premature. But i do enjoy being proved wrong about stuff as it means i learn something new! Thanks for the links and the info!
Comment by Lionsong — February 1, 2010 @ 10:51 am
That’s why there is nothing in the chroot, like OpenNTPD does and the slew of other default daemons. Yes, pending any local exploits to gain extra privileges, the bugs are contained. Just like a MAC. Pending any bugs in the MAC implementation, bugs are contained. You’re blindly trusting the MAC and you’re missing that OpenBSD simply took a different approach. This is because in OpenBSD, local privilege escalation bugs are rare, unlike in Linux. Two different approaches to security for two very different development models.
Comment by Link by umeee — February 5, 2010 @ 8:46 am
You”re not Daniel again by any chance are you? He said basically exactly the same thing above.
Anyway.
You either don’t understand the relevant technology or theory, or are ignoring it to advocate OpenBSD.
OpenBSD has NO means to contain a successful breach, only to mitigate the attempts. In the event of someone successfully getting root, that’s it.
You can’t simply say that it is two different approaches for two very different development models.
The adoption of EACL technology is by no means mutually exclusive with writing quality code and auditing for bugs..indeed, they go hand in hand.
The problem here is with the OpenBSD developers consistently and repeatedly dismissing EACL as security theater when it is anything but.
DAC is useless if you want to actually secure systems, and while it may be fine if your only concern is preventing remote code execution, a secure system needs to be able to protect against far more than that.
Comment by allthatiswrong — February 10, 2010 @ 1:26 pm
[…] si es informático o un friki de esos, no aparecen datos sobre él) escribió esta semana “The insecurity of OpenBSD” acusando al sistema del pez globo de contar con menos herramientas de seguridad de las […]
Pingback by ¿Si OpenBSD no es seguro qué lo es? | LXA! Linux Adictos — February 14, 2010 @ 2:18 am
Whining about old versions of sendmail and bind does not make a convincing argument. But you know how to start a good fight.
Comment by Arthur — February 23, 2010 @ 11:37 pm
As observed, 99.999% of people disable SElinux and other MAC subsystems during first install 🙂 even on server systems.
Comment by Mimmo — February 24, 2010 @ 4:05 am
Thanks for the well-written, thought-out article.
Comment by Deskin — March 17, 2010 @ 1:26 am
Yeah, this reads like a feature request. I agree, OpenBSD could be made into a more fully featured server with additional ACL, MAC, filesystem, multiprocessor work. That’d be great. I also agree that at current it’s best at standalone implementations like routers and firewalls. That’s where I use it.
From a larger scope, security requires manageability. Complexity is the enemy of manageability. Adding features has the general effect of increasing complexity, and subsequently reducing security. This is why this article is weak. It fails to address and support the idea that the additional complexity of MAC, EACL, etc. provides greater security than what is naturally lost through increased complexity.
@AllThatIsWrong, you seem intelligent enough to be interesting, but this article (and your subsequent comments) are too inflammatory to allow for proper follow-on discussion.
Comment by theed — March 31, 2010 @ 9:54 am
Hi Theed, thanks for your comment.
I’m really don’t get how you can read a criticism of the developers and userbase as a feature request. Yes, the lack of EACLs was a main attack point, that doesn’t make it a feature request. Any such feature request would be doomed from the start since the developers have rejected the idea from the very start. Criticizing a product for not having a certain feature is not the same as requesting that the developers implement that feature. Although I suspect you’re smart enough to know this.
As for your comments RE complexity, it is a myth that an extended access control framework must be complex. I have provided many examples that are not. It seems most people only have experience or have heard things about SELinux which they let shape their opinions. The OpenBSD developers in the past have made simple secure versions of software others considered complex, such as pf.
I think I have made it obvious in the article that the increase in security provided by EACL’s far, far outweighs the increase in complexity which can be negligible.
My article is going to be taken as inflammatory, but it is not intended to be, nor are the comments. However when the development team and userbase continually misunderstand and reject the technology, then it takes extra work to get the point across. Even so, I disagree that the article and follow on comments are inflammatory enough that they detract from the point. The discussion made up of some 200 comments gets a bit childish in parts, but it is mostly interesting and worth reading, IMO.
Comment by allthatiswrong — March 31, 2010 @ 7:31 pm
Openwall is not an abandoned project. That fact, at least, is absolutely untrue.
Comment by Vincent Danen — April 14, 2010 @ 7:20 pm
Hi Vincent,
You’re absolutely correct, and that’s a big mistake on my part. It was poor research on my part, noticing they were not using the 2.6 kernel and not having heard anything about the project for a long time.
As you say the project is still alive and active, with the last release being just a few weeks ago. I will correct this ASAP.
Thanks for pointing that out.
Comment by allthatiswrong — April 14, 2010 @ 11:44 pm
[…] The insecurity of OpenBSD (tags: openbsd security toread) […]
Pingback by links for 2010-05-20 « Mandarine — May 20, 2010 @ 11:07 pm
What allot of viewers miss is that the article assumes OpenBSD in an SECURE environment. Hence the title. If you want to properly compare the top speed of two cars, you’ll have to push them to the max. Yes you wont be driving 240km/h on a normal road, but its the only way to see which car is fastest. Something with propper MAC policy is more secure then OpenBSD? Yes. Is it economical? Thats a different debate.
Anyways, OpenBSD is nice for an firewall, but what about being a webserver? OpenBSD has apache installed by default and uses a chroot to secure the webserver. I think it would be reasonable if you don’t have enough time to implement a MAC.
I haven’t touched trusedBSD. Anyone knows if there is some advantage between SELinux and TrusedBSD?
Comment by Dave — October 15, 2010 @ 5:08 am
Hey Dave,
It’s an interesting point you make, because the OpenBSD team and their fans all claim that the default environment, that whole “Secure by Default” crap.
I agree with your point that OpenBSD is a pretty secure solution in many contexts. I didn’t write the article to dispute that, bur rather the people who think OpenBSD is secure in *every* context and that MAC is useless.
TrustedBSD is essentially a port of SELinux to FreeBSD. It should be equal in functionality and will just be a bit behind SELinux most of the time.
Comment by allthatiswrong — October 15, 2010 @ 2:43 pm
It find it interesting how many people said “but Linux isn’t any better!”. Come on, I’d expect better from the sacred elite of ubercreatures that are *BSD users than such pathetic “argumentation”.
@ the author:
Thanks for the much-needed slapping, OpenBSD needs it.
(BTW, English isn’t your first language? You really do repeat too much, but that’s a style-issue and not a content one (pointing out the obvious for the people who can’t seem to get past that).)
Comment by j — November 2, 2010 @ 1:26 am
You mention that TrustedBSD is a port of SELinux, but are you aware that TrustedBSD’s initial announcement was on April 9, 2000, while SELinux was released to the open source community on December 22, 2000? And that many technologies from TrustedBSD may also be found in OpenBSD and Linux.
OpenBSD is secure by default, meaning there aren’t any remote holes in a default install. The base system includes Apache, Bind9, dhcp, pf, OpenBGPD, OpenOPFD, Sendmail, OpenSMTPD all of which are audited and free of exploits. If you don’t need any third-party apps, then a base install makes your system reasonably secure; far more secure than a default install of a Linux distribution. Reading the US-CERT vulnerabilities weekly, there are numerous citings of Linux, but strangely there aren’t any for OpenBSD.
Comment by AIX Guru — November 9, 2010 @ 2:09 pm
Mwahah. That’s hilarious. Standard BSD vs Linux fanboy flamewars.
First, read it and weep: http://www.kb.cert.org/vuls/byid?searchview
Looks like plenty of vulnerabilities for OpenBSD.
Also, it’s apparent you didn’t read the article, nor follow up with any of the discussion. You just assume that OpenBSD is more secure by default, even though we’ve shown that there is no reason to believe so. Especially when MAC systems are deployed.
Read the title, then decided to comment, did you?
Comment by Aaron Toponce — November 9, 2010 @ 9:47 pm
There were only 5 from 2008 and 2009 and none from 2010. None of them were in the base install which makes their “secure by default” stand.
Besides, most implementations of MAC are half-assed, meaning they likely leave more holes than not implementing it to begin with.
Also, in 16 years in IT in a number of different companies, including a few Fortune 500 companies, never has MAC been implemented or used.
So unless you can exactly show me a vulnerability in the default install of OpenBSD recently, then I will assume you are unable to do so and that the claim “secure by default” does indeed have merit.
Comment by AIX Guru — November 10, 2010 @ 9:01 am
And what does that mean for me, who works as a contractor for a major department in the United States government where MAC is implemented on _every_ RHEL installation in production, and most in development? I guess empirical evidence doesn’t go very far, does it?
Comment by Aaron Toponce — November 10, 2010 @ 10:20 pm
Generally when arguing a point, it isn’t good to get your facts from an obvious biased source. Looking [url=”http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openbsd”]here[/here] it seem there were 7 for 2009. Quite a few which should have been caught by the teams auditing, at least that is the claim made.
It is *EXTREMELY* disingenuous to dismiss a DoS attack as just a reliability fix. DoS attacks are consider a security problem for good reason, not least because many can lead to arbitrary code execution.
The OpenBSD team has been criticized for this and shown this for the last 10 years at least. They dismiss a vulnerability, only to have someone write a PoC hoping they would get the point. Anyone remember Gobbles?
You also show your ignorance by claiming MAC is never used. I understand you appear to be someone who uses anecdotal evidence to understand the world, so I’ll just point out that it has been used consistently over that time albeit in limited situations, however adoption is picking up because we realize DAC is simply inefficient. OpenBSD is pretty much the only project that says differently.
Also, if you think “secure by default” equates to having no vulnerabilities, then you have a fair bit of reading to do.
Comment by allthatiswrong — November 11, 2010 @ 4:33 am
TrustedBSD did indeed start before SELinux. When I refer to TrustedBSD being a port of SELinux, I was referring to the FLASK implementation being ported from SELinux. I will clarify that above.
No technology in TrustedBSD is found in OpenBSD that I am aware of, although many are in FreeBSD. The OpenBSD team rejects anything that can offer a significant increase in security if they can’t be bothered to understand it.
“Secure by Default” is meaningless in that many operating systems can be considered secure by default these days, and that a) base system is not clearly defined, and even OBSD users disagree over what it means, and b) the OBSD team redefine what they consider to be a vulnerability.
You may well need third party software, because a lot of the software OBSD includes in base while audited, is many generations behind.
Comment by allthatiswrong — November 9, 2010 @ 9:52 pm
A base system is the installation from CD with no additional packages added afterwards.
Secure by default isn’t meaningless. And certainly Windows and Linux are not secure in their default installations. Windows always has a vulnerability in IE or somewhere else, and Linux has too many apps and packages installed by default which are not audited. In two of the last three US-CERT bulletins, there were vulnerabilities in the Linux kernel.
I run OpenBSD with only one additional third party package, NSD, otherwise, I run Apache 1.3, dhcpd, and the other base packages needed.
Comment by AIX Guru — November 10, 2010 @ 11:51 am
Can you give me a link to an explicit definition of base system on the website? I understand what many people consider it to be, but there is no single cohesive definition. Going by your definition, if I run “nc -l -p 5555” is that still only the base system, and so still secure? If not, then it can no longer be the base system after *ANY* configuration, right?
Secure by default is meaningless. It is definitely a good practice and I do respect OpenBSD for adopting that philosophy far in advance. However, most decent OS’s these days are secure by default in that they have only minimum services enabled, a firewall etc. Obviously some more than others, but we have moved in that general direction.
You seem to think “secure by default” refers to a codebase free of vulnerabilities. This is false – it refers to the default configuration after install.
The reason I consider “Secure by default” somewhat irrelevant is because most people will need to rely on software outside the port tree. What if you want a secure webserver, but explicitly need Apache 2?
Then all that auditing goes out the window, and you have no way to protect your system in the event an attack is succusfull.
Contrast with MAC, where the same exploit would be rendered ineffective. The webpages could not be defaced. There would be no execute permission. Even if you got root, root wouldn’t be able to do anything.
The security aspect of the Linux development model is appalling, but this article is not saying Linux is more secure than OpenBSD. It is saying OpenBSD can not be considered a security focused OS when they continually dismiss and misunderstand MAC.
Comment by allthatiswrong — November 11, 2010 @ 4:43 am
“You seem to think “secure by default” refers to a codebase free of vulnerabilities. This is false – it refers to the default configuration after install.”
That is correct. This is what it means. This also means that a vulnerability in the base system on a daemon that is not enabled by default does not count as a remote vulnerability out of the box. If you have enabled that daemon, then it is no longer the default.
However, things like W^X are enabled out of the box as well. So, for the Apache 2 example, it still benefits from the exploit mitigation techniques that OpenBSD uses. Whether or not that means anything to you is another story.
Comment by Frank — November 19, 2010 @ 10:23 am
“If you have enabled that daemon, then it is no longer the default.”
That’s kinda my point. “Secure by default” is a great policy, but it is utterly meaningless when talking about security in any practical context.
I am aware of exploit mitigation techniques and of course they are a great help, the point I am making however is that OpenBSD doesn’t provide anything to help in the case of a successful exploit.
Comment by allthatiswrong — November 21, 2010 @ 8:08 pm
Meh. Apparently, you can’t have a URL with a unique search. Search ‘OpenBSD’ on the site, and you’ll get a lengthy list.
Comment by Aaron Toponce — November 9, 2010 @ 9:50 pm
You seem to misunderstand that an incorrectly configured MAC implementation like SELinux can lead to more problems that if it wasn’t installed.
Comment by AIX Guru — November 12, 2010 @ 11:27 am
You could say that about anything. The fact is, the chance for problems are negligible, while the increase in security is significant.
Comment by allthatiswrong — November 13, 2010 @ 2:53 am
FYI: Capsicum provides capabilities for Unix (backported to FreeBSD8, planned for FreeBSD9, and being ported to Linux) – this gives much improved usability and security over MAC and DAC solutions by providing OS supported least-privilege enforcement.
Comment by Michael Heyman — December 13, 2010 @ 8:39 am
Now this hits the fan:
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
Your post is almost prophetic. Of course, if the backdoor exists, there’s nothing a MAC or DAC solution could do for something like this. Still, interesting timing.
Comment by Aaron Toponce — December 15, 2010 @ 3:08 am
Well,
if you asked me, this new issue about the IPSEC backdoor just shows how serious OpenBSD take their proactive security.
They immediately made it transparant from their point of view and I do trust them to take measures if this claim is true.
So although I somehow agree with the tendency in this blogpost, I do regard OpenBSD as one of the most secure systems out of the box.
They would off course be even better if they would consider a clean and easy implementation of a framework that could assis administrators in the case a (regular) user or deamon gets compromised.
For me, after I have been aware of the possibilities MACseem to offer, I would welcome such a add on, and if it would come from the same guys that gave us openBSD, openssh, pf…..that would be even better.
OpenBSD could be considered a fortress, which would fall if somebody happened to break through. What this blogpost showed is that they could consider adding some modifications to the fortress that even in the case of a breach, all would not be lost. Like a ninja style castle with hidden corridors, traps and escape routes.
Comment by robert — December 15, 2010 @ 4:33 am
Hey Aaron,
To be fair, MAC would not help in this situation nor would any particular permissions model.
The problem is that the key slowly gets leaked overtime, which can only be fixed in the code itself.
Still if nothing else it shows that it is not wise to rely ONLY on auditing code, even if the story is not true.
Comment by allthatiswrong — December 15, 2010 @ 4:50 pm
Yes, I said that in my comment:
Of course, if the backdoor exists, there’s nothing a MAC or DAC solution could do for something like this.
Comment by Aaron Toponce — December 17, 2010 @ 4:53 pm
Huh! No idea how that didn’t register, sorry about that!
Comment by allthatiswrong — December 17, 2010 @ 5:57 pm
It is unlikely this exists. First the claimant said his NDA expired, so now he can divulge the information. There wouldn’t be an NDA for something like that if it was for the FBI, CIA, NSA, NRO, DISA, or any other national security/intelligence agency.
If it does exist, then don’t use IPSEC and tunnel through SSH.
Einstein said “Make things as simple as possilbe, but not simpler.”
Comment by AIX Guru — December 27, 2010 @ 11:26 am
It’s looking more and more like it didn’t happen. If the backdoor was added, it likely didn’t make it into the main tree.
Comment by Aaron Toponce — December 27, 2010 @ 6:23 pm
It would be nice if they could prove this by actually finding the backdoor in the source code instead of just speculating.
Comment by Dave — December 29, 2010 @ 3:29 am
Nevermind, they found 2 bugs but it weren’t backdoors…
http://marc.info/?l=openbsd-tech&m=129296046123471&w=2
http://cryptome.org/0003/fbi-backdoors.htm
http://mickey.lucifier.net/b4ckd00r.html
Comment by Dave — December 29, 2010 @ 3:56 am
How can you find something that doesn’t exist?
http://www.informationweek.com/news/security/vulnerabilities/showArticle.jhtml?articleID=228900037
Comment by AIX Guru — December 29, 2010 @ 9:19 am
You’re more than welcome to help the team find the backdoor. Should be more productive than complaining.
Comment by Aaron Toponce — December 29, 2010 @ 11:02 am
incorrect
Comment by dave — February 2, 2011 @ 10:07 pm
Whilst I started using OpenBSD because of the secure-by-default install and heavily audited code and track record, I must say I can agree with the basic idea of the article.
Correct me if I am wrong but the point is not that OpenBSD is insecure, but rather the *applications and services* make the system as a whole insecure. I agree with that.
I also agree that, with few methods of locking the system down and isolating the attack/confining it, any such security-by-default paradigm is quite useless.
Of course you can have the world’s most secure operating system without any flaws or bugs, but what good is such a system if you cannot use it without the risk of the application/service you use causing a mess?
I would love to see ACLs implemented. Even Windows NT has a complex set of ACLs which make it relatively safe when setup correctly.
I would not mind on top of that being able to configure what user the service/daemon runs under, or what user group it runs under anyway. This would probably help a lot too.
Sure OS security is important and OpenBSD already achieves OS level security. But anything which requires complex access controls to be setup… forget about it.
On to physical security… their disk encryption scheme isn’t too easy to set up either – and if you want to use a passphrase you cannot eliminate the “Passphrase:” thing or replace it with “Enter to continue” or whatever. You would think it would be quite easy given their security focus but their tools are not very mature. Though in their defense again, I have seen a big improvement in the softraid driver.
So to sumarize – remote vulnerabilities in the base OS mean nothing if the services have a vulnerability AND there is no way to prevent the attack from spreading. Not sure about the rest of you but at least if the attack is contained then at least it gives you time to move the other data on the server to a safe place while you sort the issue out? I am impressed with the OpenBSD approach to security but I think it should not be the only approach.
S
Comment by Thunder God Johnny — September 7, 2011 @ 9:09 am
I should add that given my background of knowledge is NT oriented I am open to discussion and could be wrong about this too.
Kurt Seifried has two articles on similar matters already as well:
“Why OpenBSD will never be as secure as Linux” – http://www.seifried.org/security/os/20011107-openbsd-linux.html
“Why Linux will never be as secure as OpenBSD” – http://www.seifried.org/security/os/20011107-linux-openbsd.html
Both from Kurt himself and they are worthy of a read.
Comment by Thunder God Johnny — September 7, 2011 @ 10:07 am
What a joke. Remember when for 2 years Debian and all of it’s clones/branches were vunl to SSL sniffing because in 2006 Kurt Roeckx commented out two very important lines of code in the OpenSSL pseudo-random number generator? For TWO YEARS Debian used 15 bit entropy in any crypto key it generated.
To this day you can retroactively seek out DSA signatures generated during the vulnerable period and use them to recover the private key easily. What’s the point in your l337 MAC/SELinux setup if I can just decrypt your 15 bit SSH key and log in as root?
Comment by lolz lul — January 16, 2012 @ 3:24 am
Uhm, because I don’t need SELinux or any MAC to prevent SSH logins as root, for starters. And second, using a MAC/SELinux setup, I can squash root privileges to obvlion, using RBAC models. Seriously.
Comment by Aaron Toponce — January 16, 2012 @ 4:55 am
What has a vulnerability in Linux got to do with OpenBSD refusing to implement more granular access controls like SELinux?
Comment by allthatiswrong — December 11, 2012 @ 3:40 am
This article is a big gift for BSD beginners.
Gives a lot of important information.
Must be read by everyone in the field.
THANKS!!!
Comment by eran — January 20, 2012 @ 2:07 am
> Since the majority of attacks are not against the base system but against software operating at a higher level actively
> listening over the network, it is likely that if an OpenBSD machine were attacked, it would be through such software.
> This is where OpenBSD falls down, as it provides no means to protect from damage in the event of a successful attack.
What BS! You don’t seem to be aware that OpenBSD lead the charge years ago for “priv sep”, and to this day installs
every single ‘ports/packages’ daemon with a distinct, non-privileged userid – a good idea which not only proves that your
statement above is based on ignorance, but provides “secure by default” a strong measure of what the formal approaches claim to offer
but make complex to implement. And it’s also been copied into leading Linux distributions, e.g., Android does exactly the
same thing for every app you install.
Comment by Ian Darwin — February 23, 2012 @ 12:25 pm
You missed his point. The attack is already successful. Privelege separation or not. Apache was PWND. Now what? Without a MAC framework in place, the system falls. And that is the whole point of the post. OpenBSD is “secure by default”, so long as you don’t put anything on the open Internet. As soon as a service is listening to the world, OpenBSD is only as secure as that service, which is your weakest link. Put something like SELinux or grsecurity into the kernel, and you have a hardened layer to work at now that you’ve taken control of the service.
Comment by Aaron Toponce — February 23, 2012 @ 11:01 pm
http://forums.grsecurity.net/viewtopic.php?f=7&t=2939
My favorite quote is “failure of SELinux to prevent exploitation”. Also, if you consider the PaX (and not just RBAC) portion of grsecurity as “a hardened layer to work at”, then you shouldn’t be dismissing the OpenBSD exploit mitigation techniques so quickly. While OpenBSD doesn’t offer something with as complete a feature set as grsecurity, what they do offer still makes exploitation difficult. Furthermore, it just works and is enabled out of the box for everything (base, xorg, packages). The same cannot be said for mainstream Linux distributions.
Comment by Brian — February 28, 2012 @ 5:09 pm
I don’t dismiss what OpenBSD has, it’s just that they have nothing that helps if an attack is successful and access is gained.
Comment by allthatiswrong — December 11, 2012 @ 4:10 am
Put something into the kernel which has vulnerabilities itself, like SELinux, and you compromise your system. There is a known SELin ux vulnerability and there are likely thousands of systems to this day that are exploitable because they never applied any patches.
Plus, SELinux is complicated enough that misconfiguration is likely to aide in exploitation as much as prevent exploitation.
That is nonsense that putting OpenBSD on the Internet in insecure because a service will be exploited. The base install doesn’t have any exploits. The base install includes Apache, Sendmail, DHCP, and other services. Apache may still be version 1.3, but it has been audited and has had some code modifications to enhance security.
Linux with or without SELinux has more vulnerabilities than OpenBSD. Check out US-CERT to see the insecurity of Linux.
Comment by AIX Guru — March 17, 2012 @ 4:59 pm
You should know better than to use vulnerabilities as a metric for the entire security of an OS. It’s easy to audit the MAC framework that would be integrated with the kernel, and besides it can be formally verified.
How exactly could SELinux aid in exploitation? That’s a strong claim.
Comment by allthatiswrong — December 11, 2012 @ 4:12 am
All i have to say to this is… LAWL
Comment by forgottentq — April 19, 2012 @ 1:57 pm
Wow. This is still going. I just thought I would add; ACLs aren’t going to be feasible for certain things like printer ROMs. You really have no choice but to code correctly. Sometimes a printer is all it takes for a launching/pivoting point.
Comment by Justin — May 25, 2012 @ 8:58 pm
delete this thread, moderators
Comment by dattyanent — June 6, 2012 @ 1:22 am
It’s difficult to find experienced people about this topic, however, you sound like you know what you’re talking about! Thanks
Comment by linux for security — June 24, 2012 @ 6:19 am
Very nice post. I absolutely love this website. Keep it up!
Comment by linux for security — November 3, 2012 @ 9:57 am
unfortunately this comes up #1 in search results so I will clear everything up
===================
Adding complexity, reduces security. Full stop.
http://www.schneier.com/blog/archives/2013/01/complexity_and.html
Read Schneier’s 1999 essay, it still holds true to today. The more complex your system (Protip: the linux kernel and SElinux are extremely complex into the multi millions of lines of code) the less security you have.
===================
The SElinux devs themselves point out SElinux does not protect you from linux kernel vulnerabilities.
Here’s a talk given by the NSA about SEAndroid, which is an SElinux patch for Android (and operates exactly the same as SElinux in terms of kernel policy/patches) and he repeats again how if there’s any kernel vuln, you are screwed: http://packetstormsecurity.com/files/108737/caseforseandroid.pdf
SElinux solely exists because the linux kernel was so insecure the NSA felt obligated to write a patch. They really don’t like using proprietary software at the NSA, so in order to even consider linux a very complex patch had to be written. Sadly, for most administrators the policy and language is so complex they simply turn SElinux off. You have to be very vigilant in updating and auditing security policies and many times stuff will just fail and there’s nothing in the logs to say why because it was a hurried patch just to get the kernel some sort of protection so plenty of error documentation is simply not there. I know because I used SElinux everyday for over 10 years, and now am forced to use it to secure handsets.
How many vuln are in the linux kernel? Go look at the kernel bug tracker. As of this post, there are 1893 bugs in 29 days, many of them still open. They find bugs all the time. Linus Torvalds does not code the kernel for security, he never has nor does he want to. Linux kernel is coded for usability and features. Now throw in all the various distros and you have a nightmare of complexity interacting with an exponentially complex kernel.
====================
MIT professor Nickolai Zeldovich helped design and code this operating system while he was at Stanford, specifically to reduce system complexity and lines of code in the kernel:
http://www.scs.stanford.edu/histar/
It uses MAC and taint tracking. Now download the code and read every dev text file. Note how even their tiny operating system grew to out of control complexity because of the MAC. Propagation of errors galore. Eliminating bugs and vuln from the x86-64 arch has been going on for decades and still nobody has been able to do it. When you have a solid understanding of how the arch works you’ll understand why this is so near impossible to do, UNLESS you design from scratch to reduce complexity and use priv seg wherever you can, which is what OpenBSD does
=====================
OpenBSD doesn’t need these controls because of proper priv seg. This is why whenever you hear about yet another X vuln it doesn’t affect OpenBSD because of how they’ve separated the running process from users. Linux doesn’t have this, no distro I know of does it.
======================
A Debian developer once commented out a small offending line in openssl that was giving errors. It stopped giving errors so he told nobody and called it a day. Two years later they found this out: http://www.schneier.com/blog/archives/2008/05/random_number_b.html
This is no ‘oh well no harm done’ kind of error. This is a major security lapse that existed from 2006-2008. Welcome to the world of linux development. Again, it’s never been nor has it aimed to be coded for security. Lot’s of lessons were learned, but it’s likely to happen again the entire dev process of most linux distros and the kernel is a fast release cycle with a revolving door of contributors
=======================
Conclusion: Is OpenBSD perfect? No of course not. But it’s literally the best current O/S anybody has in terms of clean audited secure code and who’s developers code using a sane process to reduce complexity. Don’t believe me though, believe their track record and believe what your computer science professors are telling you about complexity and insecurity.
If you play games, go on facebook to circle jerk with your friends and that’s the entire limit of your online exposure then go for any linux distro. If you are running servers, firewalls, or are up against a very strong adversary like a government then you should be using openbsd base with no X in full terminal mode.
The game has changed. There’s now corporations out there that broker 0day vuln to governments and law enforcement and these vulns are not being reported to the maintainers. SElinux, grSecurity and apparmour are not going to help you when you’re up against the likes of criminals, Vupen and thegrugq trading X11 and kernel 0days by the dozens to spy agencies and law enforcement, who in turn are leaking it to their Chinese, Bahrainian, Yemeni and European/Aus counterparts.
http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
Comment by freeweev — January 29, 2013 @ 8:20 pm
“…who’s (sic) developers code using a sane process to reduce complexity.” — that isn’t entirely true. I use OpenBSD’s pf for my firewall, however, I’m looking into NetBSD’s npf. And reading on npf you will see references to pf that the code is messy and not easy to clean up. Certainly this isn’t good.
“Buit it’s literally the best current O/S anybody has in terms of clean audited secure code…” — point me to a published audit of OpenBSD other than Theo or some other OpenBSD hacker who says this. Tell me what audit method is used, because that information isn’t released either.
Comment by AIXGuru — May 6, 2013 @ 1:24 pm
freeweev
You aren’t cleaning up shit. SElinux exists because DoD systems require MAC. The government doesn’t just do things to make the world a better place.
Comment by Justin — August 4, 2013 @ 12:57 am
AIXGuru
You are mistaken if you think OpenBSD is trying to hide anything from you. You really need to read the history of OpenBSD and perhaps you will understand the precedent for transparent development which OpenBSD paved the way.
Comment by Justin — August 4, 2013 @ 1:02 am
You have no idea what secure OS means …
Comment by john — November 19, 2013 @ 6:38 pm
This is a good discussion of the overall trend toward capability-based security. When we finally have our
perfect OS it might not matter unless we have also fixed the growing OOB hardware vulnerability of
critical servers, which seems a mere subset of the “internet of things.”
Comment by callie — September 3, 2014 @ 6:03 pm
Microsoft Windows has inherited ACL from Daytona/Windows NT. Yet if you start it in a VM and lesve it for a few days it will have a virus of some kind.
So I fail to see a dirrct connection of the use of finre grained access control and overall system security in the way you assert.
I have to conclude that there is no practical connection between the two in the way you asset and reject your argument.
Comment by Keith — February 21, 2015 @ 11:42 pm
Dang.
Comment by allthatiswrong — October 30, 2016 @ 1:48 am
[…] https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ (artikel komprehensif satu halaman yang bagus memperkenalkan OpenBSD secara global) […]
Pingback by Kumpulan Pranala Sistem Operasi BSD | RESTAVA — March 6, 2015 @ 11:27 pm
[…] a look at this article all that is wrong. Basically secure by default means at time of release, the system has been audited and is believe […]
Pingback by Unix:Why does time/ident/daytime/comsat run after an OpenBSD 5.2 install? – Unix Questions — October 24, 2015 @ 12:16 pm
Interesante informatiile, ma gandesc serios sa imi fac si eu un site. Sper sa ajung sa compun la fel de frumos precum o faci tu.
Comment by Tractaribucuresti — April 17, 2016 @ 5:37 am
バニラと聞くと、まず先には牧場などで食べられるバニラソフトを思い浮かべるのではないでしょうか？
しかしバニラは植物です。小さな美しい真っ白な花です。その植物から抽出された香料のことをバニラと言い、種小名はラテン語で「扁平な葉」を意味します。
バニラエッセンスは熱により香りが揮発しやすいので、焼き菓子など高熱で熱する食べ物には実際のところバニラオイルがおすすめです。
どちらも非常に香りが強く、特にオイルは少量で十分な香りがするので使用する時には注意が必要です。
Comment by バニラ 原料 — June 4, 2016 @ 6:01 am
[…] allthatiswrong.wordpress.com Mai multe aici […]
Pingback by The insecurity of OpenBSD – LUG Mureş — August 6, 2016 @ 6:30 am
By the time of your original article, NetBSD has already chosen to remove systrace in its entirety.
Discussion here: http://mail-index.netbsd.org/source-changes/2008/02/19/msg002462.html
Comment by catbsd — November 29, 2016 @ 2:05 pm
My family every time say that I am killing my time here atweb, but I know I am getting familiarity allthe time by reading such good articles.
Comment by Buck Puerta — December 5, 2016 @ 5:29 am
Hi there everyone, it’s my first visit at this web page, and
piece of writing is actually fruitful for
me, keep up posting these posts.
Comment by porn — January 21, 2017 @ 5:01 am
VMware Certified Advanced Professional 6 (Desktop and Mobility Deployment) – The industry-recognized VCAP6-DTM Deploy certification validates that you know how to deploy and optimize VMware Horizon 6 (with View) environments. It proves that you have the knowledge and abilities required to leverage best practices to provide a scalable and dependable Business Mobility platform for your organization. Some of the topics involve: Configuring and managing Horizon View components, configuring cloud pod archituecture, configuring Group Policy settings related to Horizon View, Configuring and optimizing desktop images for Horizon View & Mirage, Configuring and managing App Volumes AppStacks, Configuring desktop pools, Configuring and deploying ThinApp packaged applications, Configuring VMWare Identity Manager, etc.Sebastian’s take on the VCAP6 exam: “In my thoughts and opinions VCAP6 examination is much better experience when compared with VCAP5, the newest examination appears to be exactly like VMware HOL. The interface is not difficult, questions are structured on the right section of the display, and can be concealed to the side or even restored when needed. My bits of advice to the questions window: should you decide to make it floating, you should know how to restore it back. I ended up shifting it around due to the fact I forget about how to restore it back. The 2 arrows that resembled control buttons on top were designed to dock the window to right or left. Fonts could be resized, which i think was far better than scrolling up and down the question. The reaction speed of the entire user interface was so quicker than VCAP5.5, and there wasn’t any lagging time period experienced when changing from window to window. One thing to remember: BACKSPACE key is not working! I believe it is good because you don’t reload your test window in error, nevertheless, it could be troublesome occasionally whenever you type something wrongly and you need to select and press Del to remove. The Desktop and shortcuts were structured adequately, and all necessary applications like web browser or Mirage console could be launched. There is a superb user interface for Remote Desktop Manager where you can find all essential RDP connection to servers or desktops without the need to type account information. The web browser had all the links in the Favorite Bar. At the time I am penning this, there’s no additional Thirty minute extension for Non-Native English speaker at No-Native English country, which is a bummer. There are thirty-nine question to respond to within the three hours period, and this can be actually quite hard for non-native English speakers just like me. A number of questions take time to finish, therefore it is wise to skip the questions that you cannot answer, and complete those you are able to. At the end of the 39 questions, you can return to the uncompleted questions if you still have time. Don’t squander too much time on one single question! The examination blue print is found on my weblog at Szumigalski.com. It is well-organized and following it for the exam preparation will be helpful to a great deal. Certainly, the best is if you can have lots of hands on experience! I’m in fact pretty pleased with the examination experience, despite the fact that I passed this time by small margin, however i understand what I missed for the exam, discover from the blunders and practice harder to get familiar myself with the environment. This accreditation will definitely open up your career prospects!”
Comment by VCAP certified — February 9, 2017 @ 10:45 pm
increased weight
The insecurity of OpenBSD | All that is wrong with the world…
Trackback by elevator service nj — August 24, 2018 @ 12:50 pm
yet another clueless author!
thank you for making me laugh …
As Theo de Raadt said long time ago, when you start cranking over 2000k lines of C daily come back and start commenting …
Comment by catchmonster — August 25, 2021 @ 8:18 am
lol
Comment by Areyano — January 9, 2023 @ 7:24 pm