IAM Cybersecurity and Unikernels

IAM or Identity Access Management is a complex topic and covers a wide range of topics but when it comes to server-side linux systems we're commonly talking about the management of users accessing these systems primarily through ssh to access a shell. This is assumed since linux is built with the concept of running multiple programs by multiple users.

Hello 2025!

Wait a minute. What if you're only running one program though? Do you even need users?

IAM encompasses application level and network level identity access management and operating system identity is just assumed as something that needs to be managed as well. Unfortunately this is where the most costliest security problems can arise as it implies attackers have potential access to both network and application level access regardless, often with devastating consequences.

Deploying an interactive server operating system with the notion of users, when you can virtualize individual applications, comes with a whole host of security issues but have you ever thought about how large of a problem it truly is?

Software developers have long had to struggle with designing security for user interaction with their application and their server operating system. However, this is just a historical reason. With the rise of real application level virtualization through unikernels versus containers, you don't have to struggle with this anymore. Since unikernels virtualize individual applications vs an entire general purpose operating system large swaths of security issues with operating system users immediately vanish.

A lot of people immediately think of authn && authz but it goes way further than that.

Let's quantify it.

55 Common Weaknesses Within 10 Categories

We consulted Mitre's CWE list and found 55 distinct common weaknesses that are associated with allowing users on servers spread out across ten different categories.

We're not just talking about random sysadmins ssh'ing into systems here. We are stating the architecture of even allowing multiple users or the existence of a user system itself is an issue here. After all - you can't have the black without the white - if you have one user that implies there are others. For instance having a webserver run as a root but then "lower privileges" to a lesser user is a fundamental security flaw. You need to take into context though that on a normal linux system you still kind of want this because again, there's this notion of multiple users and multiple processes - some privileged and some not.

When you start looking at all the ways you can poke the bear -- as you can see this is not just a small issue - it is a massive security hazard. Furthermore since the issue is so infectious it is impossible to just limit or deny certain aspects of it.

Note: This list should not be taken to be read as an authoritative set but more as a large list that was compiled. Perhaps in the future we'll put together something a bit more concrete.

There are 10 CWE categories that can be abused that the notion of a multi-user operating system comes with. (Some of these are duplicated in categories.)

• CWE-1390: Weak Authentication
• CWE-290: Authentication Bypass by Spoofing
• CWE-294: Authentication Bypass by Capture-replay
• CWE-295: Improper Certificate Validation
• CWE-301: Reflection Attack in an Authentication Protocol
• CWE-303: Incorrect Implementation of Authentication Algorithm
• CWE-305: Authentication Bypass by Primary Weakness
• CWE-306: Missing Authentication for Critical Function
• CWE-307: Improper Restriction of Excessive Authentication Attempts
• CWE-308: Use of Single-factor Authentication
• CWE-309: Use of Password System for Primary Authentication
• CWE-322: Key Exchange without Entity Authentication
• CWE-603: Use of Client-Side Authentication
• CWE-645: Overly Restrictive Account Lockout Mechanism
• CWE-836: Use of Password Hash Instead of Password for Authentication

• CWE-653: Improper Isolation or Compartmentalization
• CWE-842: Placement of User into Incorrect Group
• CWE-1220: Insufficient Granularity of Access Control

• CWE-283: Unverified Ownership
• CWE-639: Authorization Bypass Through User-Controlled Key
• CWE-640: Weak Password Recovery Mechanism for Forgotten Password
• CWE-708: Incorrect Ownership Assignment

• CWE-262: Not Using Password Aging
• CWE-263: Password Aging with Long Expiration
• CWE-324: Use of a Key Past its Expiration Date
• CWE-521: Weak Password Requirements
• CWE-798: Use of Hard-coded Credentials
• CWE-916: Use of Password Hash With Insufficient Computational Effort
• CWE-1392: Use of Default Credentials

• CWE-324: Use of a Key Past its Expiration Date
• CWE-328: Use of Weak Hash
• CWE-331: Insufficient Entropy
• CWE-916: Use of Password Hash With Insufficient Computational Effort

• CWE-324: Use of a Key Past its Expiration Date
• CWE-798: Use of Hard-coded Credentials

• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• CWE-41: Improper Resolution of Path Equivalence
• CWE-59: Improper Link Resolution Before File Access ('Link Following')
• CWE-66: Improper Handling of File Names that Identify Virtual Resources
• CWE-378: Creation of Temporary File With Insecure Permissions
• CWE-379: Creation of Temporary File in Directory with Insecure Permissions
• CWE-426: Untrusted Search Path
• CWE-427: Uncontrolled Search Path Element
• CWE-428: Unquoted Search Path or Element

• CWE-645: Overly Restrictive Account Lockout Mechanism

• CWE-276: Incorrect Default Permissions
• CWE-277: Insecure Inherited Permissions
• CWE-278: Insecure Preserved Inherited Permissions
• CWE-279: Incorrect Execution-Assigned Permissions
• CWE-280: Improper Handling of Insufficient Permissions or Privileges
• CWE-281: Improper Preservation of Permissions

