I am not sure that the offset in security is that small. The assumption, that your servers will only be evaluated month later doesnt hold true in most cases. Attacking running machines quickly does happen. If your threat scenarios are little green men, they are unlikely to just shut down your server and haul it to some dark room to interrogate later. They will of course try to get the key from a running system, but thats also something you should most definitely have in your threat assessment.

edit: blue men*. Forgot that green police uniforms are an outdated local thing.

I’ll give examples for the US but you can translate as appropriate.

I’d say there’s no municipal police force in the country that has a sufficiently technically sophisticated regular law enforcement to try to attack a running machine. So if you are suspected of having information relevant to a murder or drug deal—the seize and examine one month later scenario is extremely likely.

A handful of states and maybe one or two municipalities may have a computer crimes division that would be sophisticated enough to know to worry about encrypted disks, but they’d have to hire expensive outside consultants to carry out the actual attack and would do so in exceptional circumstances rather than routinely.

Finally, if your threat model includes the national security apparatus then, yes, this is probably too much of a compromise.

There are regional technical support task forces that work across agencies. Smaller departments call them in for serious work and the larger ones contribute resources. So while you’re right about the agencies’ individual capabilities, you’re wrong that they’re siloed like that.

>I’d say there’s no municipal police force in the country that has a sufficiently technically sophisticated regular law enforcement to try to attack a running machine. So if you are suspected of having information relevant to a murder or drug deal—the seize and examine one month later scenario is extremely likely.

I wouldnt assume that this is still the case, at least in Germany. I think the days of police shutting down the devices they have a search warrant for are pretty much over until they are confident enough that there isnt a disc encryption in place. If there is, they keep the device from going to sleep and call for an expert. If they are actually targeting server infrastructure, there will be people with technical expertise involved.

The US can have some small police forces. Like, a handful of people independently serving a city.

If they were the first to respond to a tech crime, they could probably create a mess. But in theory, they could do their own search warrants, searches, recommending prosecutions, etc.

Even big police forces, e.g. NYPD, have lots of divisions. I don't think there's any standard operating procedure in place that would lead a random detective in a random precinct to call in one of the two or three experts across the entire NYPD on a case he is working that happens to involve seizure order for servers. If someone in the special city-wide child pornography unit was involved in a server seizure, that's when the computer expert might be involved (because he or she would be attached to the computer crimes division the child porn unit is a part of).

> They will of course try to get the key from a running system, but thats also something you should most definitely have in your threat assessment.

1. I have yet to see any indication that this is the case.

2. If you assume such technical skill in your adversaries, you must figure that they could just as well open your servers and read the file system keys right off the memory by running wires to the memory bus. In which case Mandos is no worse than no Mandos.

Putting wires on the memory bus is not really needed.

>1. I have yet to see any indication that this is the case.

Taking memorydumps of running systems have been state of the art for about 10 years. There is a heap of commercial forensic software which are used for extracting everything from bitlocker to back then truecrypt. In 2014 it was published that the German police used ElcomSoft as well as Passware, both capable of extracting keys from running machines. I doubt you even need experts for that anymore. Police officers were already on alert to prevent you from shutting down your devices years ago in cases where they assume that there might be evidence on them. I mean we are living in a world where the police is cloning smartphones in routine controls. And on the more sophisticated site, where the police is allowed to infect suspects of even low level drug dealing with trojans. The police isnt stuck in the 90s and they are aided by a rather large sector producing forensic software as well as spyware.

I understand that your product offers great convenience, however its only reasonable to point out, that the need to put in your password after the device was shut off is not a problem but working as intended. Encryption will only protect you if the device is turned off. Circumventing this is not necessarily a good idea.

edit: You also dont have to assume law enforcement. The tools are also affordable for private entities and marketed towards for example towards private detectives.

Even if your adversary have access to the latest and most sophisticated state-of-the-art tools, and have the budget for having technicians to use them, Mandos still does no harm; i.e. does not reduce security. And Mandos is not meant to defend against this; Mandos is instead meant to get people who are not using encrypted disks to start using encrypted disks, since Mandos fixes the (in my opinion) most annoying problem with using encrypted disks.

You are, in effect, arguing about whether encrypted disks are useful at all, which is a debate I’m really not getting into at this time, since it has nothing to do with Mandos.

>You are, in effect, arguing about whether encrypted disks are useful at all

No at all, encrypted disks are very useful, you just cant show anyone the content.

The sole purpose of encrypted disks is to prevent somebody else from reading them once they are turned off. Your product turns them back on and makes it readable again without your interaction. Turning off those devices is however the only protection you had. So now you also need to turn off a second server.

And once someone has access to your running machine he can read it. Be it with simply copying the files or getting the key via some software with a big "HACK" button. https://www.elcomsoft.com/efdd.html

> Turning off those devices is however the only protection you had. So now you also need to turn off a second server.

I’m not sure I follow. If I understand you correctly, you want to have a panic button to press in case of physical intruders, and without Mandos, the power button of a server served this function, and your’re worried that Mandos makes you lose this button? Not to worry. The simplest solution is to have two local servers be the Mandos server for each other, each enabling the other to reboot unattended, and the panic button would be the power button on the power strip powering both servers. Once both servers are off, the system is effectively locked.

