Linux

56862 readers

618 users here now

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.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

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

founded 6 years ago

MODERATORS

AgreeableLandscape@lemmy.ml

nooter692@lemmy.ml

MarcellusDrum@lemmy.ml

cypherpunks@lemmy.ml

cyclohexane@lemmy.ml

d3Xt3r@lemmy.nz

Protecting against rogue devices with Full Disk Encryption and TPM (news.opensuse.org)

submitted 1 week ago* (last edited 1 week ago) by that_leaflet@lemmy.world to c/linux@lemmy.ml

18 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] 9tr6gyp3@lemmy.world 3 points 1 week ago (1 children)

I believe thats how Android works. As I recall, it uses fscrypt.

[–] FauxLiving@lemmy.world 1 points 1 week ago (1 children)

Yeah, it sounds like something you could do with SE linux and some scripting to handle mounting the user's filesystem as needed.

[–] sxan@midwest.social 2 points 1 week ago

Ok, I went and read some more about it, and you can manage keys with the kernel user session keyring. So it's possible.

It brought me back around to why systemd is so shitty.

Session Keyring (Rejected)

This strategy involves placing all keys for fscrypt in KEY_SPEC_SESSION_KEYRING. Using the current session keyring means that fscrypt will not need elevated privileges to place keys in this keyring, eliminating the need for a setuid binary. It also means that if something like pam_keyinit is used, the keys will be inherited across things like sudo.

However, this strategy has a few significant downsides that led to it not being used. The first issue is that keys unlocked in one session for a user are (sometimes) not accessible to the user in other sessions. This can create confusion for users unable to access certain directories. However, the bigger problem is that systemd is incompatible with use of the system keyring. The systemd maintainers are of the reasonable position that the session keyring just shouldn’t be used.

fscrypt

Emphasis mine. Because the user session keyring is incompatible with systemd, the Poetterites say it shouldn't be used.

The only way to handle keys securely Ok base Linux shouldn't be used because it's incompatible with systemd. What a way to see the world: so convinced in the superiority of your monolithic monster system that you argue against an immediately available way of improving security.

It's incompatible, by the way, because systemd doesn't run user jobs in the user's session, but in parallel sessions. This means that, if you use systemd, you can't use the most secure way of handling secrets with fscrypt, the kernel user session keyring.