[opensuse-factory] topics next dist meeting
for tomorrow's meeting we have one topic so far: Encrypted Home Partitions: - Use dm-crypt and LUKS by default for newly encrypted partitions - Modify our existing cryptographic scripts to handle dm-crypt/LUKS-based partitions - For user's home, allow the option of one LUKS partition or a per-user loopback-mounted LUKS file. - Provide a series of tools for the easy management of the above. This is something for 10.3 and will not make 10.2;-) Any comments, suggestions etc? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello, Am Mittwoch, 15. November 2006 21:17 schrieb Andreas Jaeger:
for tomorrow's meeting we have one topic so far:
Encrypted Home Partitions:
- Use dm-crypt and LUKS by default for newly encrypted partitions
From what I remember from the german Linux Magazin some time ago (multiple passwords per partition, passwords easily changeable etc.), this is a very good idea :-) [... more good ideas snipped ...]
Any comments, suggestions etc?
I'd propose to check how useful /etc/cryptotab is. I see several disadvantages compared to an entry in /etc/fstab: a) /etc/cryptotab needs an explicit /dev/loopX entry YaST2 always puts the first (at partition creation time) available device (usually /dev/loop0) to /etc/cryptotab This becomes funny if you manually add a loop mount to your fstab which is mounted at boot time - in fact, you won't be able to mount the encrypted partition because /dev/loop0 is already in use. In fstab, you don't need to specify which loop device to use - you specify the "loop" option and it simply uses the first available, whatever number it has. Yes, you can specify which loop device to use in /etc/fstab or you can modify /etc/cryptotab to use another loop device - but this are ugly workarounds. b) if you skipped mounting your encrypted partition while booting, you can't mount them with "mount" afterwards if they are not listed in fstab. See also https://bugzilla.novell.com/show_bug.cgi?id=209647 (which might be invalid for yast2-storage, but not for the whole story) In short, there's no additional value by using a separate file (/etc/cryptotab) for encrypted partitions, but several disadvantages and problems. OTOH, I see no disadvantages when using /etc/fstab for encrypted partitions. Did I already mention that I suggest to drop /etc/cryptotab completely and to put all partitions, including encrypted, to /etc/fstab? ;-)) Regards, Christian Boltz PS: If you decide not to drop /etc/cryptotab, please consider to drop the "loop device" column. I proposed this some time ago [1], but this was (understandable) WONTFIX because it would be an incompatible change. Now that you are going to do major changes, compatibility could get rated lower. [1] https://bugzilla.novell.com/show_bug.cgi?id=77126 (9.3 bug, therefore not public unfortunately) Oh, and /etc/cryptotab bit back in 10.0 ;-) https://bugzilla.novell.com/show_bug.cgi?id=105020 (public bug) Short summary: The installation/update now ignores the "loop device" column... -- [IP-Adresse von ppp0 mit system() ermitteln] Dazu Perl zu verwenden, ähnelt sicherlich ein wenig der Spatzenjagd mit großkalibrigen Langrohrgeschützen...;-) [Christian Schmidt in suse-linux] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Wednesday, November 15, 2006 at 23:53:45, Christian Boltz wrote:
Am Mittwoch, 15. November 2006 21:17 schrieb Andreas Jaeger:
for tomorrow's meeting we have one topic so far:
Encrypted Home Partitions:
- Use dm-crypt and LUKS by default for newly encrypted partitions
From what I remember from the german Linux Magazin some time ago (multiple passwords per partition, passwords easily changeable etc.), this is a very good idea :-)
[... more good ideas snipped ...]
Any comments, suggestions etc?
I'd propose to check how useful /etc/cryptotab is. I see several disadvantages compared to an entry in /etc/fstab:
In short, there's no additional value by using a separate file (/etc/cryptotab) for encrypted partitions, but several disadvantages and problems. OTOH, I see no disadvantages when using /etc/fstab for encrypted partitions.
I see a big one. It does not work with device mapper :) There is no support in mount to setup a dm on the fly (which is what a loop entry does). Maybe we can add that for 10.3 but that mean a lot of work. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2006-11-15 at 23:53 +0100, Christian Boltz wrote:
Hello,
Am Mittwoch, 15. November 2006 21:17 schrieb Andreas Jaeger:
for tomorrow's meeting we have one topic so far:
Encrypted Home Partitions:
- Use dm-crypt and LUKS by default for newly encrypted partitions
From what I remember from the german Linux Magazin some time ago (multiple passwords per partition, passwords easily changeable etc.), this is a very good idea :-)
[... more good ideas snipped ...]
Any comments, suggestions etc?
I'd propose to check how useful /etc/cryptotab is. I see several disadvantages compared to an entry in /etc/fstab:
a) /etc/cryptotab needs an explicit /dev/loopX entry
YaST2 always puts the first (at partition creation time) available device (usually /dev/loop0) to /etc/cryptotab
This becomes funny if you manually add a loop mount to your fstab which is mounted at boot time - in fact, you won't be able to mount the encrypted partition because /dev/loop0 is already in use.
In fstab, you don't need to specify which loop device to use - you specify the "loop" option and it simply uses the first available, whatever number it has.
Yes, you can specify which loop device to use in /etc/fstab or you can modify /etc/cryptotab to use another loop device - but this are ugly workarounds.
b) if you skipped mounting your encrypted partition while booting, you can't mount them with "mount" afterwards if they are not listed in fstab. See also https://bugzilla.novell.com/show_bug.cgi?id=209647 (which might be invalid for yast2-storage, but not for the whole story)
In short, there's no additional value by using a separate file (/etc/cryptotab) for encrypted partitions, but several disadvantages and problems. OTOH, I see no disadvantages when using /etc/fstab for encrypted partitions.
Did I already mention that I suggest to drop /etc/cryptotab completely and to put all partitions, including encrypted, to /etc/fstab? ;-))
Regards,
Christian Boltz
PS: If you decide not to drop /etc/cryptotab, please consider to drop the "loop device" column. I proposed this some time ago [1], but this was (understandable) WONTFIX because it would be an incompatible change. Now that you are going to do major changes, compatibility could get rated lower.
[1] https://bugzilla.novell.com/show_bug.cgi?id=77126 (9.3 bug, therefore not public unfortunately)
Oh, and /etc/cryptotab bit back in 10.0 ;-) https://bugzilla.novell.com/show_bug.cgi?id=105020 (public bug) Short summary: The installation/update now ignores the "loop device" column...
It's been a while ago since i experimented with crypto (beginning 10.1 ;-) But from what i recollect... 1) Using the general partitioner, with yast, results in a partition that gets mounted at startup. works well, but the partition gets mounted allways. 2) Some people (not me) wants to encrypt EVERYTHING, inluding swap and root. AFAIK, that is still not possible. Perhaps its should be pointed out, that it both a) irrelevant, and b) counter productive. a) 90% on the harddisk is opensource and general available b) encrypting cost cpu-cycles,so hard disk will be slowed down. 3) best solution (imho) is to have for each individual user a seperate container, which gets mounted on his home directory after login (pam_mount) 4) for the the paranoia, have also /var/spool/mail en swap encrypted Nothing else is worthwhile 5) for the super-paranoia, encrypt with the key from a smartcard. I still use loop-aes on my usk-stick and i would highly recommend it.. Hans -- pgp-id: 926EBB12 pgp-fingerprint: BE97 1CBF FAC4 236C 4A73 F76E EDFC D032 926E BB12 Registered linux user: 75761 (http://counter.li.org) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Am Donnerstag, 16. November 2006 20:21 schrieb Hans Witvliet:
It's been a while ago since i experimented with crypto (beginning 10.1 ;-) But from what i recollect... 1) Using the general partitioner, with yast, results in a partition that gets mounted at startup. works well, but the partition gets mounted allways.
It should be possible to mark it as "mount by user" and/or "noauto" in YaST. (However, I never tried that.)
2) Some people (not me) wants to encrypt EVERYTHING, inluding swap and root. AFAIK, that is still not possible.
It is possible - with the exception of /boot. http://tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/
Perhaps its should be pointed out, that it both a) irrelevant, and b) counter productive. a) 90% on the harddisk is opensource and general available
Well, encrypting _everything_ is really something that you need very rarely. However, it's important that you encrypt /tmp and (large parts of) /var because sooner or later your data "leaks out" to a tempfile or alike... Encrypted swap is also a good thing from the security point of view (you never know which of your data gets swapped out) - unfortunately it doesn't work with suspend2disk AFAIK.
b) encrypting cost cpu-cycles,so hard disk will be slowed down.
Of course, but with today's CPUs I consider this a minor problem. Usually the harddisk performance is the limiting factor, not the CPU.
3) best solution (imho) is to have for each individual user a seperate container, which gets mounted on his home directory after login (pam_mount)
4) for the the paranoia, have also /var/spool/mail en swap encrypted Nothing else is worthwhile
As already said: /tmp and parts of /var (like /var/tmp, /var/lib/mysql, ...) can also contain sensitive data. A simple example: Click any attachment in KMail - it will be saved to /tmp/kde-$user/... temporarily. My paranoia level ;-) is: I have symlinked most of /var to my encrypted partition - except for /var/log, /var/lock and /var/run which would need some more tuning. See https://bugzilla.novell.com/show_bug.cgi?id=140226 for details.
5) for the super-paranoia, encrypt with the key from a smartcard.
;-) Regards, Christian Boltz -- "Hast du schon gehoert: Ein Bug im Netscape Navigator erlaubt es jedem, übers Internet deine Festplatte zu lesen." - "Weiss ich, deshalb bleibe ich ja auch bei Netscape - wenn's ein Microsoft-Bug waere, dann dürfte jeder meine Festplatte auch noch beschreiben..." --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 16 November 2006 21:30, Christian Boltz wrote:
A simple example: Click any attachment in KMail - it will be saved to /tmp/kde-$user/... temporarily.
Have you tried setting TMPDIR to something other than /tmp before logging in to kde? /opt/kde3/bin/lnusertemp will create those user directories on login So a user that a) wants to have his data on an encrypted partition, and b) doesn't want his data on a partition where he doesn't control the encryption key, has options --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (5)
-
Anders Johansson -
Andreas Jaeger -
Christian Boltz -
Hans Witvliet -
Henne Vogelsang