Bug 735877 - sudo crontab -e -u breaks the crontab file perms
Summary: sudo crontab -e -u breaks the crontab file perms
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 741870 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-06 00:08 UTC by Robin Powell
Modified: 2011-12-04 02:34 UTC (History)
6 users (show)

Fixed In Version: selinux-policy-3.9.16-48.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-04 02:34:50 UTC


Attachments (Terms of Use)

Description Robin Powell 2011-09-06 00:08:06 UTC
Description of problem:

My apologies if this isn't categorized correctly.  Also if it's a duplicate; I tried to search but this is a hard one to come up for search terms for.

Summary kind of covers it; more details below.

Version-Release number of selected component (if applicable):

Name        : cronie
Arch        : x86_64
Version     : 1.4.8
Release     : 2.fc15

How reproducible:

"sudo crontab -e -u [any non-root user]"

Before:

-rw-------. djanatyn root user_u:object_r:user_cron_spool_t:s0 djanatyn

After:


-rw-------. root   root staff_u:object_r:cron_spool_t:s0 djanatyn

Running vim against the spool file directly doesn't have this problem, so it's something in crontab the command.

-Robin

Comment 1 Tomas Mraz 2011-09-06 06:19:41 UTC
Hmm, is this actually a problem? The user can still edit the file due to crontab being setuid and the file is loaded by crond without problems too.

Comment 2 Tomas Mraz 2011-09-06 06:20:40 UTC
And this way you (as root) can also see whether the last edit of the file was done by the user or root.

Comment 3 Marcela Mašláňová 2011-09-12 07:34:58 UTC
As was mentioned in previous comments, is it real problem? Does selinux deny run your jobs?
I suppose change of context is right thing to do if you use sudo.

Comment 4 Robin Powell 2011-09-12 17:17:13 UTC
The jobs run, but the user can no longer do "crontab -e"; it errors out.  They have no perms on their own crontab.  Root has to manually change the context for the user to be able to "crontab -e" again.

-Robin

Comment 5 Robin Powell 2011-09-28 09:03:01 UTC
Better still, restorecon doesn't fix the problem; there doesn't seem to be a context setting for /var/spool/cron at all.  It has to be a chcon, i.e.:

sudo chcon -t user_cron_spool_t /var/spool/cron/rlpowell

or similar.

Until that is done, the user can't "crontab -e" *and* the cron itself doesn't run.

This is true for all non-root users.  Both "sudo -u [user] crontab -e" and "sudo crontab -e -u [user]" cause it.

I'm not sure how to copy the selinux-policy people on this, but it might be worthwhile.  Maybe dwalsh, at least.

-Robin

Comment 6 Dominick Grift 2011-09-28 10:35:38 UTC
Seems sysadm does not call cron_role() and so crontab may be run in the sysadm_t domain causing the file to inherit the type of the parent dir.

I do not know what exactly the best solution is but i guess either call cron_role() for sysadm_t (like its called for unprivileged user domains) or just allow sysadm_t to file type transition on cron_spool_t dirs to user_cron_spool_t files.

Either:

cron_role(sysadm_r, sysadm_t)

or:

filetrans_pattern(sysadm_t, cron_spool_t, user_cron_spool_t, file)

Disclaimer; I might be way off here. Just looking at the cron policy module gives me a headache (j/k).

Comment 7 Dominick Grift 2011-09-28 10:38:54 UTC
actually i mean cron_admin_role(sysadm_r, sysadm_t)

Comment 8 Daniel Walsh 2011-09-28 15:04:24 UTC
We should activate

