What good is crypt?

I had /tmp and /var/tmp encrypted by the system for security purposes. Due to a file corruption problem not related to those directories, I booted with the OpenSuSE 12.1 KDE live CD. While I was letting fsck clean up my mess, I opened Dolphin and just for the heck of it, clicked on /tmp. I was able to see everything without being prompted for a passcode. The same was true for /var/tmp.
When I had Yast Partitioner encrypt the directories, I created tmp.crypt and var-temp.crypt in the root directory and used them to set up the encryption. I had Yast create loop files for each directory set at 500MB each. The setup went without error and I was always prompted for the passcodes during boot to unlock the directories for mounting.
My question is, did I do something incorrectly when I encrypted the directories, or is it possible to bypass the encryption by simply mounting the partition from a different OS as root?

It isn’t clear from your post, whether you were looking at “/tmp” from the live KDE system, or “/tmp” from your installed system, which would have to have been mounted somewhere else.

Even if you were looking at “/tmp” from the installed system, it isn’t clear whether you were looking at files on the original system, before mounting the encrypted container.

I don’t think it is possible to mount the encrypted container without giving the pass phrase.

Maybe recheck what you did. While looking at the “/tmp” (or “/var/tmp”), open a terminal window and use “df” to see what is mounted where. That will give you a better idea what you are looking at.

And check the file dates in the “/tmp” and “/var/tmp” you are seeing. If those are from around the date that you setup the encryption (or earlier), then you are probably looking at the base directory that is hidden when the encrypted container is mounted.

I was looking at the installed filesystem, not the running system from the CD. I mounted the hard drive. The file dates were newer than when the encryption was done. I would think that the original /tmp and /var/tmp would have been written over with encrypted information. Perhaps I made a mistake when I set it up. I’ll try to do it again, but delete the original files after it is set up. I agree that I should not be able to view them once the encryption is done. I have been pondering re-installing OpenSuSE 12.1 with the entire OS encrypted. Does anyone have any positive or negative thoughts on that?

On 02/09/2012 08:16 PM, purevw wrote:
> Does anyone
> have any positive or negative thoughts on that?

it is pretty easy to pop open dolphin (or whatever) and accidentally
look at /var/tmp in RAM, rather than /mnt/var/tmp or /media/var/tmp or
/opt/var/tmp or wherever you mounted the hard drive…

when you get it running again, have another look…i guess you will find
it impossible to read the encrypted drive…or as you say, maybe you
didn’t actually encrypt it…


DD http://tinyurl.com/DD-Caveat
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

That’s about what I am doing. Everything except “/boot” is encrypted. I did this by installing as an encrypted LVM. It is working very well.

I am running an encrypted (minus /boot) LVM install as performed by the installer and it’s working beautifully. It’s likely possible to also set up the same without re-installing but it may involve a considerable amount of work. Anyway I’m quite glad that I went ahead with the encrypted LVM setup. I’m in the process of studying the documentation to have a thorough understanding of it as well as to know what exactly I need to do in the event of certain failures and I highly recommend doing this if you do decide to go this route.

I didn’t realize a person could look at RAM through a file manager. Guess that’s why I’m still a student penguin. Just to be clear, I mounted the entire root partition of my installed system (/dev/sdc2). So what I was looking at was /tmp and /var/tmp in the root file system. The problem that originally caused me to use the live CD as a rescue disk was fixed before I looked around the root file system. As I had been using the computer, I was always prompted for the pass code to mount the encrypted directories. Anyway, I removed the loop files and decrypted all for now.

I would most likely choose to encrypt the entire install without the use of LVM. I have zero experience and knowledge concerning virtual machines. If I do decide to encrypt all, I assume the best way without LVM would be to simply create a separate partition for boot. Anyone please correct me if that is incorrect. My /home is on a separate partition already and I have not used a /swap partition for a very long time as I have 12GB of physical RAM.

Also, is it correct that Crypt uses only AES encryption? I set up cascading encryption on my Windows partitions with very good luck. decrypting seems fairly CPU intensive, but it has never really caused any problems. I use True Crypt under Wine to mount the Windows partitions under Linux.

One important question I would have is: how large should the boot partition be, providing plenty of padding for any larger future kernels? My current /boot shows to be 29MB in size.

On 2012-02-10 13:16, purevw wrote:
>
> I didn’t realize a person could look at RAM through a file manager.

There are some directories stored in ram, not disk.
And, if you point at certain files in /proc, you can certainly look at memory.


Cheers / Saludos,

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

On 2012-02-10 13:26, purevw wrote:
>
> I would most likely choose to encrypt the entire install without the use
> of LVM. I have zero experience and knowledge concerning virtual
> machines. If I do decide to encrypt all, I assume the best way without
> LVM would be to simply create a separate partition for boot. Anyone
> please correct me if that is incorrect. My /home is on a separate
> partition already

