In my SE Linux configuration I have set it up such that only the gpg process may access the files under ~/.gnupg to reduce the risk of a secret key being stolen if a hostile script is accidentally run. However a hostile script could encrypt the secring.gpg file to an output file under /tmp and thus avoid this! I would like to have gpg either check sym-links etc and refuse to open a file under ~/.gnupg as a source for encryption, or have it call a separate process who's sole purpose is to manipulate the secret key file (in which case I can deny the main gpg program direct read access to that file).
On Thu, 9 May 2002 11:56:32 +1000 (EST), russell said: I have not yet looked closely at SE-GNU/Linux so I don't know any details regarding ACL etc. 1.0.7 checks that permissions are sane but this won't help here. Well we could refuse to open a file in ~/.gnupg but is not easy might break existing applications. I wonder whether there is an syscall to help with this. Future version will separate secret key access into a separate process (gpg-agent). Have a look at http:/www.gnupg.org/aegypten/ for some architectural notes. Werner
Werner Koch <wk@gnupg.org> writes: fstat() and compare ft_dev/ft_ino fields with the values for ~/.gnupg/secring.gpg?
Sounds good to me! The way SE Linux works is that there is a security policy determining what access to various objects (files, network connections, etc) each "domain" is given. Each process will be in one of the domains, and the domain can change at exec() time. So if the main gpg process read the secret file by fork()/exec() on a separate program, we could then have a security policy rule stating that the separate program runs in a different domain which has read access to the secret key. Russell Coker
# Automatically generated email from bts, devscripts version 2.10.20 # looks fixed since a 1.3 release, see the --enable-selinux-support configure option tags 146345 + fixed-upstream
It is my believe, that this particular issue has already been fixed upstream some time ago. I'm therefor closing this report now. Please feel free to comment on this decision or reopen the report if necessary. Regards, Daniel
reopen 146345 thanks gpg -c < .gnupg/secring.gpg > out gpg: can't open `[stdin]': Operation not permitted gpg: symmetric encryption of `[stdin]' failed: file open error If built with --enable-selinux-support the above is the expected output. Currently it will just encrypt the secret key. The following patch needs to be applied: diff -ru gnupg-1.4.9.bak/debian/rules gnupg-1.4.9/debian/rules --- gnupg-1.4.9.bak/debian/rules 2008-06-06 11:05:02.000000000 +1000 +++ gnupg-1.4.9/debian/rules 2008-06-06 11:09:45.000000000 +1000 @@ -18,7 +18,7 @@ endif
http://etbe.coker.com.au/2008/06/06/se-linux-support-gpg/ One issue of this feature is that it prevents --export-secret-keys. Determining the correct way of dealing with this will take some time. It might be appropriate to not have this new GPG feature enabled in the case of --export-secret-keys but only apply to operations like "gpg -c --output /tmp/foo.gpg ~/.gnupg/secring.gpg". See my above blog post for some more background data (and probably some comments soon).
retitle 146345 Please build with --enable-selinux-support (restrict access to secring.gpg) thanks Hi, Building gnupg with --enable-selinux-support is probably impossible for Lenny. But we will examine it for Lenny+1. Regards, Daniel
retitle 146345 Please build with --enable-selinux-support (restrict access to secring.gpg) thanks Hi, Building gnupg with --enable-selinux-support is probably impossible for Lenny. But we will examine it for Lenny+1. Regards, Daniel
I'm currently in favor of building separate gnupg packages with SELinux support. This will give us the possibility to test things and help upstream to come to a version, which can enable/disable SELinux support during runtime. See https://bugs.g10code.com/gnupg/msg2499. Regards, Daniel