• CWE-243: Creation of chroot Jail Without Changing Working Directory
• CWE-250: Execution with Unnecessary Privileges
• CWE-266: Incorrect Privilege Assignment
• CWE-267: Privilege Defined With Unsafe Actions
• CWE-268: Privilege Chaining
• CWE-270: Privilege Context Switching Error
• CWE-272: Least Privilege Violation
• CWE-273: Improper Check for Dropped Privileges
• CWE-280: Improper Handling of Insufficient Permissions or Privileges
• CWE-648: Incorrect Use of Privileged APIs

Zooming in on a CWE Category

Let's zoom in on just one of these categories to understand some of the ramifications. I'm going to pick file handling for a few reasons. First - it's not the most obvious one such as authentication errors. Secondly, the concept of users goes a lot deeper than asking whether or not someone can ssh into a server. Applications using the multi-user privilege model will commonly do things like listen with privileged access on lower number ports but then have less privileged code do other things.

Other times you'll see code that looks at the permissions of a file, perform some task on behalf of that user with different (not necessarily higher) privileges and then carry on as the user in question. These are classic TOCTOU attacks that the container ecosystem has always routinely suffered from. This style of software is just totally utterly broken. Literally yesterday, as of this writing, news broke of the latest (definitely not the last) container breakout, NVIDIAScape, CVE-2025-23266, that was accomplished in 3 lines of dockerfile and it suffers from CWE-426 which is in our list.

While most of the attacks that utilize these methods are going to be *vastly* easier for an attacker with local access - even if you don't have a shell and you have turned off the ability to fork new processes these weaknesses can still be present.

To put it another way the architecture itself here is inherently broken.

AI Agents

In 2025 we are starting to hear more about "non-human" identities in relation to AI agents but the reality is that that concept already existed. The identity aspect matters not so much if it is driven by a determined attacker or is slightly more autonomous.

At the end of the day we don't need or want the concept of "users" tied to code - definitely not the concept of multiple users with different permissions when there is only one application even being ran. Also, just to be clear here - we are talking about provisioning for virtual machines that can take advantage of this architecture - not physical servers that you can touch.

In the old days you might have a "user" named "apache" that belonged to the "www" "group" and another "user" named "postgres" and they lived on the same machine - but that is simply not how things are ran in production today. There are a lot of companies whose databases don't even fit on a single server anymore - they shard and replicate out onto many servers. Of course - those "servers" aren't even real - they are virtual machines living in the cloud.

Nanos unikernels can completely eliminate many of these common weaknesss categories and greatly reduce the ramifications of others because they only run a single application and don't have the notion of system users or an interactive userland. When you're able to throw out this concept of a user-based architecture you can seriously drive down a ton of these problems and we haven't even mentioned yet that most exploit payloads *expect* an interactive userland - that in of itself is a major win. Trying to ROP your way not only through a binary but an entire VM that changes it's entire memory layout on every single deploy is not fun.

Some people might think that simply deploying your application to a PAAS or to AWS Lambda or to K8S skirts around these issues but that is nowhere close to the truth. These all still have users, many have shells and you can still ssh into many of these options. all these distroless images that are cropping up have the same liabilities. Again - it's not about the lack of tooling - it is about the inherent architecture flaws.

Don't kid yourself. Unikernels are *nothing* like containers or pushing workloads into consumer PAAS.

What About Debugging?

Don't we need users to debug systems? No. First, modern APM and oberservability tools go a very long way to debugging applications. They are inhernetly built to manage fleets of systems. Secondly, if you haven't actually deployed a unikernel you probably don't really understand what these things are. I'd stop reading and go deploy your first unikernel right now just so you can have a feel for what these things are. You shouldn't think of them as a linux or bsd system - think of them more as your app because that's what they are. Just as we have removed things like frame buffers and d-bus and the like we have also made the experience a lot more suitable for running one application vs many. Much of the configuration that you can apply to them are application specific but it's applied to the systeme as a whole. We can take snapshots of running vms, download them locally and attach gdb to them - cause at the end of the day - it is just an application. Just as it wouldn't make sense to ssh into your go webserver it doesn't make sense to ssh into these. Thirdly, many of the technologies we just listed above impose similar restrictions even thoug the "users" are still there in hiding. You can, as pointed out in the 'file handling' weakness category still abuse them heavily.

Locally you can still debug these quite easily with gdb or a whole host of other tools like the filesystem sub-commands we package with ops or the tracing tools like strace/ftrace and such, or Radar you can dynamically enable or the ability to export coredumps.

Unikernels are totally different since they not only don't have the concept of users but they don't have the concept of an interactive system which implies multi-processing. Virtualization is the way this is actually made possible.

Time to Dump IAM

It is time to walk away from the operating system user architecture and dump the IAM - at least for managing systems.

If you are looking for stronger runtime protection - what are you waiting for?