All that is wrong with the world…

February 13, 2013

Thoughts on Fedora 18

Filed under: Tech — Tags: , , — allthatiswrong @ 6:57 pm

Thoughts on Fedora 18

I recently decided to remove my long running Slackware install with Fluxbox and Tint2 and install Fedora 18. I chose Fedora because I know that is is well maintained and up to date, and I wanted to start delving deeper into SELinux . I thought it would be a good opportunity to see how Linux on the desktop has progressed.

I was sadly disappointed. Fedora may not be the first name people think of when they think of a polished desktop Linux experience, but it had to be better than the eternally buggy Ubuntu. I didn’t think it would be too different from Debian and so I had high expectations. I was very disappointed.

I should disclose that I may have been at a disadvantage as I did a full install from the 900mb live CD as opposed to the DVDs, however I noticed no warning that my experience would be hampered in any way if I installed this route.

The first thing I noticed was that there was no no easy way to minimize or close windows that was apparent, short of right clicking. This was quite frustrating, and did not seem to make much sense. I decided to install other desktops such as MATE and Cinnamon, to see how they were in comparison to the horrible Gnome 3.

The problems I had then were with the package manager. Using the package manager I thought I would search for the mate desktop, using mate as my search term. I found a bunch of packages, with it not being clear which ones I had to install or which dependencies were needed. After dealing with a lot of nonsense about waiting in a queue before I could actually install packages, it turns out I had not managed to install the MATE desktop.

I did manage to install cinnamon, although I had the same problem of trying to guess which packages were actually for the desktop environment. Isn’t package management on Linux now meant to be easy to use and intuitive? That is not all the experience I had. Compiling from source would have been significantly easier.

I also noticed that there was no way to easily disconnect from a wireless network. I had connected to the wrong network by mistake and when wanting to rectify this, I found no way in the GUI to disconnect from the current network.

Finally I decided to logoff to test out my newly installed Cinnamon (and I had thought MATE) environments. This was the kicker…there was no logoff option. Apparently this is a well known bug (feature?) with Fedora, in that if there is only one user account the logoff option is not displayed. Sigh. Even ctrl+alt+backspace didn’t work to restart the X server.

I still plan to use Fedora a lot more, but for my initial impressions I am not at all impressed. Year of the Linux Desktop? Not this year, or not with Fedora at least.

Advertisements

August 7, 2011

Linux – The worst platform for video editing

Filed under: Tech — Tags: , , , — allthatiswrong @ 6:16 pm

Proponents of Linux often tend to misrepresent Linux as a leader in video editing. Whether this is intentional or just due to being misinformed, nothing could be further from the truth, with Linux potentially being one of the worst platforms for video editing. There are no decent software packages for editing video on Linux and it is one of many prime examples of why Linux is not anywhere ready to be a replacement for OS X or Windows on a large scale. The idea that Linux is the most popular platform for video editing seems to come from the fact that it is used on server farms to do 3D rendering. However, this is not video editing. For actually editing film, doing post-processing such as adding in sound, visual effects or even just playing with scenes there is no software on Linux that can do this reliably.

Often you’ll see people quoting statistics such as 95% of the computers in Hollywood are running linux or some crap. Even if that’s true, it doesn’t mean Linux is being used as the platform that film is edited on. As it stands there are no decent video editing tools for Linux, or for any OSS platform. Kdenlive, PiTiVi, OpenShot, lives, Cinelerra and Kino have all been in development for many years ever languishing or forking. Either way at the moment there is not a single OSS video editor that provides anywhere near the functionality of say Final Cut Pro. Not only are all the available video editors lacking in basic functionality, many of them have horrendous stability issues, segfaulting when trying to import video for example.

Many people of bring up stuff like Maya or Pixar’s RenderMan, but ultimately this is 3D development software that’s use is not limited to film, at all. The fact that films can be made with such software is incidental and does nothing to detract from the point that there is no quality video editing software for Linux. This shouldn’t be surprising, as it is the nature of the beast. The way OSS works is that people develop out of personal motivation or because they are paid to. There are very few people working in video editing who are also programmers, so there is a lack of quality video editing OSS available. Until more people contribute or a company funds development, that’s how it will stay.

Hopefully this will help to dispel the propaganda that Linux is prominent in the film industry. It certainly is as far as CPU hours goes, since it is ideal for rendering. If you expect to see it being used by the people actually editing the films on desktops, then think again. Perhaps one day….probably before Linux gets decent audio applications at least. Also, this isn’t an anti_Linux article. It’s an anti-bullshit-propaganda article. Linux is great, no need to misrepresent what it is capable of or how it is used.

