# hardened notebook - pros?cons?caveats?

## Veldrin

Hi there,

I am currently in one of my more paranoid phases, and as such I am wondering if it worth to install hardened desktop. pros? cons? caveats?

what experiences are around?

Is it worth the effort, or should I start securing from another end?

I am mainly intrigued by the additional security. But am not entirely sure if it fitting for a desktop.

I am currently running a test installation on my desktop, hardened profile with hardened kernel. PaX and grsec enabled, but no rbac.

I am pretty surprised how much works out of the box, at least form the open source part. the more closed source it gets, the more trouble arises (skype, adobe-flash, virtualbox, ati-/nvidia-drivers)

And it seems, that hardened uses less ram, than a 'normal' installation. but this could also be just coincidence.

The main goal to have a decision (whether to go with a hardened install, or a vanilla one) for my upcoming notebook replacement, in the next couple of weeks/months.

V.

edit: changed title to better reflect the topic

----------

## Hu

I suggest always using the hardened user bits.  Recent sys-devel/gcc releases make hardened much more accessible than it once was.  Using a hardened kernel is a more difficult question, since that requires you to stay behind mainline while waiting for updated PaX/GRSec patches.  Additionally, since the hardened kernel patches necessarily affect the running kernel in significant ways, a bug in the kernel hardening could panic the system, whereas bugs in user hardening are generally both more isolated and more readily reported/fixed.

You mention this decision will affect a notebook.  Are you looking at hardening purely because of the convenience of installing it on a new system or are you also looking because notebooks are more susceptible to certain classes of attack (physical theft, direct exposure to hostile networks as you travel)?  If you are concerned about physical theft, there are steps that you can take to mitigate the unauthorized disclosure of information.  Those steps are best taken during initial install.

----------

## Veldrin

So there IS a french way...   :Smile: 

I was half way hoping, that there is some kind of hybrid solution to a pure hardened desktop. 

How much do I loose, if go with a vanilla/gentoo kernel compared to a hardened one?

And it is good to know, that recent gcc versions make hardening a little easier. My test install is currently using gcc-4.6 on ~amd64  :Rolling Eyes: 

It is mainly just to have it installed, and to make it less susceptible to hacking attempts. Maybe also to keep some experimental software at bay if it misbehaves (stack overflow like)

Besides the OS hardening, BIOS/HDD passwords are planned, ecryptfs encrypted home (FDE/LUKS uses to many cpu cycles) and maybe swap ecryption.

The latter I have to investigate a little further, as I still want to be able to hibernate. 

Apart from that, I am open for further suggestions.

But I am also aware, that perfectly secure system (if it exists) is barely usable. So I like to find a reasonable balance between usability and some gained hardening/securing.

And as the system will only be used by myself, I see little point in installing rbac or selinux.

V.

----------

## Hu

If you use a non-hardened kernel with hardened user programs, then an attacker will face a greater challenge than breaking a pure non-hardened system, but it may not be as difficult as if the kernel were hardened.  Hardened programs work correctly on a vanilla kernel, but the hardened kernel adds some extra protection.  For example, a hardened kernel can enforce memory protection restrictions that make NX much more effective against an active attacker.

If you plan to keep any sensitive data on the machine, I strongly advise using encrypted swap.  Since Linux can swap pages at its discretion, a page containing sensitive information could be swapped out and persist on disk indefinitely.  You can still hibernate and resume with encrypted swap, but you need an initramfs that activates the encrypted volume.  Also, you will need to use a persistent key (usually derived from a passphrase or a GPG-encrypted file) for swap.  If you were not using hibernation, you could encrypt the swap with a random key that is discarded on shutdown.

----------

## Veldrin

 *Quote:*   

> If you use a non-hardened kernel with hardened user programs, then an attacker will face a greater challenge than breaking a pure non-hardened system, but it may not be as difficult as if the kernel were hardened. Hardened programs work correctly on a vanilla kernel, but the hardened kernel adds some extra protection. For example, a hardened kernel can enforce memory protection restrictions that make NX much more effective against an active attacker. 

  Thanks for the clarification. So it just gets less effective.

I think, I'll install vanilla/gentoo kernel on my test setup, and see how it goes. 

And you just convinced me, that I need an encrypted swap. The only decision to be made, is do i need hibernation (or do I get it working), and then chose the appropriate method. though I can use the persistent method either way.

Is there a howto for using the gpg encrypted file as key?

V.

----------

## rh1

http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS

There's a section on swap and gpg keys

----------

## Hu

The nice thing about hardened kernels is that you can switch between a hardened kernel and a non-hardened kernel with just a reboot.  Thus, you could add a hardened kernel later, and abandon it easily if you find it causes problems that you cannot take the time to solve.

I am very fond of hibernation on any system where it works reliably.  Fortunately, the nature of swap makes it very easy to destroy and remake, so even if you set it up incorrectly the first time, you can swapoff -a, tear down the encryption mapping, and try again.  Once you have encrypted swap working the way you want it, then you need an initramfs to prepare the encryption mapping and call resume.  There are various guides on doing this, and we can help you troubleshoot it if you have problems.

----------

## m0p

As has been mentioned, you still get some benefits with software and libraries compiled from source with the hardened toolchain alone (ProPolice, FORTIFY_SOURCE=2, LD_BIND_NOW, etc), but a hardened kernel will just drive you up the wall.

