Hacker News new | past | comments | ask | show | jobs | submit login
Obscurix – Arch Linux-based OS configured for privacy, security and anonymity (obscurix.github.io)
88 points by URfejk on Oct 18, 2020 | hide | past | favorite | 24 comments



A comparison with Tails would be nice.

A big difference is the base distro.

I used Arch for many years, so I love it as daily driver.

But for a security-critical context such as this, Debian with it's stability and very security-aware package maintainership seems like a better choice.

Some answers are in the FAQ: https://obscurix.github.io/faq.html


>But for a security-critical context such as this, Debian with it's stability and very security-aware package maintainership seems like a better choice.

Or Centos.


In my experience CentOS means EPEL and EPEL means throwing that stability and security-aware packaging out the window.


This. Rationale is SELinux.


Linux security modules, always good to have. AppArmor, SELinux, Smack, and TOMOYO are good examples.


How does this compare to Qubes+Whonix ?


> How does this compare to Qubes+Whonix ?

From Obscurix FAQ:

"Whonix is another anonymity focused operating system. It is meant to be run inside virtual machines instead of from a USB like Obscurix. Whonix has a more leak-proof method of forcing all traffic through Tor but it isn't amnesiac or forensics resistant like Obscurix."

Basically, Whonix requires a VM sandbox escape in order to leak your IP address. Obscurix does not have any comparable protection against malicious applications leaking your IP address. The purported advantage of Obscurix is its "amnesiac" property, but it doesn't sound very compelling. Everyone should be using full disk encryption in any case, regardless of what OS they are running or what other steps they are taking to improve security. It's not clear to me why I should care about the amnesiac property of the OS when everything is encrypted.


> Everyone should be using full disk encryption

Should they? Regardless of threat model? It's point and click easy on macOS (and probably Windows) so sure why not, but a bit more involved on Linux. I think encrypt a directory (ies) that actually warrants protecting is enough for most people, where the threat is casual even opportunistic theft rather than an organised, targeted attack.


I can't recommend directory-level encryption when full-disk encryption is so easy these days. It's a few clicks in the Fedora installer or a few commands with Arch Linux. It comes out of the box on new MacBooks and most new Windows laptops (although the more secure BitLocker option requires Windows 10 Pro).

Directory-level encryption is harder to set up and use—it requires typing your passphrase more often and makes you choose third-party software instead of using the features built into your operating system. Plus, lots of important files, like your browser's autofill information and other files that aren't considered "critical", are left wide open.

Encrypting your home directory is better than encrypting the "TOP SECRET" directory, but it's still just as hard as setting up full-disk encryption while being less effective.


In my opinion, it's way harder (and riskier - screw it up and you can't boot, vs. login as a different user and fix it in the case of critical dir, or same user and fix it if not). The Arch Wiki pages are far longer and more off-putting than running whatever you want post-boot in PAM or even ad hoc or from systemd/.profile if it isn't home dir.

And what's the difference in what you're protecting that affects the average user? Why stop at FDE - they should be worried about cold-boot attacks too right!?


> I think encrypt a directory (ies) that actually warrants protecting

My first thought as an adversary would be "Hey! This looks out of place! this guy must really want to protect whatever this is".


Depends on the distro, but it's trivial in ubuntu-based and no harder than the rest of basic setup in arch (the only two I have recent experiece with). I'd argue that any distro where it isn't easy is a good reason to start looking elsewhere, absent any specific conflicting requirements.

Not sure it matters if it's full-disk vs just home directory, but full disk is easier to reason about and I don't recall an OS that can do homedir easily but not full-disk (there very well could be one, just none come to mind).


It can range from trivial to impossible. Full disk encryption does not play well with hybernation on laptops, for example. There is also very limited support for hardware encrypted ssd... And even though it can potentially be a few arch commands away, you need to do a lot of reading to understand what you're doing and make informed choices about your setup. Which is hard.


You're right.


Amnesiac is a level above FDE. You can’t be compelled to decrypt that which does not exist.


