Comments on: SE Linux Support in GPG

By: Deron Meranda

Deron Meranda — Thu, 12 Jun 2008 20:18:08 +0000

Why not allow exporting of secret keys to a file; but only as long as the newly created file can be created with the same SELinux context as the secret key ring itself. This would allow secret keys to be exported when needed (without disabling GPG functionality or mandating special password restrictions only when in SELinux mode), but still allow SELinux profiles to maintain control over those exported secret keys, since you’re not allowing data to be copied across different security contexts.

By: etbe

etbe — Sat, 07 Jun 2008 10:33:47 +0000

Werner: If someone seems to be using some underhand method of reading the secret key, then that should be blocked at any time. Without SE Linux the user can use cp to get the secring.gpg file. The defined way of doing this from gpg is –export-secret-keys, having this force the user to encrypt the data would make sense. Allowing no way of exporting unencrypted secret key data makes sense (that would not deny them access as cp still works).

Even without SE Linux it seems to me that there still is the possibility that blocking unusual ways of accessing secret data can do some good.

By: textshell

textshell — Fri, 06 Jun 2008 16:42:32 +0000

I think for exporting the secret keys there should be at least a config option to select permissive (always) or something more restricted.

But i’m not sure if disallowing the user to read his/her own files is a good idea. I’d wish that even with selinux* the user keeps full control over his files and potentially problematic programs (all internet software, etc) would run somehow with a different MAC context that restricts only those. Then gpg would “only” need to find out if the calling context can read the file to check if exporting is allowed.
Is something like that possible with SElinux?

* standard end user configuration for SElinux, obviously the local admin might have reasons to use an other policy and SElinux shouldn’t enforce things like this.

By: Werner Koch

Werner Koch — Fri, 06 Jun 2008 14:58:40 +0000

What about this:

if ( ! is_selinux_enabled () )
disable_all_se_linux_hacks ();
else if ( security_getenforce () != 1 )
allow_secret_key_export ();

My man page for is_selinux_enabled states “May change soon” – what does thins mean?

By: Werner Koch

Werner Koch — Fri, 06 Jun 2008 14:43:23 +0000

Okay, an extra transport key to encrypt keys during export would make sense but I see problem to manage that properly.

The idea to require a passphrase for export actually makes sense. It has been requested for years but I always rejected it with the rationale that it won’t help because the user could just copy the secring.gpg. Of course with SE this is different.

[Typo above; it should be: ... send the private key...]

I created https://bugs.g10code.com/gnupg/issue928 to remember this. I guess you want to have that in Lenny; need to hurry a bit.

By: etbe

etbe — Fri, 06 Jun 2008 11:46:36 +0000

http://www.coker.com.au/selinux/play.html

Werner: security_getenforce(3) is what you want. The above URL has the login details for a test machine, I would be happy to give you your own account (root is shared and random people can rm files etc). If you login at a quiet time (most times) then you could test compiling some code there.

Simon’s idea of requesting the pass-phrase before backing up a key makes sense for some situations. However I can imagine the case where you want cron jobs to decrypt or sign data but don’t want them to be able to send the public key out over the net.

We probably need a configuration option for this.