[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: partman-auto-crypto

On Sun, Aug 20, 2006 at 08:23:53PM +0200, Frans Pop wrote:

On Sunday 20 August 2006 12:15, David Härdeman wrote:

As far as I know, the major outstanding issue is that of keyboard
input. Currently it seems that d-i does not allow UTF8 input which
means that passphrases with non-ascii characters won't work after
reboot into the newly installed system.

So it would really be nice to have a fix for #365308 which has been
open since April and affects other parts of d-i as well (such as
username input).


Yes, but we need some expert help on that...


Oh, and we need a more thorough check for unencrypted swap.
Is it correct that having an unencrypted swap will prevent the crypto option from being shown at all? I understood that from various comments. Seems to me that is very much non-intuitive.
No that's not the case. The problem is rather that right now if you do a setup without an encrypted swap and finish the setup of the encrypted volumes, you'll get a warning. However, once the crypto setup is done, you can still go back and change the swap to be non-encrypted and no warning will be given. 


Are you aware of any other major partman-crypto issues not in the BTS?


Support in graphical installer would be nice to have before the release.


What needs to be done?


As for lvm, I don't see any new bugs against partman-lvm, what issues
are you referring to?
The issues are mainly in partman-auto-lvm which partman-auto-crypto is based on (and thus also affected by).
I assume you're referring to the "should automatically delete existing LVM" issue? 


Another alternative is to not change the partman-auto main menu at all.
The menu might get crowded but that is mostly an issue with > 2 disks
which is not a very common scenario. This would allow p-a-c to be added
without any changes (the issue of overcrowding is orthogonal to p-a-c
IMHO, p-a-c just makes the problem more immediate).
IMO we would at least have to move "manual partitioning" to the top. There is also the issue of text getting cut of because strings are getting too long. This may make it impossible for users to see which disk they are selecting with which type of auto-partitioning and IMO that _is_ an RC issue that necessitates a reorganization. 


This was my original plan before you brought up the issue of crowding
the menu :)
Yes, I know :-) But I really feel at this point that we should not do one without the other.
Okey, I'll try to implement the reorganization during next week. From the comments so far, I take it that you'd prefer the two-level organization with "method" as the first screen and "disk" as the second? 


>> This allows multiple disks to be used for LVM or RAID and should
>> simplify the preseeding to use two values: method and disks to use.
>
>What RAID level(s) are you assuming/wanting to support here?

I'm not involved in the RAID part of partman, but I'd assume that
levels 0, 1 and 5 would be offered.


I' not sure that is a good idea:
- it would mean adding yet another question to select the RAID level
- it would add serious complexity to the partman-auto scripts
- I doubt that people who want RAID5 will be happy with the default
 schemes anyway and would prefer manual partitioning
My feeling is that RAID0 is fairly uncommon, but that supporting RAID1 is probably useful for less experienced users. So, I'd propose to limit RAID support in partman-auto to RAID1. 

I won't get involved in the partman-auto-raid UI issues :)


>Without yet having looked at the code...
>For p-a-c, what I have been wondering about is which partitions should
> be encrypted by default for the different schemes. From comments in
> earlier threads I understand that having e.g. /usr encrypted isn't
> all that useful.

Allows /usr to be managed with the LVM tools as well
No, that is a limitation in the current implementation and would be solved by using separate flags for lvm and crypto.
No, with p-a-c we have disk <-> crypto <-> lvm (in order to allow one password to give access to all partitions). If you want an unencrypted "/usr" to use LVM, you'd have to have a separate PV and VG for it which defeats most of the advantages of using LVM as you can't reallocate space between the partitions etc. 


Avoids any accidental disclosure of information, e.g. there is
/usr/local which may contain something of interest. Or the user may not
want it to be known even which programs he has installed.

The disadvantage is of course performance.
Which is an edge case and not main usage. IMO the performance argument outweighs that edge case. 

I agree that it's an edge case.


I think we should err on the side of caution and encrypt everything by
default.
Well, I'd prefer to do what users expect when selecting automatic partitioning using crypto... I think that users selecting the "home" scheme probably care more about what is in there than on the rest of their system.
Again, IMO partman-auto-* is not for super-sensitive specialized setups, but rather for rather average users who would like some extra security for their sensitive data. 


>So what partitions does p-a-c set up encrypted currently? I could
> imagine something like ("<c>" indicates encryption):
>"atomic": / <c>, /boot, swap <c>
>"home":   /, /boot, /home <c>, swap <c> (so, / not encrypted)
>"multi":  /, /boot, /tmp <c>, /usr, /var <c>, /home <c>, swap <c>
>          (maybe / should be encrypted too in this case)

I would definately encrypt / as well. /etc usually contains a lot of
good information for an attacker (e.g. /etc/shadow).
OK, except that IMHO that is not sufficient reason to encrypt everything else too in the case of the "home" recipe.
This only leaves /usr in the "home" recipe. Should it have a completely separate LVM VG/PV or should it not be on LVM at all then? 


Right now all partitions which are marked as $lvmok { } are encrypted.
I assume that "palo" partitions and other special partitions aren't
marked as $lvmok?
OK. That should be fine. Although I do think that a separate flag would be better: 
- adds flexibility
- $lvmok is a misnomer if it also determines if crypto is supported
If you want to check for both flags to prevent setting up crypto on a non-lvm partition, that would be fine.
That seems like a good solution. It would also protect against hypotetic situations such as if grub would gain LVM support and /boot would be marked $lvmok. 

Regards,
David
Reply to: