Enncrypted Root Partition

Any idea if it is possible to install openSUSE with an encrypted root partition?

Tried it and got this error message

http://i52.tinypic.com/25yvyfl.png

IIRC it is not possible, at least not immediatly from the installer. (And that is what it tells you).

Yes, it can be done. But you can’t install that way. For details, see:
SDB:Encrypted root file system - openSUSE

What you can do, and I recommend this as an alternative, is use an encrypted LVM. The installer understands doing it that way. You will need a separate “/boot”, and everthing except “/boot” will be part of the encrypted LVM. I blogged about this a few months ago: Disk encryption

On 2011-10-03 13:16, nrickert wrote:
>
> Yes, it can be done. But you can’t install that way. For details, see:
> ‘SDB:Encrypted root file system - openSUSE’
> (http://en.opensuse.org/SDB:Encrypted_root_file_system)
>
> What you can do, and I recommend this as an alternative, is use an
> encrypted LVM. The installer understands doing it that way. You will
> need a separate “/boot”, and everthing except “/boot” will be part of
> the encrypted LVM. I blogged about this a few months ago: 'Disk
> encryption ’
> (http://nwrickert.wordpress.com/2011/06/06/disk-encryption/)

There is another method, that was described in the security mail list,
without using LVM, and entering the passphrase just once. I can not explain
the method, I have not used it, so read it there.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve only used the LVM method, but I’ve used it for a couple years and I
am only prompted for the passphrase (on boot or un-hibernate) once.
Works like a champ and everything I care about (non-/boot) is encrypted.
The installer now handles this too, which is really nice since it used
to be a bit more-manual.

Good luck.


Want to yell at me in person?
Come to BrainShare 2011 in October: http://tinyurl.com/brainshare2011
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOib2CAAoJEF+XTK08PnB5ploP/RJw1TNZWelFDgCGlV7H3w5b
XwtN3cqMb8tLg1cLkHVR3t7eSujQYIRW04j3XT8Uj/ZrY1H/yAfskEsO2ig3zmC9
j7B1I1maBjQ8Seo+BlfzfbHQ3XgTO9N6jqrmol6llkvpO/25EeshgXO3TDPF2UlK
/Ua0bEMQiDqBDaBLTltihzhfsn9W6YaRNf9Qtk9p5dNpNOZ5sdWom6bC5xiTFTxK
zceT2qqu6Rnc9CbekIRXXfNKRVPVxp9lPvVxo02uMWMyLbRJjUemiN7jzst6G/B/
wmFdJmybxRCPXP2rBkv0KtMCSxA0ybxQaxjaod3mfO7CnPTNX9BUT6oA76Hx/B6a
vcAYG0MWB/V6hbcvnuqGr2Gw/RTlgu+X0L1HGbXhMiqKBQWZ52WDSig8u7W87ahO
XjuZ0E3Sqp4oykbmZjLTuDRrnXYPdxsfko0ieolkY2GiA6A62A4RkO10yo2hTPe4
xeog+PMnB/+PcdHk8tK6e49cXRxNqDL4ILlLP61tSPKJdWJq7h5ulDNuoWiczE5u
1nFpWFGpcB5j+k71wiK/8GM6FeWREVanLKliZ6uYZtpGDah/ThhywEDsc68/Vgvq
HM+fegN2oG3hYBhuB8eizjr2HtfTkck+AmN3wxvFapnV4HawDDd3QB0v0n52zMo8
B6HbU8bMngVRxUePpDNZ
=b3N/
-----END PGP SIGNATURE-----

On 2011-10-03 15:49, ab wrote:
> I’ve only used the LVM method, but I’ve used it for a couple years and I
> am only prompted for the passphrase (on boot or un-hibernate) once.
> Works like a champ and everything I care about (non-/boot) is encrypted.
> The installer now handles this too, which is really nice since it used
> to be a bit more-manual.

I know, but I don’t like LVM.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

I suspect that is the one that I mentioned, and provided a link to. You even quoted the link.

Thanks everyone for the advise,

Understand that this could be achieve through LVM, however do not quite understand the purpose of installing LVM on my laptop. Therefore am looking at a normal install instead.

I have been using LUKS on my home folder for previous install and with a new install, curious about encrypting all except /boot during a livecd install.

Had browse through
en.opensuse.org/SDB:Encrypted_root_file_system as suggested, which forwards me to
SDB:Official documentation - openSUSE and reforwarded to
http://www.novell.com/documentation/opensuse114/

but unable to locate the information that enable encryption of / during livecd install.

Thanks anyway.

On 2011-10-03 23:26, nrickert wrote:
> I suspect that is the one that I mentioned, and provided a link to.
> You even quoted the link.

No, the method in the wiki is not the same one I’m referring to. It was
somebody that was not happy with either method (LVM or wiki) and finally
found, or invented, a method which she wrote about in the mail list.

> http://lists.opensuse.org/opensuse-security/2010-10/msg00026.html


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2011-10-04 00:26, michalng wrote:
>
> Thanks everyone for the advise,
>
> Understand that this could be achieve through LVM, however do not quite
> understand the purpose of installing LVM on my laptop. Therefore am
> looking at a normal install instead.

Using LVM is a trick.

The idea is that you encrypt the entire space used by the LVM system, and
then “partition” the contents: root, home, swap (?), etc. /boot has to be
an independent, non encrypted partition.

When the system boots, it asks you once for the password.

The other, classic method involves encrypting each (real) partition
separately (with same or different passphrase), and on boot the system will
ask for the same pass several times, one for each partition.

Alternatively, there is the other method I posted the link to. You’d better
read the entire thread.

> Had browse through
> ‘en.opensuse.org/SDB:Encrypted_root_file_system
> (http://en.opensuse.org/SDB:Encrypted_root_file_system) as suggested,
> which forwards me to
> ‘SDB:Official documentation - openSUSE’
> (http://en.opensuse.org/SDB:Official_documentation) and reforwarded to
> http://www.novell.com/documentation/opensuse114/
>
> but unable to locate the information that enable encryption of / during
> livecd install.

Me too. I think the article is incomplete, this is not what I remember. The
real article is in the last link:

> [http://en.opensuse.org/SDB:Encrypted_root_file_system_(deprecated)](SDB: Encrypted root file system_(deprecated))

Note that this method is not supported by YaST, you can not do it from the
live CD install.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 10/04/2011 12:26 AM, michalng wrote:
>
> I have been using LUKS on my home folder for previous install and with
> a new install, curious about encrypting all except /boot during a livecd
> install.

what would be the advantage of encrypting the open source software of
the system existing in the root directory?

i mean, i understand the advantages of encrypting /home and any other
partition used to hold personal files, data, etc…but, why encrypt the
the container for the operating system??

what could a thief find useful in there??


DD
openSUSE®, the “German Automobiles” of operating systems

i agree that there is no information of value to steal, but a keylogger/packetsniffer/malware/etc could not be installed to the encrypted volumes, limiting the evil-doer to the boot partition and bootsector, which hopefully would be much easier to verify integity.

On 2011-10-04 11:16, j xavier wrote:
>
> i agree that there is no information of value to steal, but a
> keylogger/packetsniffer/malware/etc could not be installed to the
> encrypted volumes, limiting the evil-doer to the boot partition and
> bootsector, which hopefully would be much easier to verify integity.

Remember that when the system is running, the filesystem is in clear via
system services. If you are hacked, the keylogger would enter.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 2011-10-04 09:30, DenverD wrote:

> what could a thief find useful in there??

No, the idea is not protect the system software, but temporary files that
are used normally on various places of the disk that could give information
to a thief.

You could protect only /home and /tmp, perhaps. But the paranoid aka safe
measure is encrypt all (including swap, of course).


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

The main issue is with files in “/tmp” and “/var”. User data can leak to those locations.

Personally, I am not seeing much risk in “/var”. So I settled with encrypted home, encrypted swap, and mounting “/tmp” from swap.

Unfortunately, I am unable to mount “/tmp” from swap in the 12.1 Beta1. If that is not fixed, I will have to go with an encrypted LVM.

On 2011-10-04 13:26, nrickert wrote:
> Unfortunately, I am unable to mount “/tmp” from swap in the 12.1 Beta1.
> If that is not fixed, I will have to go with an encrypted LVM.
>

I hope you wrote the bugzilla… else, it will not be fixed.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

https://bugzilla.novell.com/show_bug.cgi?id=721683

On Tue, 04 Oct 2011 11:26:02 +0000, nrickert wrote:

> The main issue is with files in “/tmp” and “/var”. User data can leak
> to those locations.

Sure, but when the system is up and running, the files are available to
all users in unencrypted format because the filesystem is mounted.

What it will protect against is an attacker accessing the filesystem if
they have to boot the system or try to use offline tools.

If the system is booted (or not shut down but put in hibernation) at the
time of the attack, an encrypted root partition won’t really protect
against much of anything.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

agreed, i was considering the scenario of a poweroff/unattended machine.

In part, that depends on file permissions. I encrypt files that need to be kept private (in addition to using an encrypted home partition).

The leaking of information is for temporary copies of that encrypted data, such as might exist unencrypted while reading or updating the file.

My primary reason for using encrypted partitions is concern about somebody stealing my laptop, though that has not happened thus far.

In practice, I also encrypt on a desktop for consistency between the laptop and desktop. As a side benefit, I won’t have to be so concerned with scrubbing the disk when I eventually junk the system for newer hardware.