optional_policy(`
	cron_admin_role(sysadm_r, sysadm_t)
')

This should be back ported to RHEL6.

Comment 9 Daniel Walsh 2011-09-28 15:05:32 UTC
*** Bug 741870 has been marked as a duplicate of this bug. ***

Comment 10 Dominick Grift 2011-09-28 15:55:53 UTC
Robin could you try this out please?:

mkdir ~/mytest; cd ~/mytest;
echo "policy_module(mytest, 1.0.0) optional_policy(\` gen_require(\` type sysadm_t; role sysadm_r; ') cron_admin_role(sysadm_r, sysadm_t)" > mytest.te

make -f /usr/share/selinux/devel/Makefile mytest.pp
sudo semodule -i mytest.pp

See if that fixes your issue and other functionality.

Comment 11 Dominick Grift 2011-09-28 15:57:33 UTC
Make that:

echo "policy_module(mytest, 1.0.0) optional_policy(\` gen_require(\` type
sysadm_t; role sysadm_r; ') cron_admin_role(sysadm_r, sysadm_t)')" > mytest.te

I forgot to close the optional policy block

Comment 12 Dominick Grift 2011-09-28 17:31:18 UTC
seems that cron_admin_role does fix it for sysadm_t, but Robin tried it as unconfined_t.

I am not sure how that cron_unconfined_role is supposed to work and if it is called but i suspect we just need it to filetrans:

filetrans_pattern(unconfined_t, cron_spool_t, user_cron_spool_t, file)

Comment 13 Daniel Walsh 2011-09-28 19:40:55 UTC
Yes that makes more sense then trying to use a new role.

Comment 14 Robin Powell 2011-09-28 23:36:35 UTC
Will restorecon DTRT with crontabs when you guys are done?

-Robin

Comment 15 Miroslav Grepl 2011-09-29 07:52:38 UTC
Since I will add the file transition rule which means the context should be ok for /var/spool/cron/*.

And we have in the policy

/var/spool/cron/[^/]*       --  <<none>>

which means the restorecon won't be applied on this directory.

Comment 16 Daniel Walsh 2011-09-29 14:17:35 UTC
I am a little concerned about this.  Doesn't cron do some kind of check on the file to decide which context to run the cronjob with, based on the SELinux owner of the file, or does it ask the system what context should dwalsh run as?  It has been a while since I have looked at this code.

Comment 17 Tomas Mraz 2011-09-29 14:44:34 UTC
The context on the file does not affect which context to run cronjob with but it checks whether the chosen context has entrypoint access on the file's context.

Comment 18 Daniel Walsh 2011-09-29 18:08:23 UTC
So is it failing on the entrypoint?

Comment 19 Robin Powell 2011-09-29 18:16:25 UTC
For the record, the log response when this doesn't work is:


Sep 28 11:52:01 stodi /usr/sbin/crond[581]: (rlpowell) Unauthorized SELinux context=staff_u:staff_r:staff_t:s0 file_context=staff_u:object_r:cron_spool_t:s0 (/var/spool/cron/rlpowell)

-Robin

Comment 20 Robin Powell 2011-09-29 18:17:02 UTC
(In reply to comment #15)
> Since I will add the file transition rule which means the context should be ok
> for /var/spool/cron/*.
> 
> And we have in the policy
> 
> /var/spool/cron/[^/]*       --  <<none>>
> 
> which means the restorecon won't be applied on this directory.

I'm still worried about situations where they're created outside of crontab, like restore from backups, but I have no idea what filetrans does :D, so if you say it works, that's fine by me.

-Robin

Comment 21 Daniel Walsh 2011-09-29 18:30:44 UTC
I would doubt it would work when restored from a back up.  If the only files in this directory should be labeled user_cron_spool_t, then we should probably change the label.

Comment 22 Miroslav Grepl 2011-09-30 08:45:05 UTC
Yes, we need user_cron_spool_t label because of

# needs to be authorized SELinux context for cron
allow staff_t user_cron_spool_t : file entrypoint ;
allow user_t user_cron_spool_t : file entrypoint ;


The problem is with sudo

"sudo crontab -e -u [any non-root user]"

since I guess Robin has something like

mgrepl ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL

in the sudoers.


So we have this label

/var/spool/cron         -d  gen_context(system_u:object_r:cron_spool_t,s0)

since it was obviously needed

===
# Type of user crontabs once moved to cron spool.
type user_cron_spool_t, cron_spool_type;
typealias user_cron_spool_t alias { staff_cron_spool_t sysadm_cron_spool_t unconfined_cron_spool_t };
typealias user_cron_spool_t alias { auditadm_cron_spool_t secadm_cron_spool_t };

===

but now I guess we could change the label.

Comment 23 Daniel Walsh 2011-09-30 14:42:42 UTC
I have no problem with that change.  


/var/spool/cron         -d  gen_context(system_u:object_r:user_cron_spool_t,s0)

Comment 24 Miroslav Grepl 2011-10-03 06:40:55 UTC
Fixed in selinux-policy-3.9.16-43.fc15 and in F16.

Comment 25 Fedora Update System 2011-11-16 16:16:45 UTC
selinux-policy-3.9.16-48.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-48.fc15

Comment 26 Fedora Update System 2011-11-17 23:35:07 UTC
Package selinux-policy-3.9.16-48.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-48.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16023/selinux-policy-3.9.16-48.fc15
then log in and leave karma (feedback).

Comment 27 Fedora Update System 2011-12-04 02:34:50 UTC
selinux-policy-3.9.16-48.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


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