Hacker News Reader

Comment by sandGorgon | Hacker News Reader

some things need a change to not NEED selinux. For example, lots of password files and certificates should not be stored in directories and files (and mucked about in selinux). They are better off in the Gnome-keyring (which is severely underutilized)

for example - networkmanager-openvpn. Openvpn certfiles are usually shared by vpn providers and then when trying to load them, throws selinux errors.

Here's the bounty to fix it - https://www.bountysource.com/issues/41582244-doesn-t-copy-re...

View on HN

Actually, selinux also limits IPC. So moving things from files to gnome-keyring does not remove the need for selinux, it just changes the selinux policy from (access this object type) to (connect to this process type).

in these cases, it does. I dont have knowledge of selinux for IPC usecases... but in all the cases that I have seen, most of them have been file based access that are being guarded by selinux.

Not that selinux is wrong.. my point is that these files should never have been used in the first place.

Linux keyring is a kernel level infrastructure. However, we still have ssh keyfiles being stored in ~/.ssh . Not sure if I'm right, but it seems to me that openssh wants to be cross platform friendly. So it doesnt play with linuxism very well.

Interesting. I'm surprised I haven't read more about the Linux kernel keyring infrastructure. Are you sure that portable openssh ssh-agent doesn't implement access to it?

in a few distros, they hack it together using "ssh agent" . You can read about it here - https://wiki.gnome.org/Projects/GnomeKeyring/Ssh

AFAIK - its the same story on OSX. I dont begrudge openssh - I'm not sure how it would work with multiple systems, but I dont know if it was ever a priority.

But in this day and age of a "reloaded" Lavabit... these are infrastructure decisions that must be solved !

Interestingly, for all the hate that Lennart gets, he refused to implement "systemd-keyring" and suggested people should use the kernel level keyring service that already exists [1]. You can test it out using "keyctl". Remember however, that IMHO kernel keys do not persist across powercycles.. There is some kind of funky interplay between ecryptfs, kernel keyring and gnome-keyring that I dont completely understand (and is the basis of encrypted home directory in Linux)

[1] https://lists.freedesktop.org/archives/systemd-devel/2014-Ju...

Gnome-Keyring does not use the kernel keyring facility (correct me if I'm wrong).

It also doesn't limit access in any way. Anyone who can connect to the keyring socket gets access to everything. How is this better than storing it in files?

> Anyone who can connect to the keyring socket gets access to everything. How is this better than storing it in files?

That is not something im personally qualified to answer. However, ypu should ask that question of selinux.

Assuming something like selinux makes sense, and gnome-keyring is protected by selinux.. my point is to use builtin infrastructure.

Well, SELinux can differentiate between different subjects whereas gnome-keyring cannot.

Fedora's default policy prevents openvpn from accessing your SSH keys.

You are misunderstanding user screen fatigue. This [1] is the error message spit out by openvpn when it asks you to restorecon on your cert directory - https://bugzilla.gnome.org/show_bug.cgi?id=689818#c3

It is NOT asking you to do some specific openvpn restricted setting. Its basically setting it to the same permission level as gnome-keyring. Except - not even password protected. And the biggest issue - obviously an end-user has to muck about this stuff.

You're misunderstand what SELinux does with OpenVPN.

OpenVPN runs confined, so the only thing it's allowed to access in your profile directory is the certificate files.

The OpenVPN SELinux policy says "OpenVPN may only access files marked home_cert_t".

With gnome-keyring, it would have access to all your secrets.

Gnome-keyring is a poorly documented, DE specific solution that will rope in libdbus abnd a dbus service as dependencies. There are few circumstances where gnome-keyring is the answer.

My big complaint with gnome-keyring is that it took over (replaced) GPG agent functionality but didn't bother implementing all of it (it doesn't support smart cards, for example).

> Gnome-keyring is a poorly documented, DE specific solution

It hasn't been GNOME-specific for around 5 years.

Quoting https://wiki.gnome.org/Projects/Libsecret:

"libsecret is a library for storing and retrieving passwords and other secrets. It communicates with the "Secret Service" using DBus. gnome-keyring and ksecretservice are both implementations of a Secret Service.

libsecret replaces libgnome-keyring."

I didn't say gnome specific, I said DE specific. There's only two implementations and both of them can only be trusted to work correctly if you run them in combination with their respective desktop environment.

Reply on news.ycombinator.com