If you want to make Google tongue-tied, search for “MDM for Linux.”
What you’ll find are a few vendors who claim to offer device management for Linux devices (usually as an afterthought to round out their solutions for Mac and Windows). But look closer and you’ll quickly realize that none of these solutions will let an IT admin provide endpoint security in the way they’re used to with an MDM.
The absence of an MDM for Linux is a real problem if you’re trying to get your entire fleet of devices aligned to the same standard–for instance, if you’re trying to pass a third-party compliance audit. It’s also just a black eye on your security program when you have no visibility into some of your highest-risk devices.
So why isn’t there a Linux MDM? And what are you supposed to do now?
Let us explain.
An MDM (Mobile Device Management) solution is the most common–and the most aggressive– form of device management. (It’s also important to note that “MDM” and “device management” are not synonymous, but we’ll get into that more later.)
MDMs give IT teams nearly total control over Android and iOS mobile phones, and Mac and Windows PCs, and allow admins to apply policies that the user cannot alter. The MDM approach is about graying out check boxes, installing and uninstalling apps, and being able to remotely read, update, lock, or wipe a device.
But that approach is antithetical both to Linux as a technology, and Linux users as individuals. We’ll talk about the technology side first.
If you’ve ever dabbled with Linux, you know it isn’t a single, standardized OS, like the ones produced by Microsoft or Apple. The only thing all Linux devices have in common is the Linux kernel, on top of which Linux users can run anything they want.
Even within the two primary flavors of Debian-based Linux (which includes Ubuntu) and RPM-based Linux (which includes Red Hat and CentOS)–there’s nearly infinite variation from one user to the next.
No MDM solution can account for this level of customization. And since end user control is baked into Linux at every level, the user can reject any outside interference. For example, you can write a shell script for Linux demanding that the firewall is turned on, but unlike with the other operating systems, the user can uninstall it as they please.
As we mentioned earlier, there are tools that claim to give you control over Linux, but they only work on a very finite subset of systems. So what claims to be a tool for Linux turns out to only work if the system runs on Ubuntu, is using the Gnome window manager, etc.
And if you try to enforce that level of conformity on devices so they’re compatible with these tools, then you have misunderstood the Linux user.
You can’t solve the problem of endpoint security for Linux devices until you understand the psyche of the Linux community.
Linux users have long had an aura of mystique–kind of a mix of punk rockers and warrior monks. That’s because, even for developers, using Linux is hard. A user has to have a lot of technical skill for Linux’s value to offset its inconvenience.
Non-Linux users often assume that people gravitate to this challenging OS simply to be contrarian or avoid oversight. But they’re wrong. Linux users are driven by the belief that free software is important, and it’s crucial for individuals to have a say over what their computers do. That’s an important perspective that shouldn’t be lost in a world where devices are locked down by the vendors who sell them, and by the organizations who provision them to their employees.
Linux users are hackers in the original sense of the term–they value the freedom to control their experience. If you force an MDM approach on them they may just quit, and your company will likely lose one of its brightest and most original thinkers.
The other option is that a Linux user pretends to accept their company-issued Mac or Windows laptop, but actually does all their work on their personal Linux computer. And that scenario is very risky, because Linux users may be highly capable, but they’re not infallible, and you still need visibility into their devices to maintain security.
We’ve established that you’ll never have the same inexpensive, easy-to-deploy MDM for Linux as you do for the rest of your fleet. We’ve also explained the problems with trying to standardize Linux devices, or forcing Linux users onto another OS.
Once you’ve eliminated those choices, only three real options remain.
This might seem like a joke, but for a long time, doing nothing was the dominant strategy for Linux device management. IT teams basically trusted that Linux users were technically sophisticated enough to protect their own devices, and allowed them to work without oversight or observation.
And here’s the thing: they weren’t entirely wrong. Linux devices are much less vulnerable to commodity malware or ransomware attacks than Mac or Windows devices. The same customizability that throws off MDMs also makes Linux laptops an unappealing target for hackers, who usually seek the path of least resistance.
While you may have been able to get away with this approach in the past, “do nothing and hope for the best” is no longer a viable option. For one thing, visibility into all devices is now mandatory in order to pass third-party audits like SOC 2.
Likewise, your customers, investors, and leaders simply won’t accept that some of the most high-risk devices in your fleet are functionally invisible. And they’re right to object, because if a Linux device is compromised, it can be disastrous.
Linux users deal with the most valuable data in your fleet, but ironically, they have the least amount of scrutiny applied to their devices.
Linux users often hold the keys to the kingdom on their laptops; intellectual property, production environments, and they have access to other servers. For a hacker looking to exfiltrate IP or customer data, Linux users are an appealing target. And just like any user, they sometimes need to be reminded to do the things that will keep their device secure, like enabling the firewall, and turning on screen lock.
While the concept of an MDM for Linux devices is fundamentally impossible, achieving visibility is not. There are a couple of options for achieving this in-house.
The first general approach is to treat Linux device management like Linux server management, which is relatively straightforward. But, as many IT admins have learned the hard way, you can’t manage Linux laptops like servers, because there’s a human user there.
On servers, products like Anisble or Puppet are good choices because most of the servers you interact with remotely are standardized and in an expected state when you run scripts/commands on them. By contrast, end user devices are anything but standard, by design. It’s impractical (maybe even impossible) to build robust automated scripts that don’t risk creating unintended consequences due to a modification a user made to their device.
You can theoretically use the same products you use for servers to run commands across multiple Linux laptops, but it’s up to you to write the scripts and code you want.
The second option for getting visibility is a tool like osquery, an open source project that lets you run queries across your entire fleet. Osquery can surface a lot of useful data about Linux devices, but it stops at visibility. When it comes to actually remediating issues, you’re on your own.
The overarching problem with any DIY approach is that it isn’t economical. Linux users typically make up a tiny fraction of a workforce, so it doesn’t make financial sense to spend a significant time and effort just to allow a handful of people to keep using the computer they want to use.
Every solution we’ve covered so far has shared the same basic philosophy: that device management is something you do to users. But what if it were something you did with them?
That’s the question we asked at Kolide. (Yes, we’re going to talk about our own product now, but we promise it’s not a bait-and-switch; it’s a genuinely new way of approaching this problem.)
Kolide’s open source agent is built on osquery, so it can run checks across your Linux devices, whether they’re Debian-based or RPM-based. But Kolide goes beyond visibility and actually helps achieve compliance. It notifies Linux users when it detects an issue, and instructs them on how to resolve it. And if a device isn’t secure, its user can’t authenticate via \Okta until they’ve resolved the issue. (To be clear, we’re not claiming we can detect or solve every issue on every version of Linux, but we are the fastest and easiest way to deploy osquery across your fleet.)
“Ask users to fix their own problems” might seem simplistic, but it’s a quietly revolutionary way of collaborating with employees who value transparency and autonomy. And in our experience, it works. When you approach Linux users this way, they’re happy to cooperate, and are even grateful for the reminder.
For all their stubbornness, Linux users aren’t ridiculous. They understand that for business to transact, their devices need to be secure. But they’re unwilling to accept an approach where that is done on their behalf.
You can’t solve endpoint security for Linux without involving end users. But once you take that step, you might realize you didn’t need an MDM in the first place.
Want to see how Kolide’s Device Trust solution (finally) solves Linux endpoint security? Watch our on-demand demo.