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.
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.
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 abandoned 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.
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 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?
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.
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.
- 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.