sudo is not as bad as Linux Journal would have you believe

Fear, uncertainty, and doubt (FUD) is often used to undercut the use of open source solutions, particularly in enterprise settings. And the arguments are sometimes valid, but that’s not a requirement. So long as you make open source seem risky, it’s easier to push your solution.

I was really disappointed to see Linux Journal run a FUD article as sponsored content recently. I don’t begrudge them for running sponsored content generally. They clearly label it and it takes money to run a website. Linux Journal pays writers and that money has to come from somewhere. But this particular article was tragic.

Chad Erbe uses “Four Hidden Costs and Risks of Sudo Can Lead to Cybersecurity Risks and Compliance Problems on Unix and Linux Servers” to sow FUD far and wide. sudo, if you’re not familiar with it, is a Unix command that allows authorized users to run authorized commands with elevated privileges. The most common use case is to allow administrators to run commands as the root user, but it can also be used to give, for example, webmasters the ability to restart the web server without giving them full access.

So what’s wrong with this article?

Administrative costs

Erbe argues that using sudo adds administrative overhead because you have to maintain the configuration file. It’s 2017: if you’re not using configuration management already then you’re probably a lost cause. You’re not adding a whole new layer, you’re adding one more file to the dozens (or more) you’re coordinating across your environment.

Erbe sets up a “most complicated setup” strawman and knocks it down by saying commercial solutions could help. He doesn’t say how, though, and there’s a reason for that: the concerns he raises apply to any technology that provides the solution. I have seen sites that use commercial solutions to replace sudo, and they still have to configure which users are authorized to use which commands on which servers.

Forensics and audit risks

sudo doesn’t have a key logger or log chain of custody. That’s true, but that doesn’t mean it’s the wild west. Erbe says configuration management systems can repair modified configuration files, but with a delay. That’s true, but tools like Tripwire are designed to catch these very cases. And authentication/authorization logs can be forwarded to a centralized log server. That’s probably something sysadmins should have set up already.

sudo provides a better level of audit logging compared to switching to the root account. It logs every command run and who runs it. Putting a key logger in it would provide no additional benefit. The applications launched with sudo (or the operating system itself) would need it.

Business continuity risks

You can’t rollback sudo and you can’t get support. Except that you can, in fact, downgrade the sudo version if it contains a critical bug. And you can get commercial support. Not for sudo specifically, but for your Linux installs generally.

Lack of enterprise support

This sems like a repeat of the last point, with a different focus. There’s no SLA for fixing bugs in sudo, but that doesn’t mean it’s inherently less secure. How many products developed by large commercial vendors have security issues discovered years later? A given package being open source does not imply that it is more or less secure than a proprietary counterpart, only that its source code is available.

A better title for this artice

Erbe raises some good points, but loses them in the FUD. This article would be much better titled “why authorization management is hard”. That approach, followed by “and here’s how my proprietary solution addresses those difficulties” would be a very interesting article. Instead, all we get is someone paying to knock down some poorly-constructed strawmen. The fact that it appears in Linux Journal gives it a false sense of credibility and that’s what makes it dangerous.

Why I choose the licenses I do

In the discussion around Richard Stallman’s speech at Purdue and my subsequent blog post about it, there was a great focus on the philosophy of various licenses. On Twitter, the point was raised that the GPL restricts the freedom of those making derivative works. The implication being that it imposes selfish restrictions. As a response to that (and because I told “MissMorphine” that I would write on this), I thought it would be a good idea to write about my own license choices and the personal philosophy behind them. Never mind the fact that it’s five years late.

First, my general philosophy. I am a proponent of the free sharing of information, knowledge, and software. I’m also aware that producing these things requires effort and resources, so I’m sympathetic to people who prefer to receive compensation. For myself, I generally opt to make things available. In exchange, I ask that people who would build off my work not restrict the freedoms of others. In order to do that, I must restrict the freedom to restrict freedoms. This is the choice I make for my own work.

Open source licenses (and I use the term broadly here to include the Creative Commons licenses and similar) maximize freedom in one of two ways: they maximize freedom for the next person downstream or they maximize freedom to any level downstream. It’s shouldnt be a surprise to learn that the former is often favored by developers and particularly by commercial entities, as it allows open source code to be used in closed products.

My default licenses are the GNU General Public License version 2 for code and Creative Commons Attribution-ShareAlike 4.0 for non-code. The gist (and to be clear, I’m hand waving a lot of detail here) of these licenses is “do what you want with my work, but give me credit and let others have the same rights.” However, I’ve licensed work under different licenses when there’s a case for it (e.g. contributing to a project or ecosystem that has a different license).

The important thing to remember when choosing a license is to pick one that matches your goals.

 

Other writing in January 2017