There is another manual procedure which I can’t describe with separate
passwords. When this question was asked previously I posted links to people
that did it, so they must be in the archive.

View this thread: http://forums.opensuse.org/showthread.php?t=456418
View this thread: http://forums.opensuse.org/showthread.php?t=466353

> Also, is it correct that Crypt uses only AES encryption?

No, that’s what yast uses. If you do it manually you can use whatever you like.

> One important question I would have is: how large should the boot
> partition be, providing plenty of padding for any larger future kernels?

Between quarter and half gigabyte. Ext2, not ext4.


Cheers / Saludos,

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

On 02/10/2012 01:16 PM, purevw wrote:
> I didn’t realize a person could look at RAM through a file manager.

i’m sure you already know this but lets review: when one has first
booted a live CD the hard disk is not available for writing any of the
system’s required temporary files…and, neither can they be written to
the CD…

so, the only place temporary file can be held is in /tmp and /var/tmp
directories which are mounted to the root directory of the system
running ‘live’ in RAM…

so, both before you take any action to mount the machine’s hard drive,
if you look in Dolphin you will see that there is already both a /tmp
and /var/tmp in the file system and at least /tmp will be populated, and
possibley /var/tmp also (depends on what you been doing)…

> Guess that’s why I’m still a student penguin.

hmmmmm…are you attempting to be sarcastic?

save your effort, i have not looked to see your ‘rank’ (which i now
assume is “Student Penguin”) in these fora because those are not served
up to folks who enter via nntp…

but, lets continue our review

> Just to be clear, I
> mounted the entire root partition of my installed system (/dev/sdc2). So
> what I was looking at was /tmp and /var/tmp in the root file system.

remember, the root file system is mounted (by the live system) in a RAM
Disk (in RAM)…so, when you mount /dev/sdc2 it is being mounted to that
existing file system which already has both /tmp and /var/tmp…

and, we know (don’t we) that can’t be two directories named tmp (or
/var/tmp) directories hanging off the root file system, something like this:


/
/bin
/<snip>
/tmp    < for the running live system - unencrypted
/tmp    < from the hard drive - encrypted
/<snip>
/var    < for the running live system
/tmp      < unencrypted
/var    < from the hard drive
/tmp      < encrypted

with one of /tmp’s (or /var/tmp) on the hard disk and the other already
mounted in the RAM disk…

so, to where did you mount /dev/sdc2 ?
a question i asked earlier and you didn’t answer…so, i will assume you
mounted /dev/sdc2 at /mnt/sdc2…

if you did, then you could in Dolphin and look at something like this:


/           < this is the root of the live file system in RAM
/bin       < looking here you see Live CD files
/<snip>
/mnt
/sdc2    < this is the root of the hard drive's file system
/bin   < looking here you see things on the hard drive
/<snip>
/tmp        <encrypted on the hard drive
/<snip>]
/var
/tmp      <encrypted on the hard drive
/tmp      < here you see the live CD's unencrypted files in RAM
[snip]
/var      < looking here you see the CD's files
/tmp    < here you see the live CD's unencrypted files in RAM
[snip]

as i said in earlier post “it is pretty easy to pop open dolphin (or
whatever) and accidentally look at /var/tmp in RAM”


DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

Thanks for the info. I find I’m needing to pull my foot out of my mouth once again. I’m not sure why I was thinking “virtual machine” when others mentioned LVM. I am slightly better educated now, but would still prefer to use standard partitions.

I do have an additional question. robin_listas suggested 1/4 to 1/2 gigabytle for /boot, which seems very reasonable. He also specified ext2 rather than ext4 for the file system. I’m sure there is a reason for that, but I have used Reiserfs for years. Is there a specific reason to use ext or is it a question of preference? Perhaps I am just being nostalgic by staying with Reiserfs for so long? In several years of using Linux with Reiserfs, there has only been one instance where the file system failed to automatically correct it’s own errors after a system hang and a forced “power off”. Even in that one instance, I was able to save everything with the KDE live CD and fsck --rebuild tree.

I apologize if I gave that impression. I was simply trying to affirm that although I am very comfortable and happy with OpenSuSE, I still have a lot to learn. To answer your questions, as I remember, the hard drive showed up as removable media and I mounted it via the Dolphin GUI. It showed up in the lower left pane of dolphin as 20GB file system and it was mounted by the Live system using it’s model and serial number. I can’t specifically remember if it mounted under /media or /mnt. I then navigated to the root of that partition. I am quite sure that I was in the root of the installed system because I also looked at /boot/grub/menu.list which I had modified, and some of my custom settings under /etc concerning hddtemp and my proprietary Ralink Wifi driver. I don’t remember ever looking at /proc for any reason.

