Some geeky traditions did continue in 2020, including FOSDEM — the Free and Open Source Software Developers’ European Meeting. The special 20th-anniversary edition still went off as scheduled in Brussels in early February, giving the community’s developers a chance to hear from one another. And last week the videos finally appeared online — including a …

Interesting story about improvements to user’s home directories on Linux.

@akagusu
22M

There are two problems with his solution:

1: it tries to fix problems that doesn’t exist.

When Unix was designed there were no yubikeys, full disk encryption, malicious actors trying to steal your data etc. Passwords and ACLs were just fine. So its is not that Unix (or a unix-like system such Linux) has a problem, it’s more like the use we do isn’t compatible with Unix’s design.

2: it’s tied to systemd.

If we have a problem, why not do we create a universal solution for it? Because all things related to systemd are not about fix user’s problems, it’s about create “solutions” for Redhat’s corporate clients. It doesn’t matter if people find an use case for it or if the technology is interesting, it’s all about corporate interests.

@bluefish
banned
12M

i am enjoying my mx linux (ubuntu/debian with sysv init). to me, he seems reinvent wheel something about init, which fragment linux world systemmatically.

also enjoying in artix

@brombek
22M

For me this looks like he is trying to work around fundamentally broken model of ACLs written to file system that UNIX uses. The only way to get this right and not have mountains of complexity is to use object-capability system instead of ACL; but this would not be UNIX anymore.

Also the idea of erasing your LUKS key is kinda pointless since your RAM will also contain most of your recently opened files in page cache - so if you can read your LUKS key from RAM you can also read some of your files from RAM. If you want your files to be really secure just shut down the computer or suspend to disk (“hibernate”) with encryption of the suspend file - this would be no different for what he proposes (since no user program can run anyway) and also better for CO2 emissions…

@federico3
22M

Not at all. File access control in UNIX works just fine, but no kernel-based access control can protect all user homes against a successful privilege escalation. Encryption, instead, does.

The idea that erasing keys is pointless is also incorrect: it’s possible to implement proper scrubbing of keys and caches in RAM, and also CPU registers, CPU caches and so on. Once the sensitive content is wiped the kernel can be compromised by an attacker but the data will not be immediately at risk.

@brombek
12M

