PLiSS cryptofilesystem with SuSE 9.1?

For purpose of saving confidential data, especially passwords, I
developed a specific system of encrypted partitions and containers.
(Personal Linux Security-System; PLiSS)

The encrypted file-*containers*, e.g. for the files of the home-directory,
were here as well layed down in *partitions* encrypted, too. So you can
mount resp. unmount such file-containers without any loss of security also
while the system is running.

So far, so well. The problem is only that the SuSE-modul for generating such
cryptofiles supports that approach not as yet. So I can't presently
establish my system fully automaticly. For example I have to move the
respective entrys made by OS from the cryptotab to the fstab by hand. But
not enough with that. SuSE 9.1 changes under some conditions (e.g. during
creating a new filecontainer) the respective entrys on its own. But, if the
changed entrys are replaced again by the former entries, the old entries
will not work any more :-(( .


So it happened to me that the original entry in fstab:

>/tmp/encrypted_file**/home/stefan**********ext3*****
>loop,encryption=twofish256,noauto,user,acl,user_x attr

was replaced by the following entry

>/tmp/encrypted_file***/home/stefan*********ext3******
>acl,user_xattr,loop=/dev/loop0,encryption=twofish256,
>phash=sha512,itercountk=100

Of course, I unterstand some of the entrys, but for some other I ask you for
your help. So, but now simply one after the other:

********OLD*************************************NE W************

/tmp/encrypted_file /home/stefan*ext3* /tmp/encrypted_file /home/stefan*ext3

*REMARK:* Clear: path to the container, mountpoint, filesystem.
***
******
********OLD*************************************NE W************

acl******************** acl

**REMARK:*:* Also clear: entry for acl-extension
******
********OLD*************************************NE W************

user_xattr******************** user_xattr

*REMARK:* I don't know, what that shall mean. Simply copied. Surely not so
important.
*****
*******OLD*************************************NEW ************

encryption=twofish256*****************encryption=t wofish256*

*REMARK:* Algorithm for encryption. By the way, previously SuSE used just
only twofish.
*****
********OLD*************************************NE W************

loop******************** loop=/dev/loop0


*REMARK:* Apparently SuSE is now binding the particular cryptofilesystems
statically to a specific loop-device, instead of dynamicly like before. So
I've got some problems. Because e.g. /dev/loop0 is in my case always
already occupied by that encrypted partition, on which my file-container
for the home-directory is stored. If I don't mount that partition, I can't
reach my homecontainer anyway. I simply changed the device-assignment. Then
it works. Was that statical binding of loop-devices already possible in
former times, or is that a new feature?PLiSS Cryptofilesystem mit SuSE 9.1?
PLiSS Cryptofilesystem mit SuSE 9.1?
********ALT*************************************NE W************

******************* phash=sha512*
*REMARK:* What, the f.., is that?
******
********ALT*************************************NE W*************

******************* itercountk=100*

*REMARK:* See above.***

********ALT*************************************NE W*************

noauto,user********************

*REMARK:* Wonderful! How careful! The people of SuSE are apparently of the
opinion that only root should mount a cryptofilesystem, and impose their
point of view on everybody, who don't shares their convictions.

TIA
Stefan
--
PsyPaM: Neue Hilfsmittel und Methoden zur Benutzeridentifikation-

Stefan Weinzierl; Bambergerstr.31; 96135 Stegraurach
Fon: 0951/2970067; Fax: 0951/2970068
Website: http://www.PsyPaM.com; E-Mail: Stefan.Weinzierl@PsyPaM.com

In article <1987402.Xcbnlxp4Ds@psypam.com>, Stefan Weinzierl wrote:
> For purpose of saving confidential data, especially passwords, I
> developed a specific system of encrypted partitions and containers.
> (Personal Linux Security-System; PLiSS)

I currently use emacs+crypt++ for small files, like my passwords
wallet.

If emacs is "sticky" (not swapped to disk), then AFAIK, the cleartext
is limited to memory.

For large files used by scripts, I wrapper gpg(1) around their use.

> Of course, I unterstand some of the entrys, but for some other I ask you for
> your help. So, but now simply one after the other:
>
> ********OLD*************************************NE W************
>
> user_xattr******************** user_xattr
>
> *REMARK:* I don't know, what that shall mean. Simply copied. Surely not so
> important.

Allow extended user attributes (e.g. namespace, mime_type, md5sum, ...)
if supported by filesystem. IIRC, this is required by acl. See attr(5)
for details.

> ********OLD*************************************NE W************
>
> loop******************** loop=/dev/loop0
>
>
> *REMARK:* Apparently SuSE is now binding the particular cryptofilesystems
> statically to a specific loop-device, instead of dynamicly like before.
> ... Was that statical binding of loop-devices already possible in
> former times, or is that a new feature?

AFAIK, this has been available for several years. See mount(8) for details.

> ********ALT*************************************NE W************
>
> ******************* phash=sha512*

I suspect this is the choice of hash (posix hash = SHA-1) (512???) used
for the extended user attributes above.

> ********ALT*************************************NE W*************
>
> ******************* itercountk=100*

I suspect this is the count of mounts (or accesses) between hash testing
above.

> ********ALT*************************************NE W*************
>
> noauto,user********************
>
> *REMARK:* Wonderful! How careful! The people of SuSE are apparently of the
> opinion that only root should mount a cryptofilesystem, and impose their
> point of view on everybody, who don't shares their convictions.

Actually, SuSE's default is deliberately conservative. If you don't
like their default, change it on your system.

Personally, I praise SuSE for their efforts to set their default
configuration to conservative safe settings. The user is free to
open access the user selects on their system as they learn the
risks and benefits. I've found the documentation that appears
in the sysadmin's mail upon installation, to be very useful in
openning up access in this regard.

Hopefully helpful,
--
Dr. Robert J. Meier