I can only assume that I made some kind of error during the original encryption and even though the encryption was successful and I was always prompted for passwords during boot, the encrypted files were not mounted to /tmp and /var/tmp as I had intended.

On 02/10/2012 03:36 PM, purevw wrote:
> I can only assume that I made some kind of error during the original
> encryption

and i had assumed you did the encrypting right and accidentally looked
in the wrong place…


DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

On 2012-02-10 15:06, purevw wrote:

> I do have an additional question. robin_listas suggested 1/4 to 1/2
> gigabytle for /boot, which seems very reasonable. He also specified ext2
> rather than ext4 for the file system. I’m sure there is a reason for
> that, but I have used Reiserfs for years. Is there a specific reason to
> use ext or is it a question of preference?

Yes, I have reasons. The separate /boot partition should be type “ext*”
because that is, currently, a filesystem that is supported by the kernel
directly (no modules) and by grub. Others filesystems have problems of one
or another type.

Reiserfs, which is my system of choice, had till recently a bug (538795)
that made the startup (thawing) from hibernation to disk to be extremely
slow. Apparently the journal had to be replayed in memory, and while it had
worked with reiserfs for years, it stopped working at some kernel version.
It is also working right now (12.1).

XFS also had problems with grub, because one wanted to write where the
other had reserved space. I think this is now solved (not now, some years
back, IIRC)

IMO, it seems that ext* filesystem is the only one guaranteed to always
work for booting, because it is the only one they test and they solve bugs
fast. Others may work, or may break, and in the past they took YEARS to
solve the problems.

So, ext* for booting. Why not ext4? Because it has a journal! A journal is
not necessary for a small partition, adds used space, and probably has to
be replayed slowing boot. So no ext4, no ext3, but ext2.

For example, the minimal size for reiserfs is 100 MB, so I assume about
that size is used for the journal. That’s a waste.

Obviously, for a root partition without separate /boot partition, the
choices are different. Me, I use ext4 for root, xfs for home, and reiserfs
for partitions holding certain types of data or activity (news, building).
I limit my usage of reiserfs because it does not scale well in its current
version.

> Perhaps I am just being
> nostalgic by staying with Reiserfs for so long? In several years of
> using Linux with Reiserfs, there has only been one instance where the
> file system failed to automatically correct it’s own errors after a
> system hang and a forced “power off”. Even in that one instance, I was
> able to save everything with the KDE live CD and fsck --rebuild tree.

I have had filesystems destroyed completely with all types.


Cheers / Saludos,

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

The thing about an encrypted LVM, is that it is easy to setup during install. An encrypted root directory that is not part of an LVM is not currently supported by the installer. If you want that, you have to install first, backup the root directory, setup for encryption, restore from backup, rebuild the “initrd” to decrypt during boot. It’s a lot easier to just use an encrypted LVM.

There is another alternative. You can setup an encrypted LVM for only the root partition. You might have to manually edit “/etc/fstab” and “/etc/crypttab” later to use your existing “/home”. But that will be a lot easier than what you have to do for an encrypted root partition without LVM.

The thing about an encrypted LVM, is that it is easy to setup during install. An encrypted root directory that is not part of an LVM is not currently supported by the installer. If you want that, you have to install first, backup the root directory, setup for encryption, restore from backup, rebuild the “initrd” to decrypt during boot. It’s a lot easier to just use an encrypted LVM.

There is another alternative. You can setup an encrypted LVM for only the root partition. You might have to manually edit “/etc/fstab” and “/etc/crypttab” later to use your existing “/home”. But that will be a lot easier than what you have to do for an encrypted root partition without LVM.

I agree with those recommendations. I am currently using 100M for “/boot”. On a system with both default and desktop kernels installed, it is about 60% full. So going to 1/4G gives a little more room.

As for “ext2” - the “/boot” partition is rarely written to, so it doesn’t need a journal. Using ext2 keeps it simple.

On 02/10/2012 03:55 PM, DenverD wrote:
> On 02/10/2012 03:36 PM, purevw wrote:
>> I can only assume that I made some kind of error during the original
>> encryption
>

having now “slept on” this problem i think it is important to discover
(and fix) whatever it was that allowed you to think you had safely
encrypted a partition/file only to accidentally later discover that it
was not…

that (to me) seems a very bad bug! that is, if either the documentation
or tool you used to to the encrypting can report success in encrypting
(or not report the failure) then THAT really needs fixing…

so, i ask you to do it again exactly as you did before…follow the same
steps and use the same tool…and, then log the bug…please.

otoh, i might be different if you were not so insistent you inspected
the correct /tmp and found crypt to be faulty.


DD http://tinyurl.com/DD-Caveat
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW