Bug 556276 - gpg used via cron cannot read/write in /root/.gnupg or /var
Summary: gpg used via cron cannot read/write in /root/.gnupg or /var
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-17 15:44 UTC by Peter Verthez
Modified: 2012-12-14 14:37 UTC (History)
1 user (show)

Fixed In Version: 3.6.32-78.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-02 01:23:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
avc messages extracted from /var/log/messages (2.69 KB, application/octet-stream)
2010-01-17 15:44 UTC, Peter Verthez
no flags Details

Description Peter Verthez 2010-01-17 15:44:32 UTC
Created attachment 384929 [details]
avc messages extracted from /var/log/messages

Description of problem:

gpg cannot read/write files (as root) in /root/.gnupg or /var when used in a script started by a cron job.

I have a backup script of my own that creates some tar files in /var/backup, after which I'm using gpg to encrypt them (and then later write them to an external disk).  

When this backup script is run by root on the command line, everything is running fine, but when this backup script is run as a cron job as root (via /etc/cron.d), gpg cannot access any files in /root/.gnupg or /var/backup.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.6.32-66.fc12.noarch

How reproducible:

Always

Steps to Reproduce:
1. make a script that uses gpg to encrypt something in /var
2. add it as cron job
3. wait for the cron job to fire
  
Actual results:

gpg gets "Permission denied" errors.

Expected results:

gpg should succeed in encrypting the file in /var

Additional info:

The test script I was using is the following:

id > /tmp/testcron
cd /var/backup
/usr/bin/gpg -q -c --no-options --no-tty --cipher-algo AES --passphrase-file tmpfile etc.tgz

and it is started in /etc/cron.d as follows (I've put it to be run every 5 minutes, to be able to test and improve...):

*/5 * * * *     root    /root/testcron

When the script is run on the command line, the /tmp/testcron file contains the following id (written by the first line in the script):
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

When the script is run from the cron job, /tmp/testcron contains the following:
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023

The only difference is the selinux security context. 

I know the basics of selinux, but I wasn't able to understand why it didn't work as cron job, but by experimenting with audit2allow, I found that I could fix the problems by using the following module:

module mygpg 1.0;

require {
	type admin_home_t;
	type var_t;
	type gpg_t;
	class file { read lock create write getattr open };
	class dir { write search add_name };
}

#============= gpg_t ==============

allow gpg_t admin_home_t:dir search;
allow gpg_t admin_home_t:file { read lock write open };
allow gpg_t var_t:dir { write add_name };
allow gpg_t var_t:file { read write getattr open create };


Is there a reason why this is not in the selinux-policy-targeted?   

It's also not clear to me why this gives a problem in a cron job, since the changes I made have nothing to do with cron...   As a side note, is there a tool that allows to trace selinux transitions on something that works (audit only shows problems...), to see how it is supposed to go?

I'm attaching the AVC messages that I extracted from /var/log/messages to this bug report (note that some of these are only visible when dontallow is disabled).

Comment 1 Daniel Walsh 2010-01-18 20:47:28 UTC
First gpg writing to a file in /root/.gpg

chcon -t gpg_secret_t /root/.gnupg 

Should fix

I am adding

/root/\.gnupg(/.+)?		gen_context(system_u:object_r:gpg_secret_t,s0)

If you want to examine policy you can use sesearch

 sesearch -A -t gpg_t -p transition
Found 5 semantic av rules:
   allow crond_t gpg_t : process transition ; 
   allow staff_usertype gpg_t : process { transition sigkill sigstop signull signal getattr } ; 
   allow sysadm_usertype gpg_t : process { transition sigkill sigstop signull signal getattr } ; 
   allow user_usertype gpg_t : process { transition sigkill sigstop signull signal getattr } ; 
   allow system_cronjob_t gpg_t : process transition ; 

Which shows which domains transition to gpg_t

Looks like confined users and the system_cronjob_t.  Which is causing you the problems.  Unconfined_t does not transition, which is why the script works when you run it normally.  We could eliminate the transition from system_cronjob_t which would leave you in that domain. 

These are the types that gpg_t can currently write, outside of user files.

sesearch -A -s gpg_t -c file -p create -C | grep -v home | grep -v user
Found 7 semantic av rules:
   allow gpg_t etc_mail_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow gpg_t gpg_secret_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow gpg_t gpg_agent_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 

I think we should remove the transition, if you want to get this to work in enforcing mode for now, you can add your local policy module or change the labels of your backup directory to gpg_agent_tmp_t.

Comment 2 Miroslav Grepl 2010-01-20 15:57:22 UTC
Fixed in selinux-policy-3.6.32-74.fc12.noarch

Comment 3 Fedora Update System 2010-01-28 09:24:26 UTC
selinux-policy-3.6.32-78.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-78.fc12

Comment 4 Fedora Update System 2010-01-29 03:29:38 UTC
selinux-policy-3.6.32-78.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1207

Comment 5 Fedora Update System 2010-02-02 01:21:44 UTC
selinux-policy-3.6.32-78.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Mitchell van Gerwen 2012-12-14 14:37:27 UTC
hello, I am have the same problem. I am using CentOS 6.3 64 bit. The installed version of selinux-policy is 3.7.19-155.el6_3.8.noarch. Selinux is disabled onmy server.

Have someone a solution for my problem?

Thanks in advance,

Mitchell


Note You need to log in before you can comment on or make changes to this bug.