Bullet Proof Arch System

ClaudioP · 2013-12-26 07:04:09

Hi Arch community.
I have a VPS running Arch (its only for personal use, portfolio hosting, some storage) which i first set up exactly a month ago.
Just like someone said on the IRC (sorry random helper, i don't remember your name, no credits today ) arch is perfectly good to go for a 24/7 system if properly set, and after some research (like discovering that xyne's almost been in jail and Allan breaks stuff on a daily basis) i concluded Arch is a good choice for the job. (Since i can handle very occasional bugs, and have time to maintain once a week)

This whole month my Arch setup ran mainly OpenSSH, Apache, VSFTP, OpenVPN and (unsuccessfully) Postfix with near to no additional configuration, and it was completely trouble-free.
I had even asked for help to a script kiddie to verify if he could "blow that guy's server" and he told it was impossible (lol'd hard knowing i didn't even had a firewall installed)

And so i decided to go to the long run with it, so I'll start by building the system from the bottom with security on mind. But i think its better to ask to the more experienced than to search the web for "randobuntu" guides, and so i want to ask to the community:
- How would you setup Arch for a computer that you physically don't possess (and don't know who does or what they do with it) that you could be comfortable to put your "super-secret-and-personal-files" on it?
- I also would like to make a list of good security practices on a server setup (I mean, others than: "Don't use root")