April 18, 2011

Thoughts on Slackware

Filed under: Tech — Tags: , , — allthatiswrong @ 11:40 am

Slackware is an interesting distribution known for being stable and having a minimal approach, two of the reasons why for a long time it was my favorite distribution. It is also the oldest still surviving distribution, which should speak for itself. When I started learning about Linux and getting into the low level details of computing, it was through Slackware that I learned a lot of what I know today, or at least the foundation. I had played with Red Hat, Debian and Caldera to varying extents, but they all needlessly obfuscated simple details. It was with Slackware that I had direct access to my system and the native utilities to interact with it. It was with Slackware that I was encouraged to read the documentation and learn how things work rather than use a poorly written GUI tool that tried and failed to make configuration seamless.

One thing I always liked about Slackware was that I always had the feeling of total control over my system. I knew where all my system scripts were that did everything, I knew where every file on my system was and if I didn’t I could find it. I knew how everything worked and if something was out of place, I would know it. This was less true of other distributions where there may be varying levels of obfuscation or several different locations where things may be placed. Slackware has somewhat of a reputation as being difficult to learn, but nothing could be farther from the truth. Everything is well documented and it is easy to do anything. Editing a configuration file is not any harder than having a GUI tool do it for you and for those who think it is they should probably get a Mac.

After traveling around and not having a PC for a few years I hadn’t used Slackware much. It isn’t used in production very often so I didn’t encounter it when working and I wasn’t using it personally, so it wasn’t until 2009 when I got a PC again that I got into using it. I knew I wanted to get up to speed on the Linux stuff I had missed and Slack seemed the obvious choice, especially given the alternatives. The core distributions had not changed in philosophy so much, while newer distributions such as Gentoo or Ubuntu offered no real advantages and many disadvantages. After installing and setting up 13.0 (which I will cover in a later post, the 64bit version is also very nice!) I was glad to see that things seemed mostly familiar. Yet, I also noticed a lot of changes, most of which were not positive. I noticed these changes mainly in the community but they were apparent in the design of the distribution as well.

The current community seems to be full of rabid Microsoft hating zealots who were unwilling to reason and happy to jump on any bandwagon criticizing Microsoft or Windows. This was not the community I remembered, that I had learned so much from. The community I remembered tended to be more mature than that, realizing that Windows and various Linux distributions both have strengths and weaknesses and that one is not automatically and always superior to the other. It isn’t surprising that the community is like this given Slackware’s relatively recent priority on being a desktop; however I wonder which came first? It seems like a chicken and egg problem….did Slackware change first and attract these new users or did they come to Slackware which caused it to adapt? Either way, it’s slightly disappointing.

Another major change I saw in the community was in the attitude towards learning and problem solving. Back in the day if I wanted to know how to do something there would always be people willing to explain things to me or I would be pointed towards the relevant documentation. Nowadays it seems more common that people will question why you want to do something in the first place assuming they know better or disapproving if it doesn’t meet their highly biased standards. An example of this might be that I had an issue with my soundcard module causing problems on occasion. In the days of old I would have been offered help in troubleshooting the issue and perhaps learning something from it. These days the most anyone would offer is a suggestion to reboot.

Another example of something I felt had changed was the recommendation and near requirement to do a full install. This is completely contrary to how I use Slackware, as I like to have quite a minimal install with just the programs I need and use and Fluxbox for a minimal GUI. However the current version of Slackware assumes that everyone is going to do a full install, which leads to stupid dependencies such as Mplayer requiring Samba just in case that niche functionality might be required. Aside from being a waste of space and increasing the risk of an attack, it encourages bad habits. Slackware was famous for adhering to the KISS principle but when a full install is the simplest way to satisfy dependencies, then that wouldn’t seem to hold true any longer. I don’t know that Bob would be happy with how things have changed. It might be OK if this was simply the recommendation from the Slackware team, except the community has blindly followed suit. When asking which package might contain a certain library you inevitably get bombarded with questions asking for justification as to why you didn’t do a full install.

I can’t help but feel that these changes are due to a desire to keep Slackware in the race for desktop Linux, and as a consequence has forgotten its roots. The community and distribution now seem closer to Ubuntu or Mandrake in the sense of target audience and community, which is a shame. It seems that many Slackware users of the past have migrated to Gentoo or Arch or various other distributions. I would not be surprised, as the Arch community and wiki is exactly the sort of community and advice I used to associate with Slackware. If it wasn’t for the cutting edge/rolling release aspect I would probably adopt it as my primary distribution.

One of the things I always liked about Slackware was that it took a minimalistic approach. There was always only what was necessary or what would actually make things easier present, nothing unnecessary or in the way. This no doubt helped Slackware to maintain its reputation for stability as well. It was easy to install specific programs without having to install all the related programs you didn’t actually need. The packages tended to be quite vanilla, which was useful when you were compiling your own software. It was easy to add 3rd party packages without interfering with the rest of the system. There were no kernel updates as Slackware just used the vanilla kernel, which most people knew how to build and update themselves.

One aspect of Slackware that had always received constant criticism was its package management. When compared to offerings such as rpm and apt-get it may seem lackluster, yet at a time when those systems suffered from a dependency hell worse than any windows version had been afflicted with Slackware was a breath of flash air. Originally a Slackware package was simply a collection of compiled binaries and config files inside a tarred gzip file, with an additional text file including a package description and some basic instruction. The installpkg command would extract the files in the right places and place an entry in /var/log/packages where you could easily see what packages you had installed and the files belonging to each package.

Of course most software was not offered in a Slackware package format, although this was not a concern. Using the program checkinstall you would just grab the source tarball, and run checkinstall instead of make install. This would install the program while creating the appropriate entries in /var/log/packages, allowing for an easy uninstall if desired. This is probably the area Slackware had matured the most in in the few years I had not kept up with it. checkinstall was no longer being developed, however the much more diverse src2pkg had appeared to take its place. Slackpkg had been introduced and is now an official tool in the distribution. It is an awesome tool that allows for installing and checking for updates all from one interface. It also makes it easy to create templates which allow you to setup other machines the same way in a very easy way. One of the nicest features is that you can search all packages for a particular file which makes satisfying dependencies trivial. I had a script to do this but having such functionality available natively is much better.

Probably the biggest change was the appearance of Slackbuilds. Slackbuilds are simple build scripts for pretty much any software not officially included with Slackware. You simply grab the source and the associated Slackbuild and run the Slackbuild script, and then install the resulting package. They are easy to configure and understand, and available for most software you will encounter. They don’t tend to be kept so up to date, but since the compiling process doesn’t change so much it isn’t much of an issue most of the time. For the few packages that don’t have Slackbuilds src2pkg works like a charm.

The last thing I would note about Slackware is that it has suffered from some odd decisions preventing it from moving forward. Things like a non graphical boot or sticking with stable versions of programs rather than newer cutting edge versions is all fine. Other decisions seem odd, such as still sticking with LILO over GRUB. It’s true that LILO works fine, however GRUB has a number of distinct advantages over LILO. In which case it is worth asking why not switch to GRUB? Then there is PAM. Slackware is the only modern distribution to have support for PAM. Back in the day, Linux-PAM was a mess and the justification somewhat made sense, however it no longer does. The option to use PAM should at least be included as without it, it makes it hard to use many programs, or even stuff like SELinux which is now native kernel functionality.

Despite everything I still have a lot of love for Slackware and it is still my distribution of choice. I like the hands on simple approach and the easy configuration. I like the simple yet powerful package management which despite the FUD being spread, has no disadvantages over more complex package management systems. I like the most of the packages are compiled from vanilla source without various buggy patches incorporated. Slackware remains a simple and reliable distribution that is easy to use, learn and maintain. For my needs which consist of a stable and minimal install without having to update constantly Slackware is the only option. It is getting harder to keep a minimal install however after doing the initial work the configuration can be kept with tagfiles. As packages continue to have unnecessary dependencies it is becoming easier/necessary to compile my own versions. This is only true for very few packages at the moment and hopefully that won’t change.

Slackware has changed from a distribution which was plain and simple to understand while being easy to configure and slim down for your needs to a distribution which now recommends a full install and tries to accommodate the typical needs of a desktop user. It is made more difficult now to remove unwanted functionality or to integrate 3rd party programs into the distribution. I find Slackware less convenient for my needs and fine myself less wanting to interact with the new community; however this doesn’t mean it is worse than it was before. It just means that it is catering to the needs of its users as they changed and adapted. Still, it is possible to learn a lot on Slackware and I hope much of the community can one day move past their rabid anti MS hate and mature, learning something in the process.

I don’t know if I would still recommend Slackware to new users wanting to learn the ins and outs of Linux, as the community and distribution no longer seems suited to that where something like Arch does. I still use it daily and suggest it to people; I was just disappointed to see it change from how I remembered it in a direction I felt was less true to its user base and principles. I want to give a lot of thanks to Patrick Volkerding who has put in so much work into Slackware, which allowed and encouraged me to learn so much so many years ago. I also want to stress that my opinions should not be taken as a slam on Slackware and I will continue to use and support it, or at the least remember it fondly.

April 12, 2011

Good riddance to Groklaw

Filed under: Tech — Tags: , , , , — allthatiswrong @ 7:14 pm

So, Groklaw is coming to an end, with PJ stating she is no longer going to be making new posts. I have to say, I’m not to upset at this and in fact I’m glad Groklaw is finally shutting down. See, when Groklaw started it provided some useful legal opinions on some of the issues Linux faced as it gained prominence, particular in the SCO fiasco. However as time went on the site became heavenly biased, attracting many of the worst kinds of Linux zealots. What was once an objective overview of legal issues became a front to attack anyone or anything that threatened or criticized Linux, or to a lesser extent open source. Perhaps naturally the audience the site then began to attract were those that found a reference they could sell as authoritative which matched their views. Despite the fact the legal analysis became increasingly flawed as viewed through a particular lens, it didn’t matter as long as those people were hearing what they wanted to hear.

Some critics of Groklaw began to question if the site was a shill for IBM or some other entity with an agenda. I don’t think that was the case at all. I think it’s far more likely a paralegal with a cursory interest in open source and Linux got a little too comfortable with the very strong support from the community and then started writing posts an analyzing legal issues in a way that would most appeal to that crowd, with all regard to objectivity gone. Perhaps a good example is in one of the non SCO issues the site covered, such as the whole Psystar case. In her analysis it seemed that PJ forgot many of the ideals she seemed to believe in, randomly siding with Apple. The analysis of the case was lacking in many areas and was certainly far from objective. It seemed like this random Pro-Apple support came just as the site reached its peak in its childish anti-MS campaign. Anything MS is evil and thus by extension anything that may hurt MS is good.

These type of people are one of the very worst things about the Linux community and Groklaw has fueled and supported them for the last several years. It is for this reason I am not sad to see the site go, while simultaneously having respect for PJ and the good work she did in the beginning of the site.

January 20, 2010

The insecurity of OpenBSD

Filed under: Security — Tags: , , , , , , , , , , , , , , — allthatiswrong @ 11:29 pm

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

 

  1. SELinux – http://www.nsa.gov/selinux
  2. RSBAC –http://www.rsbac.org
  3. GRSecurity – http://www.grsecurity.net
  4. AppArmor – http://developer.novell.com/wiki/index.php/Apparmor_FAQ
  5. The TrustedBSD Project – http://www.trustedbsd.org
  6. Core Security OpenBSD Advisory – http://www.coresecurity.com/content/open-bsd-advisorie
  7. Marc Espie talking about security complexity and calling MAC security theater- http://thread.gmane.org/gmane.os.openbsd.misc/129217/focus=129371
  8. 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
  9. An older similar argument on the OpenBSD misc mailing list – http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Security
  10. 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
  11. Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools – http://www.stanford.edu/~talg/papers/traps/abstract.html
  12. Exploiting Concurrency Vulnerabilities in System Call Wrappers – http://www.watson.org/~robert/2007woot/20070806-woot-concurrency.pdf
  13. Bob Beck talking about systrace – http://thread.gmane.org/gmane.os.openbsd.misc/160797
  14. China chooses FreeBSD as basis for secure OS – http://blogs.techrepublic.com.com/security/?p=1682
  15. An example of SELinux preventing an exploit on RHEL 5 – https://rhn.redhat.com/errata/RHSA-2007-0960.html
  16. Dan Walsh talking about SELinux successfully mitigating vulnerabilities – http://danwalsh.livejournal.com/10131.html
  17. 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
  18. Details on the SELinux policy that allowed for the Cheddar Bay exploit – http://eparis.livejournal.com/606.html
  19. SELinux preventing a kernel vulnerability from succeeding – http://lwn.net/Articles/191954/
  20. 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
  21. 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
  22. A primer on OpenVMS security, a highly secure OS designed with security in mind at every level – http://www.blacksheepnetworks.com/security/resources/openvms/
  23. Presentation introducing Strlcpy and strlcat – http://www.usenix.org/events/usenix99/millert.html
  24. 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.

Blog at WordPress.com.