The curious case of the Raspberry Pi in the network closet (2019)

But by trying to mitigate the risk of toxicity you can go too far in the other direction and end up not pushing smart kids to reach their full potential, which is also bad. Striking the right balance is hard.

Probably by actually connecting it to the internet. Since the idea that you can keep people out of your network is probably more dangerous in the long term.

The first version of the program used a simple UDP broadcasting method to a hard-coded port to find servers, which required some rudimentary networking knowledge, but only basic TCP/IP stuff.

Later, both the server and client parts have gone through numerous refactorings which brought in many features (like a plugin system on the client side, and a D-Bus interface on the server side), but those were manageable chunks to add to an already mature and working system.

But sure, in addition to the knowledge one could acquire from LFS, I also had some high-level knowledge of how TLS and its handshake worked, I knew that there was some way to use OpenPGP keys instead of X.509 certificates in TLS, and I knew a little about how DNS-SD worked. The rest I needed I read up on as I wrote the code.

Yes, that is a weakness, which is openly addressed in the FAQ: https://www.recompile.se/mandos/man/intro.8mandos#quick TLDR: It only works if an attacker is pretty quick about it. See also here: https://www.recompile.se/mandos/man/intro.8mandos#security

> And what about the vector where someone attacks the CA that issued the certs?

There is no CA involved, nor any X.509 keys. The keys used in TLS are ed25519 raw keys, and the server has a list of, and checks, individual key fingerprints.

> This may be moot if you are using self-signed certs, but of course those introduce their own management issues.

Yes, you have to generate and transport keys out-of-band (i.e. by hand) as part of the initial setup. The instructions on exactly how to do this are shown as part of installation and configuration.

> a pretty gnarly fail-closed kill switch

That’s a feature. A security system should fail closed.

> Presumably there’s a mechanism that allows a self-destructed pair or cluster of these [mandos]’d servers to go back to a normal operating mode?

Yes. You either type in a password on the console on one of the servers, or use a dropbear to ssh in remotely to do it.

> A section called “reasons you may not want to use this” that is very up front about those seems appropriate.

The project is mostly intended for those people who have already decided that full-disk encryption is a requirement, and Mandos is meant to alleviate some of the pain which they have already accepted. But sure, I see your point.

Teddyh's answer describes some of the technical aspects, through I would like to add the security scenarios that Mandos works to address. Any security measure is in one way or another designed with known threats, assets and costs/outcomes.

If one operates a bunch of servers with FDE in a server room, getting there every time there is a need to reboot is a significant problem. To mention a few causes, redundant nodes going up and down in the middle of the night, updates to the operating system and kernel, and misbehaving hardware. At the same time, those servers are likely to hold a lot of sensitive data to companies or persons, especially email, which puts the administrator at conflict between using full disk encryption or not using it. In my experience, unless there are regulations that dictate otherwise, servers are not encrypted because of the hassle and downsides of manual or needing to attend reboots in person. This was the initial case as to why Mandos was created many years ago. If the server hall loses both primary and backup power, there is a real risk that the administrator does need to travel there to bring the machines back up. That would be one of the major trade offs, through I would still recommend administrators to do that, compared to the risk of an unencrypted disk getting lost, stolen, or cases where someone comes in and takes all the servers.

There are naturally other scenarios that one can use Mandos for, but like any tool it's good to know whats it is designed for. It is not intended to replace setups where one is already using FDE where one types in the passwords manually at the terminal and is happy with it. If one does not need the unattended aspect but want to remotely reboot the server, there are things like Dropbear or IPMI/remote KVMs, in which case the security will rely on those components' security. In my experience, IPMI's security should not be exposed to the internet which means one first needs a security entry point to the local network. Dropbear uses ssh which mean one should use client certificates and verify the signature before use. Depending on the use case and what risks one wants to take there are benefits and drawbacks, but the key point I do want to come back to is that people really should use full disk encryption and Mandos alleviates the primary reason people don't use FDE.

Logging anonymized MAC addresses is one thing, but converting the MAC addresses to employee names, revealing their location on premises that is shared with everyone in the organization without their consent is a completely different thing and is illegal under most EU privacy laws (at least in Austria and Germany).

Sure, in theory the company could already know when I come it at work from the logs of me swiping my access badge at the main security entrance door but any such logs are kept private and can only accessed by security and upper management if some act of theft or gross misconduct has occurred which warrants an investigation.

Sharing this information publicly with everyone in the org would be a privacy breach. If you want to know if I'm "at work" just look at my Slack/$CHAT_APP notification color.

Don't plug shit into private networks unless you want it reverse engineered. This falls under the fair use exceptions (learning what software is doing / was doing to your network).

The copyright holder can take it up with whoever they licensed it to, there is a reason a lot of them read "not to be used in the commission of a crime".

It’s often the case that somebody slapped something together in an area that wasn’t their expertise, it’s been noticed that it’s a real problem, and someone has been hired to fix that problem. The “not knowing” is often the reason they’ve been hired. Trying to sort out a real world scenario (while also handling other needs of the org) is almost definitionally Taking Responsibility. So let’s not shit on people trying to cleanup a bad situation by calling them irresponsible for not knowing.

The more senior I get, the more I realize there are often a multitude of reasons things are the way they are, and many times those are valid reasons, when seeing something that is broken.

Taking a beat before pontificating and making a fool of yourself will save a ton of heartache in your career.

When you see something so broken, ask yourself why? Then ask somebody else. Some highlights from my career:

1) Last guy got cancer in the middle of a build.

2) Last guy worked his way up from one man help desk to Linux guru over 15 years all on his own, but was so busy putting out fires, he never had the chance to improve things.

3) Project started out as a proof of concept and was intended to be torn down.

4) Due to government contracts, the system has to be maintained exactly as delivered, no labels even allowed, and obviously no IT staff(?!) To make spreadsheets. Everything was paper notes by operators.

5) Pure laziness and incompetence as you alluded to.

All this to say, more often than not there is a good reason something is fucked up, finding out why may help you fix it (like in the case of politics, budget issues, firefighting, priorities, etc..)