Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 376271 - vixie-cron fails with SELINUX=enforcing and SELINUXTYPE=strict
Summary: vixie-cron fails with SELINUX=enforcing and SELINUXTYPE=strict
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: AMD64 Linux
: Normal minor (vote)
Assignee: SE Linux Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-24 21:26 UTC by Dave
Modified: 2011-09-23 19:04 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
policy SELinux cron (policy,2.26 KB, text/plain)
2011-07-24 21:35 UTC, Dave
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave 2011-07-24 21:26:56 UTC
After getting informed on the gentoo-hardened mailing-list for adding selinux-base-policy-2.20101213-r21 ("Portage support to allow emerge,
emerge-webrsync, layman etc. to be called from unattended domains like cron") I removed my policy generated by audit2allow in order to run cron jobs on SELINUX=enforcing and SELINUXTYPE=strict. 

But I've had to install my own policy again to get vixie-cron work for running a cron job ("eix-sync") (Attachment).

So this might not a bug. But it's hard for me to argue regarding the improvement of selinux-base-policy-2.20101213-r21 when I've had to activate my own policy again.





Reproducible: Always

Steps to Reproduce:
1. running cron jobs in /etc/crontabs
2. SELINUX=enforcing and SELINUXTYPE=strict
3.
Actual Results:  
Running cron job ("eix-sync") fails. 

Expected Results:  
cron job for "eix-sync" working properly with SELINUX=enforcing and SELINUXTYPE=strict.
Comment 1 Dave 2011-07-24 21:35:23 UTC
Created attachment 280871 [details]
policy SELinux cron
Comment 2 Dave 2011-07-24 21:50:34 UTC
should have been /etc/crontab
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2011-08-12 22:17:18 UTC
Hi Dave

Would it be possible to tell us what the errors were that you got (either through cron or indirectly) and which denials were triggered?

System cronjobs (system_cronjob_t) shouldn't call user scripts, that's what the user cronjobs are for (cronjob_t).

Otoh, we know our policy will not handle all possible cases, so having your own updates on the policy locally is not something unexpected.