What I am saying is that if you have access to RAM (e.g. via https://en.wikipedia.org/wiki/IEEE_1394#Security_issues or in general https://en.wikipedia.org/wiki/DMA_attack) then not all content of your files is secure unless you “scrub” the entire content of RAM.

So if you were to scrub page cache, loaded programs will still have some or all parts of the files loaded in RAM. E.g. my vim process will have some of my source code loaded. My SSH agent will have my keys loaded in RAM, my browser will have the very text you are reading loaded in RAM.

So scrubbing keys from RAM will protect most of your data but not all of your data - false sense of security. So you better understand that trade-off before using such proposed system. It is still better than having you disk wide open but it will never be perfect.

@federico3
22M

the idea of erasing your LUKS key is kinda pointless … opened files in page cache

So scrubbing keys from RAM will protect most of your data but not all of your data

Now you are shifting the goalposts.

This is not a design flaw in LUKS or in ACLs. Applications can be closed, the SSH agent can scrub its memory and so on.

@brombek
02M

OK, it is not pointless entirely (you are still protecting the files that are not in RAM), but it is not perfect; so if you believe it is perfect and you get you secrets “stolen” (e.g. browser TLS encryption keys, your password manager content, tor keys, GPG agent, Signal, Telegram… there is just so much that would need to cooperate with this system) and you get arrested that would not be good for you. My worry here is that it may be misleading and if a system were to be implemented and used there needs to be a warning that this is the case.

So if the goal was to ensure ALL your data is safe when you lock your screen this is clearly not achievable this way.

This is not LUSK flaw - LUKS is a disk encryption system and not RAM encryption/scrubbing. So it does cover you disk if you scrub the key, works as designed. But disk is not the only place your data lives when your system is running.

If you were to close you apps the content of memory may not be zeroed (I think Linux keeps a pool of zeroed memory pages to give to processes when they ask for more memory but I am not sure it zeroes it all the moment it is returned (process terminated)). Also if you need to close you app then what is the point of this? Would it not be better to just shut it down and be sure nothing is left unencrypted?

The comment about ACL is not related to the issue of security. It is just noticing how ACL system actively goes against this sort of use case and how its features need to be worked around to get this working. Also noticing that Lennart wants it to work like an object-capability system instead. And this is fine, it can be solved and I would like to see more object-capability based security in Linux.

@sgtnasty
12M

Maybe it is time to move away from UNIX, just a thought. UNIX/POSIX never had technologies like portable storage and encrypted drives when it was first created if I am not mistaken. Also the needs of encryption and security were very different back in the old card-punch days (which is where I started).

@brombek
12M

Yes, this is what I start to realize. I think sooner we understand the fundamental design flaws of UNIX (arguably ACLs being one of them in this particular scenario) the sooner we can move on to something better.

E.g. see http://erights.org/ or even Plan9 dose this capability based security (via P9 protocol) to some extent and it was designed to use remote home directory from day-1.

If you watched the video in this post you can see that:

  • the UNIX file permissions (owner and group in particular) are in the way of this scenario - as Lennart says it would be best if mount could just override this values stored with each file; otherwise you need to chown -R the whole directory
  • he then also says that even having a user name is problematic as it may conflict (he says that adding a domain to disambiguate the names globally may help but won’t solve the issue)
  • fundamentally you don’t even need the user name (login name) in the first place as the fact that you are capable of decrypting the content of your home folder is enough

So this are all fundamentals of ACL system that goes against this use-case. So I would argue that instead of hacking around this fundamental design making something that will be very complex, insecure and not doing exactly what we want we should either accept Linux as what it is or move on to something that supports this use-cases. I don’t think you can “migrate” Linux out of ACL model.

@brombek
12M

Or maybe what Lennart is doing is the only way for Linux to evolve:

  1. badly hack around existing system to get the features that you want,
  2. get people to realize that this features are in fact needed,
  3. try to reduce hacks later by redesigning system around this new features until you land with better overall system design.
@otso
12M

Someone correct me if my reasoning is flawed but I’ve heard about this before and it strikes me as a sort of [standards - xkcd]. Configurations have specific places already, they just aren’t followed. Configurations go in /etc, no /usr/etc, no $HOME/.*, no $HOME/.config/. The problem is always that people want to use non-conforming utilities, so I feel like the only way to make this work is to write a suite of conforming utilities, but at that point, there’s nothing wrong with just using one of the existing standards.

@federico3
22M

“/etc” is obviously not useful to user configuration. “$HOME/.config” etc are simply not granular enough. Did you watch the video?

@otso
12M

I guess perhaps the difference is one of priorities. In my mind the power of UNIX is the power of the user to control their system, or in multi-user systems the power of the admin to control the system they manage. I don’t have a problem with /etc being writeable and I think configuration should take place in /etc. If I want to set doas permissions, or define who can access my system I should do that from /etc.

@brombek
12M

It looks like he wants to reinvent PAM (that basically all Linux distros are already using):

https://mirrors.edge.kernel.org/pub/linux/libs/pam/FAQ

Q0: What exactly is PAM?

PAM = Pluggable Authentication Modules

Basically, it is a flexible mechanism for authenticating users.

Since the beginnings of UNIX, authenticating a user has been accomplished via the user entering a password and the system checking if the entered password corresponds to the encrypted official password that is stored in /etc/passwd . The idea being that the user is really that user if and only if they can correctly enter their secret password.

That was in the beginning. Since then, a number of new ways of authenticating users have become popular. Including more complicated replacements for the /etc/passwd file, and hardware devices Smart cards etc…

The problem is that each time a new authentication scheme is developed, it requires all the necessary programs (login, ftpd etc…) to be rewritten to support it.

PAM provides a way to develop programs that are independent of authentication scheme. These programs need “authentication modules” to be attatched to them at run-time in order to work. Which authentication module is to be attatched is dependent upon the local system setup and is at the discretion of the local system administrator.

Brian
creator
12M

As the article points out, that is not the only problem that Lennart is looking to fix with systemd-homed. The more interesting part of it for me is the stronger encryption and hot-plugged home directories.

@otso
22M

The hot-plug home directory does seem sort of cool, but again that would take near universal adoption for it to be very useful, and you can already set up your personal computers to do that without a new standard. unencrypting with an external device is already possible and easy, but requires people have the external device, and even if the linux OS you use adopts the hot-pluggable home, the public library won’t, nor will the computer lab at your school. at some point, you may be better off with a live-USB os.

Brian
creator
22M

I’m guessing most of the linux distros that use systemd will adopt it once it’s ready for end users. Also, I don’t think you read the article very closely since what Lennart is proposing with regards to encryption is quite different (system vs. user) than what is done today.

@otso
22M

You’re right that it isn’t what is typically done, but my point was that if you really wanted your disk to encrypt and unencrypt on login/logout it shouldn’t be /that/ hard to just add a hook to a login service. You needn’t rework the idea of a home directory, and create yet another configuration paradigm to do it. If that were all he were proposing, I’d be totally onboard.

@disrooter
12M

Sorry, how is this related to the content of the article?

@otso
12M

Isn’t this article about a new proposed standard for linux condifigurations and home directories?

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Community icon by Alpár-Etele Méder, licensed under CC-BY 3.0 Unported