Computer Security - Level: Paranoid

ParanoidAndroid · 2014-05-20 22:26:17

I'm working on a new install of Arch (with an eye on the possibility of moving to Gentoo) and made the decision to attempt the creation of a paranoid system on par with 1984's predictions for the future.

So far, I have a few questions:

1. What kernel mods are necessary? I imagine basic hardening and fine-grained access control are a given, but what exactly does that entail?

2. I already use encryption (I've upgraded to serpent-xts-plain64 with the whirlpool hash), but what about having a hidden OS? That is, ensuring "plausible deniability?" I've heard many debates on the relative merits or lack thereof of this feature, and I've decided that I'd like to have it -- if it's possible to implement it effectively and in a way that actually works.

3. for maintenance and performance reasons (as well as for protection against certain types of attacks) I've split /usr into a separate partition. Yes, I know this isn't standard practice, and that many don't recommend it for one reason or another. That aside, I'd like to know which filesystem would be best for /usr (this is on an SSD, mind) and what mount options should be enabled to ensure security.

4. I already use TOR and privoxy, along with iptables to ensure that no traffic goes over the network except through TOR. Are there any other network security/anonymity practices I should implement software-wise? My browsers don't use flash or javascript, nor do they accept cookies (except for a few rare exceptions). Which reminds me, Privoxy doesn't seem to filter JS or flash, or cookies for that matter, despite the fact that I have it set to do just that... anyone know why this is?

ewaller · 2014-05-20 22:53:37

ParanoidAndroid wrote:

Are there any other network security/anonymity practices I should implement software-wise?

Air gap?
Temest?
HSM?

Avoid any rooms numbered 101?

ANOKNUSA · 2014-05-20 22:56:24

Unless you've got the motherlode of the sort of data only a horrible, horrible human being would possess on your system, no one's gonna bother trying into something like what you've already got, and tightening security further would more likely make your system unusable. As for ensuring "plausible deniability," it's always a fool's errand with regard to computers on account of the "plausible" part. There's a computer in your home; it's positioned on the desk you work on, in front of the chair you sit in, with your stuff scattered around it. It has your fingerprints all over it. Your credit card and bank records enumerate the hardware purchases. You have an account with an ISP. You live in the modern world. The only thing dumber than the idea that you don't use that computer would be to insult the intelligence of the guy holding the rubber hose. If you're under suspicion of using your computer to commit illegal acts, and the state is already suspicious or aware of that fact, the same technology you used to commit said acts will not save you.

ewaller · 2014-05-20 22:59:22

... And don't forget. Data are only safe if it costs more to steal than the data are worth.

ParanoidAndroid · 2014-05-20 23:01:11

@ewaller
Your sarcasm is duly noted. Funnily enough, it's not actually helpful... hmmm.

I know that the vast majority of people believe this level of paranoia is not justified, but that's hardly the point. I asked four simple questions, and I'd like decent, pertinent, germane, legitimate answers to those quesions. Ideally ones that don't involve mockery.

I agree that plausible deniability isn't really plausible, provided someone is in the least suspicious. I was thinking more like "hey you're at the border, let's have a look at your computer because we can"-type thing.

As far as being a horrible human being goes, I never really appreciated that argument. It isn't that I'm hiding anything illegal or wrong, it's more a way of giving the finger to the various institutions who don't respect the meaning of the word "privacy." I don't care what you make of that, I just want my questions answered.

Last edited by ParanoidAndroid (2014-05-20 23:06:36)

ewaller · 2014-05-20 23:04:59

If you are responding to me, I was not being sarcastic. What is it that you are trying to protect? That is the first question that must be asked in any security evaluation.

rune0077 · 2014-05-20 23:10:30

ParanoidAndroid wrote:

@ewaller
Your sarcasm is duly noted. Funnily enough, it's not actually helpful... hmmm.
I know that the vast majority of people believe this level of paranoia is not justified, but that's hardly the point. I asked four simple questions, and I'd like decent, pertinent, germane, legitimate answers to those quesions. Ideally ones that don't involve mockery.
I agree that plausible deniability isn't really plausible, provided someone is in the least suspicious. I was thinking more like "hey you're at the border, let's have a look at your computer because we can"-type thing.
As far as being a horrible human being goes, I never really appreciated that argument. It isn't that I'm hiding anything illegal or wrong, it's more a way of giving the finger to the various institutions who don't respect the meaning of the word "privacy." I don't care what you make of that, I just want my questions answered.

Problem is of course, that said institution have already proven time and again, that you can't really give them the finger. We know by now that Tor isn't safe, VPN's aren't safe, SSL isn't safe.

You can certainly protect yourself from the common criminal, but not from those institutions, except of course by not being online at all.

But I do agree, anyone who isn't paranoid by now, is hopelessly naive :-)

Last edited by rune0077 (2014-05-20 23:11:38)

ParanoidAndroid · 2014-05-20 23:11:03

*whips out a tinfoil hat*

@ewaller
I'm looking to protect against a government who doesn't respect my rights. That's as far as I've gotten. I was reading an article in the Gaurdian from the founder of LavaBit regarding the circumstances surrounding its closure... that's what got me thinking along these lines.

@rune007
My, that's depressing. I knew SSL was shot, but I was pretty sure TOR still works for concealing one's exact location.
I realize that web traffic is pretty much out in the open, so what about my personal data?

Last edited by ParanoidAndroid (2014-05-20 23:13:32)

2ManyDogs · 2014-05-20 23:11:42

ParanoidAndroid wrote:

I'm working on a new install of Arch (with an eye on the possibility of moving to Gentoo)

You might also want to ask these questions on the Gentoo forum. I would be interested to see what kind of responses you get there.

Last edited by 2ManyDogs (2014-05-20 23:13:04)

ewaller · 2014-05-20 23:36:35

rune0077 hit the nail on the head.

ParanoidAndroid,

Okay, so the answer is not that you are trying to protect data, per se. No stored credit card numbers, banking credentials, design secrets, corporate financial data, employee salaries, private keys, etc... You are interested in maintaining anonymity on the Internet. So you are less concerned with intrusions than with having your identity and data obfuscated as they transition a very public network.

You don't really need to harden your computer. Especially if you control and have exclusive access to it. If you don't, forget it. Also, If anyone can gain access to your machine against your will, forget it. Having a mechanism to automatically zero private keys will help, but it is not fool proof (HSM). Your problem is that it is not possible to protect the end points of communications. TOR helps in that regard, but its weakness is still entry and exit points. If you can control your keys, and don't care if people know that it is YOU that is sending and receiving encrypted data, and potentially who is at the other end, you are probably good. If you cannot afford that, you have to Air Gap your system and hand carry data in and out.

Even encrypted data are not perfect. They are good, unless you draw the attention of a government. How strong are your keys? Are you sure? How did you generate them? Where did the entropy come from?
Did you know that differential power analysis side channel attacks can be used to effectively reduce key strength by several, if not dozens, of bits? (TEMPEST)

The point is, your practices are pretty good if you want to keep Google or Proctor and Gamble from knowing what kind of tuna you buy, or maybe even good enough to prevent a political opponent from knowing your taste in porn. But if you were to become a suspect in something that might interest Interpol, you are not going to be able to hide in the environment described by rune0077. Just like Winston Smith.

Edit: Oh, and how are you doing key exchange? Are you sure you are talking to the person you think you are (Man in the Middle)? If you are using public key encryption and are using signed keys (certificates), then people know who you are anyway (if you use a key server). Without a key server, how did you securely exchange keys?

Last edited by ewaller (2014-05-20 23:45:22)

Stebalien · 2014-05-20 23:39:31

ParanoidAndroid wrote:

1. What kernel mods are necessary? I imagine basic hardening and fine-grained access control are a given, but what exactly does that entail?

Weeks of work. Here's a starting place: https://wiki.archlinux.org/index.php/Security

Unfortunately, fine-grained access control for desktop applications is pretty much impossible because many of them will require access to either dbus, the X server, etc. (and you can't easily filter this access).

ParanoidAndroid wrote:

2. I already use encryption (I've upgraded to serpent-xts-plain64 with the whirlpool hash), but what about having a hidden OS? That is, ensuring "plausible deniability?" I've heard many debates on the relative merits or lack thereof of this feature, and I've decided that I'd like to have it -- if it's possible to implement it effectively and in a way that actually works.

Unfortunately, you can't do that with cryptsetup because the (cryptsetup) author thinks the whole "plausible deniability" thing is pointless. Anyways, unless you make sure to use your non-hidden operating system frequently, it'll be kind of obvious that you're using a hidden operating system.

ParanoidAndroid wrote:

3. for maintenance and performance reasons (as well as for protection against certain types of attacks) I've split /usr into a separate partition. Yes, I know this isn't standard practice, and that many don't recommend it for one reason or another. That aside, I'd like to know which filesystem would be best for /usr (this is on an SSD, mind) and what mount options should be enabled to ensure security.

I'm pretty sure you CAN'T do that in arch. Anyways, this is unlikely to give you any extra security.

ParanoidAndroid wrote:

4. I already use TOR and privoxy, along with iptables to ensure that no traffic goes over the network except through TOR. Are there any other network security/anonymity practices I should implement software-wise? My browsers don't use flash or javascript, nor do they accept cookies (except for a few rare exceptions). Which reminds me, Privoxy doesn't seem to filter JS or flash, or cookies for that matter, despite the fact that I have it set to do just that... anyone know why this is?

At this point, you might want to consider using TAILS and storing everything on an encrypted USB drive.

If you're REALLY paranoid and are willing to spend a ***TON*** of time (note, this is a rough sketch of a possible system, you'll have to fill in the details/iron out the kinks):

1. Install a bare-bones arch system with virtualization support (as a hypervisor). DON'T enable any external facing services.
2. Install tor/privoxy, etc... on this bare-bones system and configure this system to communicate over TOR.
3. Install qemu.
4. Create a VM for every "task" you expect to do. Each VM will need two separate virtual hard drives: One read-only (the base drive), one read-write (the state drive). After setting up your VM on the base virtual hard drive, you'll need to copy over any files that will need to change during normal operations (/var/log/, some /var/lib stuff, /etc/, /home, etc...) over to the rstate drive (put them anywhere you want). You'll then need to add some bootstrapping scripts to the read-only drive that correctly bind mount these mutable directories over the correct directories on the read-only drive on boot.
5. For each task, create a couple of shell scripts:
1. One will boot your task VM into administrative mode (making the normally read-only drive read-write). In this mode, you can update etc. Preferably, this mode wouldn't mount the state-storage drive but not doing so could cause some problems (pacman install scripts won't be able to migrate system program state from one format to another).
2. The other will boot your task VM into normal mode. This shell script will need give the VM read-only access to the main virtual disk and read-write access to the state storage one.

If you want to save some space, you might be able to share a single read-only main virtual disk between multiple "task" VMs.

When you actually run these VMs, you should run each under separate users under separate X instances.

Also, you should probably lock the hypervisor's hard drive into a read-only state on boot (after performing any upgrades/maintenance, you can do this with grsecurity). If you do this, you might even be able to use the hypervisor's hard drive as the base drive for the VMs. In this case, you wouldn't even have an administrative VM: instead, to update/install programs, you would restart and boot into a maintenance mode, install/update, and then transition into a runtime mode.

The primary benefits to using a system like this are:
1. The base system does very little and can therefore be more easily secured.
2. Each "task" is run in a separate container.
3. When in maintenance mode, the system is in a known-secure state.
4. When operating normally, user applications (one's running in the task VMs) will have a very hard time modifying the known-secure "base" drive because the only point of failure is qemu (which is much smaller and has much simpler security checks than the linux kernel).

Anyways, if you try to implement a system like this, let me know how it goes. Unfortunately, I don't really have time to help you do so.

Have fun!

ANOKNUSA · 2014-05-20 23:48:39

ParanoidAndroid wrote:

I was thinking more like "hey you're at the border, let's have a look at your computer because we can"-type thing.

In Canada, the US and the UK, refusing to divulge all encryption keys and login passwords to customs officials at the border either gets you detained (if you're on your way out) booted out of the country (if you're on your way in). In either case, there's a chance they'll choose to keep your laptop if they can't get full access at the customs checkpoint. I can't say how other jurisdictions handle it.

ParanoidAndroid · 2014-05-21 01:09:32

@ANOKNUSA
This is exactly why I expressed interest in plausible deniability. If I can render a password that leads to a perfectly normal-looking, innocuous system rather than my main one, they won't bother themselves looking closer. Admittedly, this must raise questions in everyone's mind as to why I would bother with such a deception if, in fact, the data on my computer is legal. Which I assure you it is.

The idea of running everything in separate VMs on a known-secure base makes good sense to me, even though it looks like freakishly complex overkill even to me. The idea of isolating tasks (particularly insecure ones, such as web browsing) from the rest of the system is something I've always wanted to do, but I've never really found a foolproof way of doing it. It seems to me that to ensure any level of security along with perfect usability would require one to design an entirely new operating system.

Communications security, at least in the complete sense, was something I gave up on a long time ago. What I'm more interested in now is data integrity, since I've already more or less reached the limits of what can be achieved anonymity-wise.

clfarron4 · 2014-05-21 10:51:00

ANOKNUSA wrote:

ParanoidAndroid wrote:
I was thinking more like "hey you're at the border, let's have a look at your computer because we can"-type thing.
In Canada, the US and the UK, refusing to divulge all encryption keys and login passwords to customs officials at the border either gets you detained (if you're on your way out) booted out of the country (if you're on your way in). In either case, there's a chance they'll choose to keep your laptop if they can't get full access at the customs checkpoint. I can't say how other jurisdictions handle it.

UK are highly likely to detain you and put you in prison for two years either direction. That said, I've never been stopped at my own border checkpoints.

One the topic of cryptsetup, there is there nuke keys option if you don't mind potentially screwing up your LUKS headers forever. Whilst it does wipe the key header, restoring the header is a tricky business that doesn't always work (that's my disclaimer if you choose to use it).

ParanoidAndroid wrote:

...what about having a hidden OS? That is, ensuring "plausible deniability?" I've heard many debates on the relative merits or lack thereof of this feature, and I've decided that I'd like to have it -- if it's possible to implement it effectively and in a way that actually works.

VMs or Truecrypt Volumes?

ParanoidAndroid wrote:

4. I already use TOR and privoxy, along with iptables to ensure that no traffic goes over the network except through TOR. Are there any other network security/anonymity practices I should implement software-wise? My browsers don't use flash or javascript, nor do they accept cookies (except for a few rare exceptions). Which reminds me, Privoxy doesn't seem to filter JS or flash, or cookies for that matter, despite the fact that I have it set to do just that... anyone know why this is?

Are you sure that all of your traffic goes straight to the destination un-touched once it's left the TOR network? IIRC, I think 10% of the TOR servers were removed from the network because they failed to update their OpenSSL packages after HeartBleed. And let's not forget there may be servers that did update OpenSSL, but didn't get new keys/certificates, hence could be compromised.

ParanoidAndroid wrote:

@ANOKNUSA
This is exactly why I expressed interest in plausible deniability. If I can render a password that leads to a perfectly normal-looking, innocuous system rather than my main one, they won't bother themselves looking closer.

I was discussing this with someone (who deleted the post on G+), who was toying with the idea of implementing this through PAM with a new set of PAM rules.

======

Just remember, like with SELinux, it is possible to configure a system to the point that it is so good at what it does, rendering it unusable in the process.

======

Identity Management?

======

There's nothing like good old pen and paper.

Last edited by clfarron4 (2014-05-21 10:51:47)

jackwild · 2014-05-21 13:27:08

I have heard that hidden volumes are possible using dm-crypt but I have not been able to create it. I did play with it and I'll tell you the basic idea (as I see it).

You need three volumes. Say your drive begins at a and ends at c. The first volume would cover the entire drive. The second volume would go from a to b. The third volume from b to c. All of your hidden stuff would go on the 3rd voulme and your decoy stuff would go on the 2nd volume. The 1st volume would be your plausible deniability.

The idea is that when you mount the outer (plausible deniabliity) volume, only the files from the decoy volume get decrypted but if you write to this outer volume then the files from your hidden volume get overwritten. I think, this is how truecrypt does it. The source code for truecrypt or tcplay will give more clues, I didn't play with the idea for long. Maybe one day.

The problem I had was in creating the embedded filesystems which then invalidate the outer filesystem or the other way around. I think, with enough knowledge/experimentation you can use the proper offsets/filesystems/creation order.

If you have any luck with this, I'd be interested in hearing about it.

moisespedro · 2014-05-21 17:01:44

I know this isn't exactly what you've asked for but have you ever tried OpenBSD? It is such a sweet system.

Trilby · 2014-05-21 17:32:40

This has been a very enlightening thread - even though I don't bother with most of this, it's fun to hear what is possible.

ewaller wrote:

Data are only safe if it costs more to steal than the data are worth.

This is why I don't bother. I'm safe! My data are worthless. If you doubt that, I can quote the editorial staff of a couple major scientific journals confirming as much.

Last edited by Trilby (2014-05-21 17:33:05)

MoonSwan · 2014-05-21 18:59:04

ewaller wrote:

rune0077 hit the nail on the head.
ParanoidAndroid,
<snip very long quote> Okay, so the answer is not that you are trying to protect data, per se. No stored credit card numbers, banking credentials, design secrets, corporate financial data, employee salaries, private keys, etc... You are interested in maintaining anonymity on the Internet. So you are less concerned with intrusions than with having your identity and data obfuscated as they transition a very public network.</snip>

Just as a sort of FYI someone has implemented a lot of this stuff in a distro called Qubes ver. 1.0 Found here

I know about it only because I read an article about it in a special edition of the Linux Format magazine. I don't know that it will "fit" everything you want to do but it may be a better starting point for whatever you want to accomplish.

Hope that helps!

MS

defears · 2014-05-21 20:19:33

Encryption draws attention. Put your sensitive passwords in the middle of the ffmpeg man page like this.
###M_Y__B_A_N_K__A_C_C_O_U_N_T_#_1_2_3_4_5_6_7_8_9
Nobody will ever find it.

If it's a bigger file, split it into 12 pieces with 7z and rename them as mp3's. Bobby Brown's Greatest Hits or something in your music folder.
Nobody will ever play it.

Obviously, you can get creative hiding things in a normal file system. Just make sure that programs like Tracker and Nepomuk can't search for anything obvious. As a bonus make it boot so that if you're not holding a certain key down during boot, every single command will put 'sleep 15' in front. It will make it unbearably slow for them to use it.

Hide in plain sight.

chaonaut · 2014-05-22 07:45:29

ParanoidAndroid wrote:

2. I already use encryption (I've upgraded to serpent-xts-plain64 with the whirlpool hash), but what about having a hidden OS? That is, ensuring "plausible deniability?" I've heard many debates on the relative merits or lack thereof of this feature, and I've decided that I'd like to have it -- if it's possible to implement it effectively and in a way that actually works.

i can understand hidden containers (as TrueCrypt can do), but what's the point of hidden OS (if it's not a stolen copy of windows) ?

ParanoidAndroid wrote:

3. for maintenance and performance reasons (as well as for protection against certain types of attacks) I've split /usr into a separate partition. Yes, I know this isn't standard practice, and that many don't recommend it for one reason or another. That aside, I'd like to know which filesystem would be best for /usr (this is on an SSD, mind) and what mount options should be enabled to ensure security.

if you're using ssd, i'd recommend either btrfs or f2fs due to their ssd-oriented features.
i'm not on ssd, but using btrfs on my system partition because of its snapshotting features. it's easy to revert system to its previous state if something goes wrong e.g. after software update.

well, your partitioning ideas seem to be too complicated. i use lvm over LUKS for my linux installation + truecrypt for my windoze installation, and that appears to be absolutely sufficient. (and for extra paranoia level, i've set up a very special & unnatural key combination for rewriting LUKS volume header with some trash from /dev/urandom, which renders all LUKS partition absolutely useless.)

Last edited by chaonaut (2014-05-22 07:47:38)

Divinorum · 2014-06-24 13:01:48

Threat model and utility would be the two fundamental principles guiding your decisions in designing a secure machine.

I believe you can achieve a meaningful level of security on both the system and the network.

APTs constitute the higher levels of a threat model and are going to require a pre-planned setup and a strict adherence to best practices. Naturally your machine loses utility as you sacrifice basic system options (e.g. Xorg, network connection).

Last edited by Divinorum (2015-05-04 14:59:36)

xero · 2014-06-24 19:40:17

IMHO, dont use TOR, there's too much nefarious stuff going on in that network anymore. i personally use a set of vpn/openvpn servers. it's much faster as well.

clfarron4 · 2014-06-24 20:19:05

xero wrote:

IMHO, dont use TOR, there's too much nefarious stuff going on in that network anymore. i personally use a set of vpn/openvpn servers. it's much faster as well.

I wonder how many people using TOR have actually read up what "Onion Routing" is and how it works. I think they'll be quite surprised.

Divinorum · 2014-06-25 10:35:44

xero wrote:

IMHO, dont use TOR, there's too much nefarious stuff going on in that network anymore. i personally use a set of vpn/openvpn servers. it's much faster as well.

Like I said, it depends on your threat model. A set of vpn servers is a solid solution and provides the meaningful level of security most users are looking for. However, in the face of APTs (which seems to be the concern of the OP) I don't know if it will suffice.

Last edited by Divinorum (2015-05-04 14:58:54)

Arch Linux

#1 2014-05-20 22:26:17

Computer Security - Level: Paranoid

#2 2014-05-20 22:53:37

Re: Computer Security - Level: Paranoid

#3 2014-05-20 22:56:24

Re: Computer Security - Level: Paranoid

#4 2014-05-20 22:59:22

Re: Computer Security - Level: Paranoid

#5 2014-05-20 23:01:11

Re: Computer Security - Level: Paranoid

#6 2014-05-20 23:04:59

Re: Computer Security - Level: Paranoid

#7 2014-05-20 23:10:30

Re: Computer Security - Level: Paranoid

#8 2014-05-20 23:11:03

Re: Computer Security - Level: Paranoid

#9 2014-05-20 23:11:42

Re: Computer Security - Level: Paranoid

#10 2014-05-20 23:36:35

Re: Computer Security - Level: Paranoid

#11 2014-05-20 23:39:31

Re: Computer Security - Level: Paranoid

#12 2014-05-20 23:48:39

Re: Computer Security - Level: Paranoid

#13 2014-05-21 01:09:32

Re: Computer Security - Level: Paranoid

#14 2014-05-21 10:51:00

Re: Computer Security - Level: Paranoid

#15 2014-05-21 13:27:08

Re: Computer Security - Level: Paranoid

#16 2014-05-21 17:01:44

Re: Computer Security - Level: Paranoid

#17 2014-05-21 17:32:40

Re: Computer Security - Level: Paranoid

#18 2014-05-21 18:59:04

Re: Computer Security - Level: Paranoid

#19 2014-05-21 20:19:33

Re: Computer Security - Level: Paranoid

#20 2014-05-22 07:45:29

Re: Computer Security - Level: Paranoid

#21 2014-06-24 13:01:48

Re: Computer Security - Level: Paranoid

#22 2014-06-24 19:40:17

Re: Computer Security - Level: Paranoid

#23 2014-06-24 20:19:05

Re: Computer Security - Level: Paranoid

#24 2014-06-25 10:35:44

Re: Computer Security - Level: Paranoid

Board footer