Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 440162 - =sec-policy/selinux-*-9999 needs allowance for fcron to unlink /var/spool/cron/lastrun/lock
Summary: =sec-policy/selinux-*-9999 needs allowance for fcron to unlink /var/spool/cro...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: SELinux (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: SE Linux Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-29 19:48 UTC by Alex Brandt (RETIRED)
Modified: 2012-11-01 15:44 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Brandt (RETIRED) gentoo-dev 2012-10-29 19:48:49 UTC
fcron with the current SELinux policies consistently provides the following error:

rm: cannot remove â/var/spool/cron/lastrun/lockâ: Permission denied

It looks like these are due to the following AVCs:

type=PATH msg=audit(1351539000.179:132): item=1 name="/var/spool/cron/lastrun/lock" inode=606356 dev=ca:01 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_spool_t
type=AVC msg=audit(1351539600.049:135): avc:  denied  { read } for  pid=14475 comm="readlink" name="lock" dev="xvda1" ino=606356 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:var_spool_t tclass=lnk_file
type=PATH msg=audit(1351539600.049:135): item=0 name="/var/spool/cron/lastrun/lock" inode=606356 dev=ca:01 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_spool_t
type=AVC msg=audit(1351539600.056:136): avc:  denied  { read } for  pid=14477 comm="cat" name="lock" dev="xvda1" ino=606356 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:var_spool_t tclass=lnk_file
type=AVC msg=audit(1351539600.066:137): avc:  denied  { read } for  pid=14480 comm="readlink" name="lock" dev="xvda1" ino=606356 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:var_spool_t tclass=lnk_file
type=PATH msg=audit(1351539600.066:137): item=0 name="/var/spool/cron/lastrun/lock" inode=606356 dev=ca:01 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_spool_t
type=AVC msg=audit(1351539600.072:138): avc:  denied  { read } for  pid=14482 comm="cat" name="lock" dev="xvda1" ino=606356 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:var_spool_t tclass=lnk_file
type=AVC msg=audit(1351539600.112:139): avc:  denied  { unlink } for  pid=14489 comm="rm" name="lock" dev="xvda1" ino=606356 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:var_spool_t tclass=lnk_file
type=PATH msg=audit(1351539600.112:139): item=1 name="/var/spool/cron/lastrun/lock" inode=606356 dev=ca:01 mode=0120777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_spool_t

I noticed that this symlink is not covered by any filecontexts:

selinux lastrun # semanage fcontext -l | grep '/var/spool/cron'
/var/spool/cron                                    directory          system_u:object_r:cron_spool_t 
/var/spool/cron/[^/]*                              regular file       <<None>>
/var/spool/cron/crontabs                           directory          system_u:object_r:cron_spool_t 
/var/spool/cron/crontabs/.*                        regular file       <<None>>
/var/spool/cron/lastrun                            directory          system_u:object_r:crond_tmp_t 
/var/spool/cron/lastrun/[^/]*                      regular file       <<None>>

Should the regular file requirement on cron_spool_t or crond_tmp_t be relaxed so this inherits permissions that are accessible from fcron?

I'm inclined towards system_cronjob_tmp_t to match the other files in the directory:

selinux lastrun # ls -lZa
total 8
drwxr-x---. 2 root root system_u:object_r:crond_tmp_t          4096 Oct 29 14:40 .
drwxr-x---. 3 root cron system_u:object_r:cron_spool_t         4096 Oct 26 19:36 ..
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t    0 Oct 29 00:04 cron.daily
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t    0 Oct 29 14:00 cron.hourly
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t    0 Oct 26 19:50 cron.monthly
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t    0 Oct 29 00:04 cron.weekly
lrwxrwxrwx. 1 root root system_u:object_r:var_spool_t             5 Oct 29 13:00 lock -> 23480


Reproducible: Always
Comment 1 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-30 20:49:59 UTC
It is very strange that the label is var_spool_t. Was this lockfile perhaps created when the labels were set incorrectly?

Try setting it to crond_tmp_t for now (although I would use system_cronjob_lock_t, but there doesn't seem to be a transition for this type yet) and see if the file eventually gets its label back to var_spool_t.
Comment 2 Alex Brandt (RETIRED) gentoo-dev 2012-10-31 13:48:18 UTC
May have been an ephemeral issue as you pointed out.  I simply removed the lockfile, relabeled the filesystem and cron has been running smoothly since.  I'll bring it back up if it starts acting strange again (perhaps it is only certain jobs that leave it in this state).
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2012-11-01 15:44:40 UTC
Ok, i'll mark it as WORKSFORME for now