Right now i got these(With the help of https://wiki.archlinux.org/index.php/security):

I'm thinking in 3/4 partitions:
- /boot formatted with EXT2 [It's impossible to crypt the bootloader, am i wrong?; Should/Can i merge it to the '/'?]
- / probably formatted with EXT4 [Should i crypt the whole thing? Will it generate too much overhead? It's EXT4 the best for the whole setup?]
- /var with encrypted EXT2 [Any better choice?]
- /home being handled by Truecrypt with EXT4 format [Should i use it? Is AES-TWOFISH+Whirlpool a good pick? Truecrypt should be stronger than the kernel encryption, am i wrong?]
- /boot, /var, /tmp and /home with nodev, nosuid and noexec. [i didn't quite understood what nosuid does]
All of the encrypted partitions with the exception of home using Ecryptfs [Good choice? Should i stack with some other algorithm? Where should the mount parameters (password or keyfile mainly) be to be safe?]
[How can / be encrypted without the password being in clear text on /boot?]

Which bootloader should be used to ensure safety, and how will it be ensured on a remote system?
On the wiki there is:

ArchWiki wrote:

It is highly important to protect your bootloader. There is a magic kernel parameter called init=/bin/sh. This makes any user/login restrictions totally useless.

What does this?

The used kernel should be the linux-lts or linux-selinux (https://aur.archlinux.org/packages/linux-selinux/)?
I think that SELinux is a bonus, but the AUR package is... an AUR package (i would like to avoid them when possible) and it is not even an LTS kernel.

For the firewall I'm thinking in using UFW since it's much simpler than configuring directly iptables and does the same job.
Everything blocked except the ports 20,21,25,80,143,443,465,587,993,{unknown SSH and VPS ports}/tcp and 53/udp for incoming. What about outgoing?
Also

chmod 700 /boot /etc/{iptables,arptables}

Every possible network service having its own fingerprint as removed as possible [Eg. Just "Apache" instead of "Apache x.x.x mod_something Unknown GNU/Linux x86_64... etc"]

SSH with root login disabled, and rejecting connections from anywhere else than server's own ip.(A VPN should be used to use SSH)
Also set a login timeout with bash "TMOUT" and disable login to accounts after 3 failed login attempts.
Use sudo to administer, only allowing one or certain users to execute the programs that may harm the system, if possible users with uncommon names instead of "admin".
Login with certificates instead of a password.

VSFTP and Postfix with virtual users and system users disabled. [Good idea?]

I think OpenVPN is always safe since it enforces CA's to auth. Right?

What MAC should be used? SELinux? [I understand almost nothing about them]

After all there measures, would you guys trust this system for your files?
What can the ISP/Goverment do that ignores all of those measures? Directly reading RAM looking for filesystem passoword? Replace the kernel with one containing a rootkit?
Any other ways to break this?

PS: Xyne's and Allan's thing was an obvious joke

Last edited by ClaudioP (2013-12-26 07:23:02)

jasonwryan · 2013-12-26 07:12:16

I would wait until the truecrypt audit is complete before using it (again) myself. LUKS and LVM makes more sense anyway.

Moving to Networking, Server & Protection.

ClaudioP · 2013-12-26 07:30:40

jasonwryan wrote:

I would wait until the truecrypt audit is complete before using it (again) myself. LUKS and LVM makes more sense anyway.

You got a valid point.
And if you don't mind (just as i asked), the system to boot from an encrypted partition needs to know it's own password. How can i do so without leaving it on clean text under /boot?
I got to search a bit for LVM (later, im getting too sleepy now) before doing any pointless question...

ClaudioP · 2013-12-27 03:48:01

Got fresh questions
After all i still didn't understood what is LVM for when attempting to increase security...
Isn't LVM just some sort of "virtual-partition-system/manager"?
Then what's the advantage of system with it over one without when using static size partitions?

I still didn't understood (even after reading this) how is the system safer if the key is stored somewhere on the bootloader/kernel (otherwise they would not be able to decrypt).

Assuming you got 50GB, how would you partition a standard server (no specific task)?
/boot [120 MB on /sdx1]
/ [8 GB on LVM-LUKS]
/var [2 GB on LVM-LUKS]
/home [ ~40GB on LVM-LUKS]
Is it ok?

jasonwryan · 2013-12-27 03:55:28

The LVM part is for flexibility; it ensures that you can change partition sizes around without any real risk of breaking stuff.

You can decrypt an encrypted /root remotely using dropbear.

WonderWoofy · 2013-12-27 03:57:11

Using LVM alone will do nothing for security. But in this case, it is being recommended as just a way to make dm-crypt easier to manage. Using LVM on a Luks/dmcrypt partition just makes it so that you can use one large Luks/dmcrypt partition and therefore just one container to decrypt when you boot.

/dev/zero · 2013-12-27 04:13:02

ClaudioP wrote:

Got fresh questions
After all i still didn't understood what is LVM for when attempting to increase security...
Isn't LVM just some sort of "virtual-partition-system/manager"?

Right. LVM is not for security. It is for convenience. You can keep your different partitions all encrypted under the one LUKS device, so they all get unlocked simultaneously when you enter your passphrase.

ClaudioP wrote:

I still didn't understood (even after reading this) how is the system safer if the key is stored somewhere on the bootloader/kernel (otherwise they would not be able to decrypt).

If I understand correctly, what is stored on disk is a hash of your passphrase. To crack your system, someone would need to find a passphrase with the same hash.

For example, suppose (for example!) that LUKS uses 256 bit sha sums and suppose also that your passphrase is correct horse battery staple, which has a sha256sum of 73fe04e5a7a16dbe16492a8773036db1646d87e22337b1c64aae0afab788b626. Then 73fe04e5a7a16dbe16492a8773036db1646d87e22337b1c64aae0afab788b626 would be stored on disk and an attacker would have to guess a passphrase with the same sum.

Note that knowing the required sum doesn't help the attacker. If they try entering that sum as a passphrase, LUKS would take the hash of the hash; the result is something different to the original hash (well, with probability nearly equal to 1, anyway).

Hopefully you can see now that what is exposed to the attacker will not help them crack your encrypted drive (unless they know of some exotic exploit).

ClaudioP wrote:

Assuming you got 50GB, how would you partition a standard server (no specific task)?
/boot [120 MB on /sdx1]
/ [8 GB on LVM-LUKS]
/var [2 GB on LVM-LUKS]
/home [ ~40GB on LVM-LUKS]
Is it ok?

Seems okay to me. I personally don't worry about using a separate partition for /var. I would probably put 10GB on the root directory and everything left over can go to /home. I might also put more room in /boot, just in case you feel like mucking around with multiple kernels or initramfses in the future. Then again, I'm used to dealing with systems that have heaps of spare hard-drive space so I'm not really concerned if /boot takes up one or two GB by itself.

ClaudioP · 2013-12-27 07:44:33

Thanks you guys, understood the LVM part.

Again on the encryption problem: What if just want the system to be able to boot by itself?
I mean, i don't want to connect from SSH to the system every time it needs to boot(either because of software, hardware, power) except for intentional maintenance.
Thats why i asked how could the system don't have the key on clear text and yet be able to boot.

Is there anything i can do, or at least any service that warns me when the server goes down so i can know when to connect to it to be able to boot?

Using these encryption techniques also prevent hosting/goverment folks to look for it's key on RAM?

jasonwryan · 2013-12-27 07:48:57

ClaudioP wrote:

Using these encryption techniques also prevent hosting/goverment folks to look for it's key on RAM?

If you want this level of security, then forget about a VPS. Buy your own box and lock it in your basement with an alligator on steroids.

progandy · 2013-12-27 13:02:15

ClaudioP wrote:

Using these encryption techniques also prevent hosting/goverment folks to look for it's key on RAM?

As soon as someone has access to the physical machine you are screwed. As long as they can boot the machine, they are able to get anything they wish.

ClaudioP · 2013-12-27 21:04:49

jasonwryan wrote:

If you want this level of security, then forget about a VPS. Buy your own box and lock it in your basement with an alligator on steroids.

Then every single kind of hosting service, ranging from a "Cloud Website" up to a dedicated server, can be easily compromised as far as they're not hosted in front of you?
Note that i am not any kind of professional related to any security-critical business. I am just some random 17 years "kid" with too much paranoia.
I just wanted to know if it was possible to trust this machine as much as i do in my own PC.

progandy wrote:

As soon as someone has access to the physical machine you are screwed. As long as they can boot the machine, they are able to get anything they wish.

Then whats the point of encrypting the whole root of the system, or even a partition at all?
If i should forget about safety on the physical-side, then the only threat are the remote exploits, and they focus on gaining access to a user on the system.
As all of the users have access to the decryption keys, then the encryption makes no sense at all... please correct me if i am wrong (as i probably am)

Leonid.I · 2013-12-27 21:26:58

ClaudioP wrote:

- How would you setup Arch for a computer that you physically don't possess (and don't know who does or what they do with it) that you could be comfortable to put your "super-secret-and-personal-files" on it?

There is no way.

If you have valuable data, store it in a controlled location or use a public service like miscrosoft skydrive, but encrypt the data first.

ClaudioP wrote:

- /boot formatted with EXT2 [It's impossible to crypt the bootloader, am i wrong?; Should/Can i merge it to the '/'?]

You must have a kernel and bootloader unencrypted. Otherwise there is a chicken-and-the-egg paradox. Who will decrypt the kernel?

Typical encryption schemes when /boot is stored on the same HDD as the encrypted root are flawed. Indeed, if the kernel and initramfs are not encrypted, I can replace them and leak your encryption key. Therefore, for the system encryption to be effective (i.e. not only protect your data if the system is stolen, but also protect the system from unauthorised physical access), you must separate kernel and bootloader from the system, and store them in a safe place.

ClaudioP wrote:

All of the encrypted partitions with the exception of home using Ecryptfs [Good choice? Should i stack with some other algorithm? Where should the mount parameters (password or keyfile mainly) be to be safe?]

No. If the underlying partition is encrypted, what's the point of ecryptfs?

ClaudioP wrote:

Which bootloader should be used to ensure safety, and how will it be ensured on a remote system?
On the wiki there is:
ArchWiki wrote:
It is highly important to protect your bootloader. There is a magic kernel parameter called init=/bin/sh. This makes any user/login restrictions totally useless.
What does this?

This is crap.

Protecting the bootloader with a password (where do you think the password/hash is stored?) only works when you have a physical control of the machine. Besides, a properly encrypted installation, doesn't even have a bootloader.

ClaudioP wrote:

The used kernel should be the linux-lts or linux-selinux (https://aur.archlinux.org/packages/linux-selinux/)?
I think that SELinux is a bonus, but the AUR package is... an AUR package (i would like to avoid them when possible) and it is not even an LTS kernel.

Do you understand how the SELinux works? If not, stay away from it.

ClaudioP wrote:

For the firewall I'm thinking in using UFW since it's much simpler than configuring directly iptables and does the same job.
Everything blocked except the ports 20,21,25,80,143,443,465,587,993,{unknown SSH and VPS ports}/tcp and 53/udp for incoming. What about outgoing?

Security is not meant to be easy. If you can't learn iptables, don't try to secure the system.

Nmap can do a deep portscan of all 2^16 ports in less than 3min, so messing with default ports will only give you a headache when administering the system.

ClaudioP wrote:

Also
chmod 700 /boot /etc/{iptables,arptables}

Before making everything 600 root:root, ask yourself what would an attacker learn from your iptables.rules and ssd_config? That you block certain ports and have ssh login grace time 30sec? A good security doesn't rely on secrecy of the configuration.

ClaudioP wrote:

Every possible network service having its own fingerprint as removed as possible [Eg. Just "Apache" instead of "Apache x.x.x mod_something Unknown GNU/Linux x86_64... etc"]

Why bother? Any attacker with more than 2 neurons will try to exploit all known vulnerabilities in the last 10 versions of Apache. If you know that your service is vulnerable, patch it, don't try to hide.

ClaudioP wrote:

SSH with root login disabled, and rejecting connections from anywhere else than server's own ip.(A VPN should be used to use SSH)
Also set a login timeout with bash "TMOUT" and disable login to accounts after 3 failed login attempts.

Right, no root over SSH -- this is common wisdom. May I ask why is SSH root login bad? Because some blogger said so? Create a 4096 bit ssh key with a passphrase and use it exclusively for system administration.

Also, why 3 attemtps and not 1? Are you trying to hide an unfolding attack from yourself? If I am running am internet-facing server, I want to be able to profile an attack. For example, if you see login attempts with login/passwd pairs root/root or ubuntu/ubuntu -- this is a kid -- pay attention but not too much. If the passwords are more complicated, you might have a problem...

ClaudioP wrote:

Use sudo to administer, only allowing one or certain users to execute the programs that may harm the system, if possible users with uncommon names instead of "admin".

Just because using sudo for priviledge escalation is a folk knowledge doesn't make it right. But if you are going to use it, read this first:
http://www.openwall.com/lists/owl-users/2004/10/20/6 .

ClaudioP wrote:

Login with certificates instead of a password.

This is the only meaningful sentence so far.

ClaudioP wrote:

After all there measures, would you guys trust this system for your files?

No.

ClaudioP wrote:

What can the ISP/Goverment do that ignores all of those measures? Directly reading RAM looking for filesystem passoword? Replace the kernel with one containing a rootkit?
Any other ways to break this?

There are 10^23 ways to break any security (we haven't even talked about hardware exploits). But these are all wrong questions.

The question which you should ask is whether the hassle of breaking your security is worth stealing your SSN and $20K in your bank account.

Last edited by Leonid.I (2013-12-27 21:37:25)

/dev/zero · 2013-12-27 21:42:48

progandy wrote:

As soon as someone has access to the physical machine you are screwed. As long as they can boot the machine, they are able to get anything they wish.

This isn't quite true, although it's a good rule of thumb that if someone has physical access then all bets are off.

ClaudioP wrote:

Then every single kind of hosting service, ranging from a "Cloud Website" up to a dedicated server, can be easily compromised as far as they're not hosted in front of you?

Correct. If everything on the machine is encrypted, then how will you be able to read any of it? At some point you need to have unencrypted information on the machine. Anyone with physical access to the running machine can, for example, cryogenically freeze the ram to get at your passphrase. If the machine in question is a remote server owned by someone else, it's that much easier.

Also don't forget the $5 wrench rule.

No security system is perfect. You need to consider the costs of your time, effort and money and weigh them against the risks of various kinds of attacks.

ewaller · 2013-12-27 21:44:39

Leonid.I wrote:

ClaudioP wrote:
- How would you setup Arch for a computer that you physically don't possess (and don't know who does or what they do with it) that you could be comfortable to put your "super-secret-and-personal-files" on it?
There is no way.

Well, one can slow them down a bit: http://en.wikipedia.org/wiki/Hardware_security_module

ClaudioP · 2013-12-28 05:38:34

Leonid.I wrote:

Typical encryption schemes when /boot is stored on the same HDD as the encrypted root are flawed. Indeed, if the kernel and initramfs are not encrypted, I can replace them and leak your encryption key. Therefore, for the system encryption to be effective (i.e. not only protect your data if the system is stolen, but also protect the system from unauthorised physical access), you must separate kernel and bootloader from the system, and store them in a safe place.

Then encryption just becomes useless after all, unless the files are encrypted on a different computer.
How could /boot be on a different computer? Can I boot with the /boot partition on a network? Like if it was PXE/NFS?

Leonid.I wrote:

ClaudioP wrote:
All of the encrypted partitions with the exception of home using Ecryptfs [Good choice? Should i stack with some other algorithm? Where should the mount parameters (password or keyfile mainly) be to be safe?]
No. If the underlying partition is encrypted, what's the point of ecryptfs?

I saw somewhere on the wiki that there are setups with two layers of encryption. I don't know its effectiveness.

Leonid.I wrote:

[...] a properly encrypted installation, doesn't even have a bootloader.

Forgive the noob question, but how can a system be booted without bootloader? Can MBR be linked directly to the kernel? Whats the difference?

Leonid.I wrote:

If you can't learn iptables, don't try to secure the system.

I've read somewhere that in the close future iptables will be replaced(don't know when nor whats the replacement). I don't want to spend loads of time on something temporary.
And whats the difference between using iptables and UFW and Iptables? Doesn't UFW uses iptables? Sorry if im the kind on newbie who just knows the basics (65k ports, in and out)

Leonid.I wrote:

Nmap can do a deep portscan of all 2^16 ports in less than 3min, so messing with default ports will only give you a headache when administering the system.

My bad. I was thinking of doing it in the services only accessible by the VPN, but then there would be no point on doing it

Leonid.I wrote:

Before making everything 600 root:root, ask yourself what would an attacker learn from your iptables.rules and ssd_config? That you block certain ports and have ssh login grace time 30sec? A good security doesn't rely on secrecy of the configuration.

I was basing myself on what i found on the wiki. What you said makes sense.
By the way, whats best to do with rejected connections? Deny them or reject them?

Leonid.I wrote:

Any attacker with more than 2 neurons will try to exploit all known vulnerabilities in the last 10 versions of Apache. If you know that your service is vulnerable, patch it, don't try to hide.

But there aren't many more in use counting with backports and between every distro? (Not to mention that Arch is a very uncommon distro for a server)

Leonid.I wrote:

ClaudioP wrote:
SSH with root login disabled, and rejecting connections from anywhere else than server's own ip.(A VPN should be used to use SSH)
Also set a login timeout with bash "TMOUT" and disable login to accounts after 3 failed login attempts.
Right, no root over SSH -- this is common wisdom. May I ask why is SSH root login bad? Because some blogger said so? Create a 4096 bit ssh key with a passphrase and use it exclusively for system administration.
Also, why 3 attemtps and not 1? Are you trying to hide an unfolding attack from yourself? If I am running am internet-facing server, I want to be able to profile an attack. For example, if you see login attempts with login/passwd pairs root/root or ubuntu/ubuntu -- this is a kid -- pay attention but not too much. If the passwords are more complicated, you might have a problem...

But then if for some reason the key is intercepted there would be a free access to the privileged account, not for some unprivileged account that would have to use su to become root.
Oh i see, the 3 attempts were meant for a multi-user system with common passwords, not for someone using cryptographic keys.
Why would the complicated password mean something bad? Couldn't be an idiot try of brute-force?(IDK, some dumb program that doesn't starts with 0 or A)
What else could the "complicated passwords" mean? Give an example please.

Leonid.I wrote:

Just because using sudo for priviledge escalation is a folk knowledge doesn't make it right. But if you are going to use it, read this first:
http://www.openwall.com/lists/owl-users/2004/10/20/6 .

I partially understood it. Not fully since English is not my mother language, but mostly.

Leonid.I wrote:

ClaudioP wrote:
After all there measures, would you guys trust this system for your files?
No.

Moral after all: Never(some emphasis on NEVER) trust a remote system to encrypt your files in safety

Leonid.I wrote:

ClaudioP wrote:
Any [...] ways to break this?
[...]The question which you should ask is whether the hassle of breaking your security is worth stealing your SSN and $20K in your bank account.

Then nobody receiving less than 1k$ a month or doing anti-government propaganda would be affected by the NSA and the other well known parties.
I'm not too much into the topic, but AFAIK(which is not certain to be right) there are much more people affected.

/dev/zero wrote:

No security system is perfect. You need to consider the costs of your time, effort and money and weigh them against the risks of various kinds of attacks.

Right now (since it's impossible to prevent against against physical attacks) I'll forget about local encryption, it just becomes useless. I'll just encrypt personal files before upload.

By the way, is there any encryption utility that works file by file and not with a container? I don't want to upload the entire container every time i change something.

ewaller wrote:

Well, one can slow them down a bit: http://en.wikipedia.org/wiki/Hardware_security_module

Sorry but the hardware is not mine and i am not rich
If i was i would not be concerning about security

/dev/zero · 2013-12-28 06:01:19

ClaudioP wrote:

Forgive the noob question, but how can a system be booted without bootloader? Can MBR be linked directly to the kernel? Whats the difference?

Several of the other questions you ask Leonid.I come back to this question.

I believe Leonid.I is talking about putting your /boot on a usb stick or the like. You encrypt the hard-drive (maybe as plain dm-crypt rather than LUKS for added obscurity ...) and boot from a usb. The usb will have a kernel and an initramfs with the "encrypt" hook built into it.

ClaudioP wrote:

By the way, is there any encryption utility that works file by file and not with a container? I don't want to upload the entire container every time i change something.

GPG

progandy · 2013-12-28 14:47:52

/dev/zero wrote:

ClaudioP wrote:
By the way, is there any encryption utility that works file by file and not with a container? I don't want to upload the entire container every time i change something.
GPG

There is EncFS which transparently encrypts files and filenames before writing them on your original filesystem.

ANOKNUSA · 2013-12-28 14:53:37

ClaudioP wrote:

Then every single kind of hosting service, ranging from a "Cloud Website" up to a dedicated server, can be easily compromised as far as they're not hosted in front of you?

Congratulations---you just learned the very first lesson everyone needs to know about security: If you can't directly control it, you can't fully secure it. Period. The only thing you can hope for is that the thing needing securing is in the hands of people in whom you can completely place your trust.

As for the point of encryption, encrypting a drive completely will result in extremely good security of your data; it does not guarantee that someone with access to the hosting service's records won't roll over and give away your personal information. If agents of the state can obtain both the machine and your whereabouts, they may compel you to surrender the passphrase to the encrypted drive. But this is, I presume, all hypothetical...

Leonid.I · 2013-12-28 16:17:19

ClaudioP wrote:

How could /boot be on a different computer? Can I boot with the /boot partition on a network? Like if it was PXE/NFS?

In principle, you should be able to boot an encrypted system over the internet, but I need to think about it because there may be subtle issues...

ClaudioP wrote:

I've read somewhere that in the close future iptables will be replaced(don't know when nor whats the replacement). I don't want to spend loads of time on something temporary. And whats the difference between using iptables and UFW and Iptables? Doesn't UFW uses iptables?

Well technically there is no iptables, only xtables... But we are not talking about backend modules here.

The problem with "easy" frontends like UFW is that once you start using them, you are stuck at a newbie level. And if you want to know what's going on behind the scenes, you'll find it very difficult to get through the UFW software layer. That's why majority of sys-admins only speak iptables -- it is just simpler. And these sys-admins are exactly the people you'll be learning from.

ClaudioP wrote:

But there aren't many more in use counting with backports and between every distro? (Not to mention that Arch is a very uncommon distro for a server)

There are 3 main linux distros which extensively backport changes: debian, rhel and suse. Each of them has 3 supported versions. So...

ClaudioP wrote:

But then if for some reason the key is intercepted there would be a free access to the privileged account, not for some unprivileged account that would have to use su to become root. Oh i see, the 3 attempts were meant for a multi-user system with common passwords, not for someone using cryptographic keys. Why would the complicated password mean something bad? Couldn't be an idiot try of
brute-force?(IDK, some dumb program that doesn't starts with 0 or A) What else could the "complicated passwords" mean? Give an example please.

Your key is supposed to have a password too.

If comeone is trying generic passwords it is one thing; if you see that some attempts resemble your old, simple passwords, you have a targeted attack.

ClaudioP wrote:

Then nobody receiving less than 1k$ a month or doing anti-government propaganda would be affected by the NSA and the other well known parties. I'm not too much into the topic, but AFAIK(which is not certain to be right) there are much more people affected.

The whole NSA scandal is a FUD. People who are "affected" are either criminals, idiots who like to whine about privacy but don't know a bit about it, or politicians trying to get re-elected.

ewaller · 2013-12-28 16:53:22

And with that, this thread has run its course. I am going to close this thread, but I am going to break protocol my making a closing statement and then denying people the right to respond to it.

Anyone who subscribes to the notion that state surveillance of its citizens is only to be feared by those with something to hide need to go acquire an education by reading some history lest we fall into the same traps that have befallen civilization for centuries.

Arch Linux

#1 2013-12-26 07:04:09

Bullet Proof Arch System

#2 2013-12-26 07:12:16

Re: Bullet Proof Arch System

#3 2013-12-26 07:30:40

Re: Bullet Proof Arch System

#4 2013-12-27 03:48:01

Re: Bullet Proof Arch System

#5 2013-12-27 03:55:28

Re: Bullet Proof Arch System

#6 2013-12-27 03:57:11

Re: Bullet Proof Arch System

#7 2013-12-27 04:13:02

Re: Bullet Proof Arch System

#8 2013-12-27 07:44:33

Re: Bullet Proof Arch System

#9 2013-12-27 07:48:57

Re: Bullet Proof Arch System

#10 2013-12-27 13:02:15

Re: Bullet Proof Arch System

#11 2013-12-27 21:04:49

Re: Bullet Proof Arch System

#12 2013-12-27 21:26:58

Re: Bullet Proof Arch System

#13 2013-12-27 21:42:48

Re: Bullet Proof Arch System

#14 2013-12-27 21:44:39

Re: Bullet Proof Arch System

#15 2013-12-28 05:38:34

Re: Bullet Proof Arch System

#16 2013-12-28 06:01:19

Re: Bullet Proof Arch System

#17 2013-12-28 14:47:52

Re: Bullet Proof Arch System

#18 2013-12-28 14:53:37

Re: Bullet Proof Arch System

#19 2013-12-28 16:17:19

Re: Bullet Proof Arch System

#20 2013-12-28 16:53:22

Re: Bullet Proof Arch System

Board footer