If you insist on having a remote Mandos server (which is not really the use case it was made for, but it is supported), you could always automate some button to signal the remote server to disable (or outright remove) the client, thereby denying all access to the secret password. The Mandos server process is controllable via D-Bus, so any program can be made to signal the Mandos server in this way.

With a programmable power strip you could even have a single button doing both things. So there’s your panic button back.

> And once someone has access to your running machine he can read it.

That has nothing to do with Mandos. Anyone with physical access to a running machine can already, in theory, access the memory and get the encryption key. Mandos introduces no additional threat from a theoretical sophisticated attacker.

There is several parts to this, depending on the threat model.

One is the scenarios where both machines are turned off during theft or fishing expeditions from legal enforcement. In this case running encryption, any encryption, is better than no encryption, and Mandos allow the administrator to install it once and forget.

I take it that your concern is that someone has turned off a machine and forgot the Mandos server, and then a time later a attacker has capabilities to break into the encrypted running machine through unrelated vectors. Mandos do not protect against attackers that has capability for breaking full disk encryption on running machines.

The threat model where we assume the attacker can break into an running machine that is encrypted looks very different. Devices that has mitigation against this tend to have in my experience things like movement sensors, light sensors and GPS, with plenty of kill switches that fry the internals if anything look at it funny. Those kind of threat models are fun, and I enjoy talking to those kind of engineers that work on such servers, and to them I don't recommend Mandos.

Where I do recommend Mandos is to the administrator that for reasons are not physical near the server that they maintain. Maybe they work at multiple buildings or travel. They have servers with sensitive services which won't be turned off for long periods but still need reboots once in a while, and yet goes unprotected because there is no one available to write in a password at the physical location.

A other scenario is when people want to treat a location as safe and want protection in transit. In that setup the client can be treated as any unencrypted device for all purposes except when taken outside the local network, at which point it behave like an encrypted device where the person carrying might not even have access to the password. In theory this makes for a great method to transport a work laptop between offices in different countries, booted into an throwaway operative system.

As with any security, thinking hard about the threat model is essential. What are you protecting, who is the attacker, and what are the risks.

Disclosure: I am also a co-author of Mandos.

Re your edit, I always thought lgm was a reference to military garb, not police. Also, many police wear black now.

Makes sense, things got really butchered in the translation. Our police used to be green until, what feels like really recently. So there are still a lot of sayings around involving "the people in green". Now they are apparently blue across the EU.

To me, "little green men" meant aliens.

“Little green men” to me is a reference to the Russian army units that invaded Ukraine without insignia for deniability.

Thats a rather recent one however. The saying is rather old.

Usually, but in this context it's clear that it isn't.

Wow, that looks really cool. However, I use CentOS 7 and that documentation appears to indicate it's not an officially supported distro. Are you aware of alternatives to Mandos (even if they aren't as good) which have official support of RHEL/CentOS?

Sorry, no idea; haven’t heard of any. Mandos is made for Debian for the simple reason that it’s what we use ourselves, and at the time Mandos was created, only Debian had something even approaching the flexibility of initramfs-tools. Nowadays with dracut, it should be possible to port it, but we haven’t looked at it.

On first glance this looks great and solves a real problem. Not sure how I’ve missed this.

Is there much of a plug-in ecosystem for this to support various auth backends?

*edit grammar

I’m not sure what you mean by “auth backend”. By default, the client merely has to prove that it possesses the correct key to be given the secret encrypted password from the Mandos server. This can be changed by configuring the server not to automatically “approve” clients, which makes the whole procedure controllable over D-Bus, opening the way for any process you like to do whatever it needs to do in order to authenticate a client before the secret encrypted password is sent.

Why does the root need to be encrypted? What's wrong with an unencrypted root and /var and /home and swap and /mnt/storage being on encrypted partitions/zpools?

I boot my machines and then ssh into them with a script that pipes a local gpg -d to them to unlock their disks, mount appropriate filesystems, and start necessary daemons. Unless the daemons are poorly-behaved, no data that is specific to me aside from the host's SSH key is ever written to the root - only the OS/distro files.

I thought this is what everyone does.

The root file system still, at the very least, records access times of all files, so an analysis of the the root file system releals, for all programs, when you last ran them, and for all libraries, when they were most recently loaded, etc. With Linux defaults, IIRC this timestamp has a limitied granularity of a day, but this can be telling enough.

I thought most people were mounting things noatime for performance these days.

The noatime mount option is not the default, so no.

That will work if you are sure that all the sensitive information you want to protect goes exclusively to the encrypted file system. Which is a tall order and security headache by itself.

Was fairly leery of how useful I thought this would be, but you reference the FAQ[1] early in what I assume is an attempt to head this off, and it delivers adequately. Despite being predisposed going in thinking it was probably not worth the janky stuff you would have to do to get it working, the level of detail and thorough covering of some fairly complex attack vectors leaves me thinking that while not as secure as no automatic boot method for encrypted disks (obviously), it would definitely be a step up over not encrypting and something I would recommend without worrying that I was increasing the burden of managing the systems to a level an organization would be unprepared to deal with.

Not that I'm some professional security researcher or anything, but congratulations, color me impressed.

1: https://www.recompile.se/mandos/man/intro.8mandos