www.fabiankeil.de/gehacktes/electrobsd/
The Electro Beer Software Distribution (ElectroBSD) is an experimental operating system designed to be used in hostile environments like Germany.
ElectroBSD is (supposed to be) free software but due to unresolved license issues it is currently only released as patchset against the non-free uptream.
According to the Free Software Foundation Europe:
Free in Free Software is referring to freedom, not price. Having been used in this meaning since the 80s, the first documented complete definition appears to be the GNU's Bulletin, vol. 1 no. 1, published February 1986. In particular, four freedoms define Free Software:
- The freedom to run the program, for any purpose. [...]
- The freedom to study how the program works, and adapt it to you needs. [...]
- The freedom to redistribute copies so you can help your neighbor. [...]
- The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. [...]
Electro beer is a dual-use technology
commonly used to resist threats like the computer police
(Computerbullen
).
It's also used by the computer police itself (to wash down transistor doughnuts).
Electro beer first appeared on the German Die Ärzte album 5, 6, 7, 8 - Bullenstaat! (track 7). Here are the lyrics:
Computerbulle naschst den Transistordonut.
Womit spülst Du ihn runter?
Womit spülst Du ihn runter?
Mit 'nem Elektrobier (Elektrobier)!
Elektrobier (Elektrobier), Elektrobier (Elektrobier), Elektrobier (Elektrobier)
Roboterpunker, womit trinkst Du Dir Mut an,
für Deinen Widerstand gegen Computerbullen?
Mit 'nem Elektrobier (Elektrobier)!
Elektrobier (Elektrobier), Elektrobier (Elektrobier), Elektrobier (Elektrobier)
Appropriately the whole album is available as free (as in electro beer) download on the official Die Ärzte website.
ElectroBSD is based on FreeBSD but compiled with
KERNCONF=ELECTRO_BEER (alcohol-free as in no alcohol) and a couple of customizations.
The goal is to make free penetration tests from the computer police
a pleasant experience for the whole family
slightly less annoying for the test subjects and more expensive for the police
(ElectroBSD experts unfortunately aren't cheap).
While ElectroBSD is still incomplete, some features are already available today:
The unencrypted boot pool (and the keyfile) can be destroyed with
cloudiatr
after the system has booted.
An attacker with physical access to the system who does not have the skills or the time to read out the memory while the system is running, will not be able to read the encrypted data on disk after shutdown, even if the passphrase is known. ElectroBSD experts will gladly try (and write bills for their service) anyway.
fk@polizei-erziehung:/home/fk $ sudo cloudiatr soft-protect [...] cloudiatr: Destroying bpool ... cloudiatr: Use 'geli kill -a' to 'hard-protect' your data right now. No recovery without remote backups! cloudiatr: Nuking former bpool vdevs from orbit ... cloudiatr: Done. ElectroBSD should remain working as expected until the next shutdown ... cloudiatr: Remember to 'unprotect' the system before consensual reboots (or use the opportunity to test your backup system)
This is expected to offer protection against most common thieves (without uniform)
and corrupt or incompetent German law
enforcement officers who sometimes trick judges
into signing warrants by withholding important information, but rarely torture or
burn their victims.
Consistent disk encryption also makes it harder to plant believable evidence on you. While planting evidence is officially frowned upon, the risk for an offending police officer is pretty low. Police officers who don't mind falsely accusing people probably don't mind planting evidence either. And now for something completely different: Meineid durch Chorweiler Märchenonkel entfällt.
cloudiatr
's soft-protection is not expected to protect against competent police
officers who get access to the system while it's running, but those aren't expected to
bother law-abiding citizens anyway.
Note that you should still try not do give any third parties physical access to your system, even if it currently isn't running. Once the hardware is compromised, ElectroBSD (or any other operating system) can no longer protect your data.
If you put soft_protection_enable="YES"
in /etc/rc.conf
,
ElectroBSD will automatically enable soft protection while booting.
If a disk (silently) returns incorrect data, this will be automatically detected and, unless you intentionally setup the system without redundancy, the system will continue to work. As an example, this system came with four hard disks of which one was sometimes returning incorrect data instead of answering read requests with an error message:
fk@polizei-erziehung ~ $ zpool status pool: dpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub in progress since Wed Dec 31 23:19:27 2014 135G scanned out of 193G at 26.2M/s, 0h38m to go 256K repaired, 69.72% done config: NAME STATE READ WRITE CKSUM dpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/dpool0.eli ONLINE 0 0 0 gpt/dpool1.eli ONLINE 0 0 1 (repairing) gpt/dpool2.eli ONLINE 0 0 0 gpt/dpool3.eli ONLINE 0 0 0 errors: No known data errors
Thanks to OpenZFS this was
detected in time and corrected without data loss. Most of the competing file systems
do not detect silent data corruption like this and will gladly forward
corrupt data to the application. In case you haven't read enough about silent data corruption
yet, you may be interested in a large-scale study of silent data corruption based on field data from 1.53 million disk drives
.
Tor itself is not actually part of the ElectroBSD base system, but it is expected that most users will install it from ports unless the system is air-gapped anyway.
No changes to the operating system itself should be required to create a proper Tor relay:
net.inet.ip.random_id
defaults to 1 and
bge's ASF feature
is disabled to prevent it from negatively impacting the relay's uptime.
The might to deliver onions will be further improved in the future, for details see the list of missing features below.
You may not like the prison industry, but there are lots of reasons to love FreeBSD jails. They are especially useful for running onion services (Tor location hidden services) that have no idea what the system's external IP address is and thus can't leak it. Jails are frequently used by people whose judgement is not clouded. Unlike Docker, nobody seems to have found a reason to boycott FreeBSD jails yet.
ElectroBSD itself (kernel + world), the distribution tarballs (base.txz, kernel.txz, lib32.txz, src.txz) and thus the MANIFEST can be built reproducible on all the supported architectures (a fancy way to refer to amd64 and i386). So far this has only been tested with ElectroBSD as build system, but it should work when building on FreeBSD as well.
There's work in progress to make the release image reproducible as well.
Note that ElectroBSD installations done with
cloudiatr
are not reproducible at the
file system layer (inode numbers, block location etc.) and given the complexity of
ZFS this is unlikely
to change anytime soon.
If you aren't sure why you should care about reproducible builds, please have a look at the Debian FAQ.
Did you ever wonder how the kernel is spending its time? With DTrace you can simply take a look – while the system is running. For example to see how a given kernel function is reached and how often:
fk@r500 ~ $sudo dtrace -q -n 'fbt::reap_arc_caches:entry {@[probefunc,stack(3)] = count(); reaped++} \ tick-10s /reaped == 0/ {printf("%Y: Why you no reaping?\n", walltimestamp);} \ tick-10s /reaped/ {printf("%Y: ARC reapings detected:\n", walltimestamp); printa(@); trunc(@); reaped = 0}' 2015 Sep 5 14:55:10: Why you no reaping? 2015 Sep 5 14:55:20: ARC reapings detected: reap_arc_caches zfs.ko`consider_reaping_arc_caches+0xa6 zfs.ko`arc_get_data_buf+0x1c7 zfs.ko`arc_buf_alloc+0x108 1 2015 Sep 5 14:55:30: ARC reapings detected: reap_arc_caches zfs.ko`consider_reaping_arc_caches+0xa6 zfs.ko`arc_get_data_buf+0x1c7 zfs.ko`arc_buf_alloc+0x108 7 2015 Sep 5 14:55:40: ARC reapings detected: reap_arc_caches zfs.ko`consider_reaping_arc_caches+0xa6 zfs.ko`arc_kmem_reap_now+0x98 zfs.ko`arc_reclaim_thread+0x260 3 reap_arc_caches zfs.ko`consider_reaping_arc_caches+0xa6 zfs.ko`arc_get_data_buf+0x1c7 zfs.ko`arc_buf_alloc+0x108 18 ^C
Given enough DTrace, all performance issues are shallow. DTrace can also be used to monitor disk encryption keys.
Just like Stuxnet, systemd does not
work run
on ElectroBSD.
Theoretically systemd could be ported to the BSDs, but
its inventor promised to keep it unportable. Thanks, Lennart.
GNU/Something
ElectroBSD still contains traces of GNU which were inherited from upstream, but no new GPL stuff will be added to the base. Several upstream developers are working hard on getting the remaining GPL'd parts in the FreeBSD base system replaced. The work is nearly done.
Obviously you can still install GNU software from ports. In fact, this page was made with GNU Emacs.
For additional features, please have a look at FreeBSD's Technological Advances (which ElectroBSD inherits).
While ElectroBSD already looks pretty decent (if I may say so myself), some mundane details have room for improvement and the following (unsorted) TODO list is rather long and yet incomplete.
rether
with depends on the perl port.And finally:
Fuzzing (on) FreeBSDslides.
Due to license issues and lazyness ElectroBSD is still not officially available online in binary form. It is built from a patched FreeBSD source tree which contains non-free parts inherited from upstream that can't be distributed freely. While the ElectroBSD build script (reproduce.sh) will automatically remove known non-free parts, it is expected that not all the non-free parts are known yet.
2016-02-04: A slightly redacted ElectroBSD patchset (signature) is available online now. When applying it on top of FreeBSD r295083 (11-CURRENT) and using the following /usr/src/reproduce.conf (not part of the patchset):
fk@r500 ~ $cat /usr/src/reproduce.conf BUILD=ElectroBSD-r295083-0c7f4d6 EPOCH=1454184620
with a ElectroBSD-r295083-0c7f4d6 userland, reproduce.sh is expected to generate the following binaries on amd64:
SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/MANIFEST) = 570a1a701ddd59515695c0667565a279a3fb971e38f42d5c7c15d9063a1482b6 SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/base-dbg.txz) = c181100dc22e3a81d02ce38b3e1bed804af149c289d21bf12b88e9fbf81dfa15 SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/base.txz) = 8744b34846b0354705a9f9b98d01275e8682ceea4078e2057e127675a721d9b8 SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/kernel-dbg.txz) = 1e1a4dba34a6bc507105d5ea0bcb57f6fa0d66917e6208d50a2510702fade35b SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/kernel.txz) = 14957575db057e549bfc9b8871923f504756931caaa73fe523cf94e400afefc9 SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/src.txz) = 81457e259f9b6910ffed9ee82074c4e00bde07f762e8f1fb185561836847766d SHA256 (/usr/obj/usr/src/release/ElectroBSD-r295083-0c7f4d6/tests.txz) = 5cbcc2faaf391f7347229d6bb2cd71b9d3de6f18a6bc3db75f08b0d1a44c079c
After building the ElectroBSD-r295083-0c7f4d6 userland on FreeBSD you should be able to use it to reproduce the results above. This has been tested starting with FreeBSD 10.2, but it should work with any other version that is recent enough to build FreeBSD r295083.
If you rebase the patchset on top of a more recent FreeBSD revision, you frequently still get reproducible results, but occasionally there are upstream regressions that require new fixes.
Builds on i386 are generally expected to be reproducible as well, but due to
laziness lack of computing power this is tested less often,
so regressions are not always detected right away.
This code drop has been rushed, the instructions will be fleshed out in the near
future this century.
2017-01-26: Here's a more recent ElectroBSD patchset (signature) against FreeBSD r312620 (11-STABLE). The expected hashes for amd64 and i386 are included in the commit message for the last commit which adds reproduce.conf.
2021-12-02: ElectroBSD has been rebased on FreeBSD stable/12. ElectroBSD patchset (signature) against FreeBSD stable/12 8facf7082d4973ae. The expected hashes for amd64 are included in the commit message for the last commit which adds reproduce.conf.
2022-08-28: ElectroBSD has been rebased on FreeBSD stable/13. ElectroBSD patchset (signature) against FreeBSD stable/13 c4c0c782f7097bc7. The expected hashes for amd64 are included in the commit message for the last commit which adds reproduce.conf.
You can support ElectroBSD development by donating to the Privoxy project (tax deductible in some countries). ElectroBSD is not actually developed by the Privoxy project, but the more hours spent on Privoxy ElectroBSD developers can bill, the more unpayed hours they can spend on ElectroBSD-related activities.
Please let me know if you want to fund ElectroBSD-related work directly, in which case you can not only influence what is being worked on (to some degree), but also get a proper bill from:
This should be tax-deductible if you use ElectroBSD for profit.
There's work in progress to create an ElectroBSD Moral License which will be modelled after the Varnish Moral License.
Current ElectroBSD funding: 0 EUR, operating at a loss which is unsustainable in the long run.
Dear BSI and friends: Your money is welcome here, too.
Funding ElectroBSD does not support the malware industry and certainly makes more sense than wasting taxpayers' money on zero-day exploits.
According to the totally leaked endorsement to the right
(classification: NvE),
the Bundeswehr
(federal defence
forces of Germany) only had good things to say
about providing at least one of the ElectroBSD developers with taxpayer's
money in the past.
Unless you have the proper clearance (apparently you don't) the endorsement
will appear slightly redacted to increase its comedic value, to make it look more
important and to prevent the
MAD from getting upset mad.
Note that none of the blacked out parts are about electro beer (or any other beverages).
Is this ElectroBSD thing a joke?
Of course not. What a rude and offensive question. Did you miss the serious business section?
Feel free to test the seriousness by donating. If your donation doesn't bounce, ElectroBSD is probably legit. The bills are legit, too, and payment isn't optional.
Why should I use ElectroBSD?
Who said you should use it? Unless you are an ElectroBSD developer or want to become one in the future, you probably should not (try to) use ElectroBSD as your main operating system at this time.
If you are an experienced FreeBSD user or developer, you may want to cherry-pick the patches that remove known non-free stuff and allow to build the system reproducible, though.
What does the ElectroBSD uname output look like?
On my development system it looks like this:
fk@t520 ~ $uname -a
ElectroBSD t520.local 12.3-STABLE ElectroBSD 12.3-STABLE #5 electrobsd-n234640-817fe7d130ce-dirty: Wed Dec 1 10:36:51 UTC 2021 fk@t520.local:/usr/obj/usr/src/amd64.amd64/sys/ELECTRO_BEER amd64
Production systems are currently based on FreeBSD 12.3-STABLE.
Wait a minute, isn't 'ElectroBSD' just a fancy name for 'vanilla FreeBSD plus a couple of patches minus the non-free blobs'?
That's a very astute observation, how did you figure it out?
Does ElectroBSD work outside of Germany?
It depends on your definition of work
.
Obviously there is no region code to prevent you from using ElectroBSD outside of Germany. It is, however, not recommended to use ElectroBSD in other countries without first checking the relevant laws about encryption and the investigation methods commonly used by the local (computer) police and related threats.
If you are unfortunate enough to live in a jurisdiction where the DMCA and software patents are relevant, you may want to define DMCA_MAY_BE_RELEVANT and SOFTWARE_PATENTS_MATTER before building and redistributing packages from the ElectroBSD ports tree. Note that the commonly used ElectroBSD package builders (obviously) do not define those variables.
Does ElectroBSD run on other people's computers ("the cloud")?
Yes. So far this has only been tested with Amazon (EC2) and Rackspace but it should work elsewhere as well. If the hoster doesn't provide an ElectroBSD image (most currently don't), one can use these steps:
cloudiatr evict
Clowning around with an additional disk is only required if there isn't a FreeBSD rescue mode that allows to overwrite the main disk right away.
For obvious reasons running ElectroBSD on computers you don't control is only
recommended not frowned upon for stuff like
redundant ggated sinks (which receive encrypted blocks)
and Tor relays etc.
Be aware that sometimes it gets stormy in the cloud in which case you should expect your cloud hoster to be unprepared and lose your data:
Google says data has been wiped from discs at one of its data centres in Belgium - after it was struck by lightning four times.
Some people have permanently lost access to their files as a result.
Hopefully said people have also learned something about the risks of clown computing without reliable backups.
How many intentional backdoors does ElectroBSD have?
Roughly about as much as FreeBSD itself, hopefully zero. Please help auditing the code
to confirm that zero
is a good approximation.
How many bugs does ElectroBSD have in general?
A lot less than Klendathu, but certainly more than zero. To get an exact number, simply solve the following equation for x:
a - b + c = x
Figuring out the following unknowns is left as an exercise for the reader:
Does the ElectroBSD project have a code of conduct?
Only one? ElectroBSD has two!
Direct ElectroBSD contributors that feel like it are expected to respect the Road House code of conduct. As the great philosopher James Dalton explained it:
All you have to do is follow three simple rules.
- One, never underestimate your opponent. Expect the unexpected.
- Two, take it outside. Never start anything inside the bar unless it's absolutely necessary.
- And three, be nice.
The short version is: I want you to be nice until it's time to not be nice.
For details, please watch the (unfortunately non-free) movie. Incidentally it is also used to train members of the New York police department (NYPD).
Update: This policy was clarified on 2017-09-16 (Software Freedom Day!).
Obviously the ElectroBSD code of conduct for humans is only relevant for people who actually want to follow it. Currently all direct ElectroBSD contributors do but in the future this might change and now the policy can handle this.
If you consider spending lots of developer time on code of conducts a good idea,
you may be an idiot want to reconsider. If you understand German, the
code of conduct of the FSF e.V.
is probably worth a look.
Software that is (re)distributed by the ElectroBSD project is expected
supposed to follow this code of conduct:
- One, be reproducible.
- Two, be freely distributable without causing legal issues.
- Three, be free of bugs.
Violators that get caught may be modified or deleted without warning.
Like most other code of conducts this code of conduct uses terms that aren't properly defined and can therefore be enforced in an arbitrary fashion. Mission accomplished.
Can I bootstrap ElectroBSD by exploiting HardenedBSD?
While this is generally considered a bit silly, it has been done in the past. Note that the exploited flaw got fixed, though, so you would have to find another one or use an unpatched HardenedBSD version.
How do you patch KDE2 under ElectroBSD?
I don't.
What's up with this Cloudflare garbage I'm sometimes seeing when using Tor on ElectroBSD?
According to themselves, Cloudflare is a Web Performance & Security Company
from San Francisco.
Cloudflare improves performance and security by intercepting requests from Tor exit relays (and probably lots of other addresses). The more innocent users they prevent from accessing the real web server (and presumably count as threats), the better the performance gets for the ones that remain.
Obviously this approach is pretty silly (which might explain why
cloudflare.com remains unprotected),
but apparently they managed to sucker a bunch of other cloud
people into using this
service anyway.
You can work around this nonsense by accessing the protected website without Tor and supposedly allowing the browser to execute unsigned and untrustworthy third-party code can help, too, but it probably makes more sense to boycott the protected websites until they allow privacy-conscious users to access their websites like anybody else.
Note that this is not an ElectroBSD-specific problem, Cloudflare knowingly degrades the clouded parts of the web for Tor users in general.
Why doesn't the ElectroBSD website bear the highly amusing 'TeleTrusT quality seal "IT Security made in Germany"'?
According to the TeleTrusT Initiative "IT Security made in Germany", bearers of the seal:
be headquarterd in Germany,
trustworthy IT security solutions
solutions that contain non-declared backdoors,
IT security research and development ... in Germany,
compliant with German data protection lawand
Kostenumlage).
After careful deliberation it was decided that the last requirement is a show-stopper.
If the seal is important to you, you can donate now to change this.
Please earmark your donation TeleTrusT quality seal 'IT Security made in Germany'
to make sure your money isn't accidentally spent on actual security improvements.