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.

BTW: Google does the same for Andorid (get your data dump and see for yourself) - every application start and stop is recorded, metadata from your e-mail, etc…;

NOT surveillance, this is to help optimize technology use. /s

This is just “telemetry”. We have that in all Windows (including server) for years now… nothing to worry. This is NOT surveillance. /s

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.

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.

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.

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…

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.

• https://developers.yubico.com/yubico-pam/
• https://github.com/google/pam-cryptsetup

Better install whose prayer apps if you don’t want to accidentally get hit with a drone attack :/

The reason for this is that there is currently no good way of doing certificate revocations. OCSP is also used for normal HTTPS connections from browsers and anything else using TLS unless the server supports better and newer mechanism called OCSP stapling. In case of app developer certificate verification this mechanism cannot be used since there is no TLS connection established in the first place.

So currently with any kind of code signing with certificates the only way to support revocation is OCSP calls back to the certificate authority. Revocation is important as it allows Apple to revoke the certificate in case the developer went rogue and started pushing ransomware.

With Linux distros this is not an issue since package maintainers for most distros sign the packages with their keys and package managers just verify signatures using public keys - to revoke the signature you need to remove the public key from package manager manually. So in other words there is no automatic revocation mechanism but you only trust a small group of people that package all the software for you.

You have to choose wisely where you put your labor in. If you put it in some “cloud” stuff you may one day wake up with it all gone with no way to recover.

When I see people making their living on building YouTube subscribers or Facebook groups this always comes to my mind. Any moment all this work can be gone and you cannot do anything about it. Same apply to software and services that you don’t own (in any meaningful way), at least with some software you can try to get cracked version if something goes wrong.

I don’t get this Ikea comparison. I own my Ikea and nobody can change it or take it away. Software is totally different - you don’t own it (unless it is free as in freedom) and change can be easily forced on you or it can be taken away from you (especially if it is not running on your computer e.g. cloud). So if you put work into it (and this is basically what software is for) you may loose your work any moment or you have to put up with the changes (including licensing and pricing changes).

Next: you allow in-home drones to fly around your place and live stream you all the time to the police.

Ring customers have control and ownership of their devices and videos ,and can choose to allow access as they wish.

Haha, yeah as if we own anything this days or have any control over this services.

So the seed has rooted: https://lemmy.ml/post/41247

https://www.opennic.org/

It was mentioned in Security Now podcast with a comment: “what can potentially go wrong” :D

Well I am pretty sure that this will be the case if it succeeds. Still much better than nothing. Nothing will be stopping you from working on the cores that are open and benefiting from all the software and supporting hardware (motherboards etc.) that will run on it.

Also note that since all this traffic will be going from their servers to other non-Google servers on the internet they will be in position of blocking access to anything they want. Owning DNS and with ability to block by IP they can make it as the site (or any other non-web service) never existed in the first place.

This heralds the day when instead of saying “the Internet” we just going to say “Google”. This is a horrible future.

They just need to make it “on by default” on Android and in Chrome… not to give them ideas :D

I have lost any hope for the web but we must not let the internet as a whole to slip to their hands… our ability to build alternative web (e.g. Gemini) is crucial to escape their power.

RISC-V is going to change computing the way that Linux did. Or at least I hope so :) More please!

I wish I could disagree with Drew but that is how I feel as well. We need new protocols that solve many issues of the web, including simpler presentation, and that are much simpler to implement. Having many capable client implementations is key to keeping the web open and accessible for everyone.

Meanwhile Google continues on their mission to build isolation layer on top of Windows in order to make Microsoft even more irrelevant. This process destroys the web and grants them totalitarian powers over it. One way they do that is by adding more APIs to JS, e.g.: https://wicg.github.io/file-system-access/