Can you describe to me a practical use case where use of Amnesiac is warranted, but encryption of data is not?

If you're uploading whistleblower documents to Wikileaks, sure you could use Amnesiac to do the upload, but where are the documents? Are they on an unencrypted USB stick? You clearly need encryption for this use case.

Are you buying/selling drugs on the Tor network? You probably need some cryptocurrency keys, where are they? On a USB stick in plain text? You clearly need encryption for this use case.

Or maybe you're a security researcher who's trying to anonymously report a vulnerability to a corporation that's known to go after researchers. Where is your poc code? On an unencrypted USB stick? You clearly need encryption for this use case.


Not that it'd probably make sense very often, but you could do bitcoin or other cryptocurrencies without having a persistent wallet digitally. You could have a paper backup and/or a memorized secure phrase easily. Been a while, but Electrum could do both years ago, I'm sure many others can as well.

Also, more importantly, why are encryption and this amnesiac property mutually exclusive? Can't you do both and use the strongest available guarantees that are applicable to a particular set of data? Seems like it'd at least make the job of an attacker more annoying at the least.


> Also, more importantly, why are encryption and this amnesiac property mutually exclusive? Can't you do both and use the strongest available guarantees that are applicable to a particular set of data?

Sure. The amnesiac property just doesn't add a lot of security on top of full disk encryption. If you have an encrypted USB stick that contains an amnesiac OS and $TOP_SECRET_DOCUMENT, the information that your adversary cares about is the document. If the adversary somehow breaks the encryption, they still get access to the document, regardless of the amnesiac property of the OS.


Don’t store locally.


So... you can't provide an actual example?

If I was working on important whistleblower documents, I wouldn't trust a cloud storage service as the sole location for the documents. I would need at least some form of backup. Furthermore, if the point was to hide the existence of encrypted data, you would have to also hide your payments to said cloud service provider. So at this point we would need to:

- Set up (locally encrypted) storage to cloud service provider 1, and a similar backup to cloud service provider 2.

- Learn cryptocurrency washing mechanism to hide continuously ongoing payments to cloud service providers.

Note that both of these would have to remain in your memory, since you wouldn't be able to save anything (like "download_encrypted_data_from_cloud_storage.sh") on the amnesiac OS.


Nothing personal. There’s a ton of different possible ways to approach the problem. If you can’t construct reasonable approaches with amnesiac setups, you can still combine it with FDE for data storage. A lot easier to swallow a microSD card than a hard drive. Tails supports this mode of operation built-in. A persistent OS that is not amnesiac will leave a lot more metadata.

But you can totally set up a “download encrypted blob from external data storage” script if you want. You can do a whole lot depending on what resources you have available.


> But you can totally set up a “download encrypted blob from external data storage” script if you want.

Remember where this conversation started? You said "Amnesiac is a level above FDE. You can’t be compelled to decrypt that which does not exist." Well, if the USB stick that contains the amnesiac OS also contains a script for downloading an encrypted blob from cloud storage, then obviously we are back at the "being compelled to decrypt" issue that we started from. If we're going to have an encrypted $TOP_SECRET document, we might as well encrypt the whole disk. And at this point the amnesiac property of the OS doesn't really provide a lot of benefit.


You need a bootstrap process. That requires some ingenuity, and you are going to be hard pressed to have people drop their solutions in a public forum. :)


I understand the use cases for certain Linux distribution spinoffs that can eliminate complexity but it also breaks my heart when they use an ultra customizable distribution like Arch Linux.

Typically, I will [1] customize my own installation media to do or contain whatever software or configurations I need without a third-party making assumptions for me. This is quite possibly what I like most about Arch Linux. I know what is going on under the hood because I set it up. I'm likely not a typical user for most spinoffs. I use Arch Linux, FreeBSD, Gentoo, RHEL, Debian, SLES, and Ubuntu for different use cases as required.

[1] https://wiki.archlinux.org/index.php/archiso

*EDIT: Forgot and added a couple distros that I actively use (wish I could consolidate to one. Maybe one day)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: