Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday May 01 2020, @11:04AM   Printer-friendly
from the resistance-is-futile.-/home-will-be-assimilated dept.

Good News:

Linux home directory management is about to undergo major change:

With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.

[...] Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy.

But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.

[...] let's take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.

However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.

[...] Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes.

Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.

[...] Of course, such a major change doesn't come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH?

The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user's home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration.

Older articles:

Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by Arik on Friday May 01 2020, @03:05PM (8 children)

    by Arik (4543) on Friday May 01 2020, @03:05PM (#988996) Journal
    Since you mentioned the 90s, you reminded me of Stacker.

    Some things have changed but the underlying principle is still about the same.

    Stacker effectively encrypted your partition, sure it was compression aimed at reducing the bytecount rather than preventing unauthorized reads, but it amounts to the same thing as it's relevant here.

    Stacker was actually a useful product, used correctly. And by used correctly, I mean to compress a data drive. If you're working all day on documents that are highly compressible, on a system that typically has the cpu idle while waiting for the HDD, you could not only fit more documents on the same drive this way, you could significantly speed up read and write access as well. 10x compression was effectively 10x more buffer memory on the disk, at the cost of a bit of cpu time.

    The WRONG way to use it was the way it was usually used, however. Compressing the boot drive or anything needed to start the system often ended in catastrophe.

    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0, Informative) by Anonymous Coward on Friday May 01 2020, @10:58PM (7 children)

    by Anonymous Coward on Friday May 01 2020, @10:58PM (#989248)

    Encryption and Compression are the same thing, period.

    They both replace N-bits with a symbol of M-bits, using some key. Sometimes N and M are equal, other times they are not. Actuall all modems work the same way. Compression the algorithm and starting key is known. Encryption they are generally at least 1 is not known.

    That's it. Nothing more fancy than. So yes Stacker and homed's poor thought pattern are same. My guess the best way to setup a new user spaces is a linking directory. So nothing in that rat hole can affect you.

    • (Score: 2) by martyb on Saturday May 02 2020, @01:03AM

      by martyb (76) Subscriber Badge on Saturday May 02 2020, @01:03AM (#989277) Journal

      RWAFpuEJLQCHGLvABGAF nsAFqv PUBGzECHEJrwFKFKvABGAF nsEJrw GLuzrw FKnszErw GLuzvAAFty, CHrwEJvABGqv.

      I would argue that is not plain text. Go ahead and try to decrypt it.

      Hint:

      Rapelcgvba naq Pbzcerffvba ner gur fnzr guvat, crevbq.

      Here's another hint:

      WFuJQHLAGF sFv UGEHJwKKAGF sJw Lzw KsEw LzAFy, HwJAGv.

      Get it yet?

      The cyphertext of the first hint was rot13(plaintext).

      The cyphertext of the second hint was rot18(plaintext)

      The original cypher was: For each letter c in the source text, replace it with rot13(c) rot18(c).

      So, I *might* agree that all compression is a form of encryption, but not all encryption needs to have compression.

      Source text:

      Encryption and Compression are the same thing, period.

      Was that a period or a full-stop?

      --
      Wit is intellect, dancing.
    • (Score: 1) by khallow on Saturday May 02 2020, @12:18PM (5 children)

      by khallow (3766) Subscriber Badge on Saturday May 02 2020, @12:18PM (#989431) Journal

      Encryption and Compression are the same thing, period.

      [...] Compression the algorithm and starting key is known. Encryption they are generally at least 1 is not known.

      So you're contradicting yourself mere a few sentences later. Let us keep in mind the whole point of the exercise. Bits aren't being replaced with bits for the thrill of it. In the case of compression, it's done to store information in a smaller format. In the case of encryption, it's done to prevent other parties from accessing the information. These very different goals also show up in reverse engineering. It's fairly easy to reverse engineer compression algorithms. It ranges from extremely hard to mathematically impossible to reverse engineer encryption algorithms.

      • (Score: 0) by Anonymous Coward on Saturday May 02 2020, @01:45PM (3 children)

        by Anonymous Coward on Saturday May 02 2020, @01:45PM (#989451)

        You are over thinking it. You are trying to say the intent is what defines it, but the base function, remains the same: symbol replacement.

        One of the best an easiest in encryption method is ZIP files, with a simple password. Why the "compression" function makes the texst unreadable and then add a simple xor over the space makes breaking very hard. But this gets down to simple again simple processes.

        Take just the simple rotate encryption method and make a minor change. Start with a list of 256 characters filled so that element 00 is filled with x00, 01 is x01 and so on. Now look up each letter in the table and spit out the replacement address. Then move the found letter to the 00 position and shift others down. So EEGEG would be replaced with E,x00,G,x01,x01. You call that encryption. But is also a precursor to improve compression, since it heavily coverts a lot of text to a heavily weighted "left handed character steam, so it improves the compression algorithm. IF it outputs a number stream asc(E),0,asc(G),1,1 then we get down to 11 symbols to compress 0-9 and ",". Even better compression can be preformed. Just using the initial list the decoding will work in reverse. See Dr Jobbs from earily 80's.

        Now make one more change the original list instead of seeding with x00,x01,x02. But a random string of non-repeating characters, using some "pass key". Then stream is not clear text readable. but the patterns are same, so all the other work just the same. all the other benefits are present highly compressible. Just without the "pass key" seed the list again, the stream is junk. But yes, you could make hundreds of runs crack it so the over all encryption is weak, but still encrypted.

        I used this method in the 90's to improve storing signatures that had to be sent via cellular modem. Took a 70k "B&W" signature picture and compress to under 768 bytes. was very conversion on 386 table of day and quick send over modem (2400 baud), also fairly secure since 3 symbol replacements methods were used together transform the data giving both reduction in size and human readability.

        So again the only difference between encryption and compression which are both symbol replacements is what is known and not known. Compression everything is known, starting key/pad/list and methodical. Encryption at least starting key/pad/list is not generally known.

        • (Score: 1) by khallow on Saturday May 02 2020, @03:58PM (2 children)

          by khallow (3766) Subscriber Badge on Saturday May 02 2020, @03:58PM (#989513) Journal

          You are trying to say the intent is what defines it

          I'd say "succeeding at". You can abstract any human activity (just the phrase alone does it) to a level where you're not distinguishing the differences. But once you abstract enough that you lose track of why the activity happens, then you've gone too far.

          Here, not only have you lost track of the differences between encryption and compression, you've conflated it with a bunch of other human activity. Such as the very generic activities of communication, translation, and recording/logging.

          • (Score: 0) by Anonymous Coward on Sunday May 03 2020, @12:07AM (1 child)

            by Anonymous Coward on Sunday May 03 2020, @12:07AM (#989644)

            Another Trump ID-10T was just heard from. Scientists are liars. The world is flat. Get me my metal hat to keep the rats out.

            Remember base learning.
            A=B, C=B there for A=C Simple math.

            Encryption is translation, Compression is translation, a translation is a translation, period. The only thing missing in one to but not in the other is the base key.

            PS: Learned have used these facts, outside of Chicago, working inside a big circle. With real scientists that dealt with number theories and military encryption. That was their specialty. Its wonderful who you can meet and talk with for hours in the intersection between MENSA and LUGs.

            • (Score: 1) by khallow on Sunday May 03 2020, @12:15AM

              by khallow (3766) Subscriber Badge on Sunday May 03 2020, @12:15AM (#989645) Journal

              A=B, C=B there for A=C Simple math.

              Except, of course, when A!=B or C!=B. Simple math. The problem here is not simple math. It's the use of an equivalence relation that is too general.

              PS: Learned have used these facts, outside of Chicago, working inside a big circle. With real scientists that dealt with number theories and military encryption. That was their specialty. Its wonderful who you can meet and talk with for hours in the intersection between MENSA and LUGs.

              Facts which were irrelevant to the thread!

      • (Score: 3, Interesting) by Arik on Saturday May 02 2020, @02:52PM

        by Arik (4543) on Saturday May 02 2020, @02:52PM (#989486) Journal
        So I think my formulation was accurate here.

        While there is a distinction, it's a fine one. When your PC won't boot and you fire up the disk editor to figure out why, you aren't going to be able to process what you're seeing, whether the data was encrypted to prevent it from being read, or compressed to make it smaller may not be apparent or even important. Either way, what you're seeing isn't data you can make sense of and repair. Either way, the data is locked behind a complex substitution cipher AND THEN corrupted in some way, and how are you going to spot the corruption if the whole thing was enciphered first?
        --
        If laughter is the best medicine, who are the best doctors?