Where have I been writing when I haven’t been writing here?

The Next Platform

I’m freelancing for The Next Platform as a contributing author. Here are the articles I wrote last month:

Opensource.com

Over on Opensource.com, we had our fourth consecutive month with a milion-plus page views and set a record with 1,122,064. I wrote the articles below.

Also, the 2016 Open Source Yearbook is now available. You can get a free PDF download now or wait for the print version to become available. Or you can do both!

Cycle Computing

Meanwhile, I wrote or edited a few things for work, too:

  • Use AWS EBS Snapshots to speed instance setup — Staging reference data can be a time-expensive operation. This post describes one way we cut tens of minutes off of time for a cancer research workload.
  • Various ghost-written pieces. I’ll never tell which ones!

Come see me at these conferences in the next few months

I thought I should share some upcoming conference where I will be speaking or in attendance.

  • 9/16 — Indy DevOps Meetup (Indianapolis, IN) — It’s an informal meetup, but I’m speaking about how Cycle Computing does DevOps in cloud HPC
  • 10/1 — HackLafayette Thunder Talks (Lafayette, IN) — I organize this event, so I’ll be there. There are some great talks lined up.
  • 10/26-27 — All Things Open (Raleigh, NC) — I’m presenting the results of my M.S. thesis. This is a really great conference for open source, so if you can make it, you really should.
  • 11/14-18 — Supercomputing (Salt Lake City, UT) — I’ll be working the Cycle Computing booth most of the week.
  • 12/4-9 — LISA (Boston, MA) — The 30th version of the premier sysadmin conference looks to be a good one. I’m co-chairing the Invited Talks track, and we have a pretty awesome schedule put together if I do say so myself.

March Opensource.com articles

I ended up only writing one article for Opensource.com this month, but it turned out to be pretty popular, garnering well over 10,000 views. However, that’s nothing compared to the over one million views the whole site had in the month of March. The final total is roughly 200,000 more than the previous monthly record. I’d like to congratulate the editorial team, my fellow Community Moderators, and all of the other Red Hat & community contributors who have worked so hard to reach this milestone. I’m honored to be a part of such a great team.

December Opensource.com articles

Here are the articles I wrote for Opensource.com in December:

November Opensource.com articles

I’ve decided to make this a regular thing: near the beginning of every month, I’ll recap the articles I’ve written for Opensource.com in the previous month. This seems better than scattershot posts that may or may not include all of my articles. So here’s November:

I support Software Freedom Conservancy

If you’ve read this blog for any length of time, you know that free and open source software is important to me. It’s important to Software Freedom Conservancy as well. Conservancy is a 501(c)(3) organization dedicated to supporting software projects.

Conservancy provides a lot of services to member projects, including financial and administrivia. Conservancy also provides license enforcement services, including support of a high-profile suit against VMWare. Although Conservancy uses litigation as a last resort, it’s sometimes necessary. However, this has lead to some corporate sponsors pulling their funding.

In order to continue their efforts, Conservancy is moving to an individual-supporter model. I first became a Conservancy supporter last year, and when it’s shortly time to renew my support, I will contribute double. Free and open source software is important to my personal and professional lives, and the services Conservancy provide to projects is invaluable.

If you use computers at all, a Conservancy project is probably an important part of your daily life. Please join me in supporting the Software Freedom Conservancy with a tax-deductible* donation today.

*Consult your tax professional to see if donations are tax-deductible in your jurisdiction.

Recent Opensource.com posts

In lieu of original content, here are a few articles I’ve recently written for Opensource.com:

Selecting an open source license for VC funding

Tomasz Tunguz recently had a post exploring the relationship between open source licenses and exits (either funding or acquisition). When I first saw this, I was excited. The practical consequences of license selection is an area of particular interest to me. Sadly, the article was terrible.

Tunguz compares funded project license distribution to total open source license distribution. This is a fatal flaw since there is no evidence to suggest that these are drawn from the same population. Many open source projects are small hobbyist efforts. Even large ones can be predominantly volunteer-driven, with no intention of seeing venture funding or acquisition. That alone is enough to render the comparison meaningless. A better study would examine projects looking for funding and see if any license is correlated with better results.

The article is titled “Which Open Source License Should Your Project Use if You Want to Raise Venture Capital?” but fails to answer the question. It does not even establish whether or not the license selection matters. Even if a full statistical study wasn’t feasible, commentary from a variety of VCs could help provide guidance.

Licenses are chosen for a variety of reasons. Some are philosophical, some are practical. Choose the one that fits your project best. If that means finding out which licenses the VC firms you’ll target prefer, do that. If it means using the license that’s common to the ecosystem your project lives in, do that. Just don’t rely on a few slapped-together bar charts with no credibility.