3 ms·
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks. However, ignoring the aspect of software distribution, wouldn't you agree that t
by abjKT26nO8 6y ago
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks.
However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.
I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?
[1]: https://git.sr.ht/~sircmpwn/himitsu https://git.sr.ht/~sircmpwn/himitsu
- ddevault 6y agoI agree with you, but the solution would have been Plan 9 namespaces, not Linux containers. What we're working towards today is awful.