PaX and RBAC are indeed nice, but the former won't work on any of the closed-source applications without PIE (which make up a few of the common attack vectors on desktops, Opera, adobe-flash, etc), and the latter can make the machine nearly unusable as a desktop user if you configure it tight enough to really benefit from it.

You might as well go for whole-disk encryption. You say that LUKS uses too many CPU cycles, but I don't imagine it would have a catastrophic effect on battery life. I'd dedicate the entire disk (if you want the bootloader on a USB key so that nobody can plant an infected kernel on there) or a big partition to a LUKS volume, throw an LVM group on top of that and use LVs instead of standard partitions. I'd at least give it a try anyway to see how it affects your battery life, it might not be as bad as you think. LUKS + LVM is definitely the tidiest way to go about whole-disk encryption anyway.

You can easily resume with an encrypted swap with an appropriate initrd if you follow the LUKS/LVM plan I mentioned above instead of using the OpenRC script that creates a new volume for it with a random key at every boot. Dracut can definitely do it, as far as the initrd goes.

----------

## Veldrin

 *Quote:*   

> PaX and RBAC are indeed nice, but the former won't work on any of the closed-source applications without PIE (which make up a few of the common attack vectors on desktops, Opera, adobe-flash, etc), and the latter can make the machine nearly unusable as a desktop user if you configure it tight enough to really benefit from it. 

 This confirms my current tests. a vanilla/gentoo kernel solves some of the problems (virtualbox, skype, possibly binary drivers, but not adobe-flash, but this seems to be my hardware), and running a rbac kernel - properly configured - takes either a lot of time, or makes the system just unuable. Kind of reminds me of my selinux experiment. 

And does it even make sense to install rbac or selinux on basically single user system?

I had luks installed on my notebook (pentium-m, single core) some years ago, and back then the crypto overhead ate about 20% cputime. But processors have improved, a from the benchmarks i read about aes-ni on the new intel processors, it might be not that bad. 

I cannot explain why, but I do not like lvm. partitioning a system is a onetime job, and done right there is rarely a need to move the partitions around or resize them. It just adds another layer of complexity that seems to have no use for me.

the currently planned setup consists of 3 partition setup: system, data, swap. system and data will run on btrfs, swap will be encrypted (the howto I take from one of the wiki articles).

btrfs allows me to split the system into as many partitions as need, and set on each appropriate permissions (nodev, nosuid, noexec, compress et all), and I get the  advantage of snapshots. the data partitions will be split into home, media and scratch (just some space to mess around with)

On the other hand, yes I am paranoid, but I like to keep things simple. Primary goal it to protect my data (thus an encrypted home and swap) but no additional boot device - just something more to lose or get broken. I currently like the way my work machine is setup, which is actually what I like to rebuild.

Or maybe just make it more annoying to get to my data. 

 *Quote:*   

> I am very fond of hibernation on any system where it works reliably. Fortunately, the nature of swap makes it very easy to destroy and remake, so even if you set it up incorrectly the first time, you can swapoff -a, tear down the encryption mapping, and try again. Once you have encrypted swap working the way you want it, then you need an initramfs to prepare the encryption mapping and call resume. There are various guides on doing this, and we can help you troubleshoot it if you have problems.

 I probably setup another VM to mess around with encrypted swaps. I keep you posted on how it goes - this is going to take a few days. 

V.

To get you an idea of the notebook I am aiming for: Lenovo X220, Core i7, 8GB RAM, Intel SSD.

now it just need to become available (again) in Switzerland....

----------

## Veldrin

Ok - I tried the encrypted swap with gpg ecrypted passphrase. works like a charm. 

Now I only have to decide, if go for a full luks installation, or just keep my initial plan, only go with a ecryptfs encrypted home.

@all: thanks for the help. 

I rarely use the forum to ask questions, I more answer them. And I am still amazed how fast one gets a solid answer.

V.

----------

## Veldrin

I ran some more tests i.e. testing luks based FDE with gpg-encrypted keys.

Everything works fine, and there is no need for a customized initramfs - genkernel handles it all, if you add the appropriate flags and set the kernel line correctly.

run the following genkernel command genkernel --luks --gpg all to build and luks and gpg enabled initramfs + kernel

Use the following settings to enable grub2 to use an encrypted root, keyfiles for root (/dev/sda7) and swap (/dev/sda6) are are stored in /boot (/dev/sda5).

The only downside, the mapped root is called root, and mapped swap swap - no space for customized names (yet).

```
menuentry "3.0.0_rc5-3 - Sneaky Weasel (LUKS)" --class gentoo --class gnu-linux --class os {

        load_video

        insmod gzio

        insmod part_msdos

        insmod ext2

        set root='(/dev/sda,msdos5)'

        search --no-floppy --fs-uuid --set=root 8e82ac0e-4c71-4a09-b80e-4ad5a7ffbdf6

        linux linux-3.0.0_rc5-3 ro crypt_root=/dev/sda7 root_keydev=/dev/sda5 root_key=/gsys.gpg real_root=/dev/mapper/root real_rootflags=subvol=gentoo acpi=on mce vbe crypt_swap=/dev/sda6 swap_keydev=/dev/sda5 swap_key=/gswap.gpg real_resume=/dev/mapper/swap scsi_mod.scan=sync 

        initrd initrd-3.0.0_rc5-3

}
```

There seems to be a small hickup, if gpg encrypted keys are used. 

V.

----------

