Bug 118902 - with selinux enabled, crond can not run user's commands
with selinux enabled, crond can not run user's commands
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
triage|leonardjo|closed|rawhide
: Security, SELinux
Depends On:
Blocks: 122683
  Show dependency treegraph
 
Reported: 2004-03-22 12:05 EST by G.Wolfe Woodbury
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-11 04:18:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description G.Wolfe Woodbury 2004-03-22 12:05:56 EST
Description of problem:
 can't cd to user directory to start command, reports "file or
directory not found"

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


How reproducible:
 consistent

Steps to Reproduce:
1. enable selinux policy 1.9
2. set up a cron job (e.g. SETIatHome)
3.
  
Actual results:
 can't find/change to user directory
 obviously can't run in user context

Expected results:
 run command

Additional info:
Comment 1 Daniel Walsh 2004-03-24 21:34:15 EST
It is working here with the latest policy (1-9-15). If this persists
please send avc messages.
Comment 2 G.Wolfe Woodbury 2004-03-27 03:19:08 EST
Installed with policy1.9-15 and am still having problems.
/var/log/cron:
Mar 26 12:02:03 tembo crontab[1932]: (ggw) REPLACE (ggw)
Mar 26 12:02:10 tembo crontab[1933]: (ggw) LIST (ggw)
Mar 26 12:03:00 tembo crond[1272]: (ggw) ENTRYPOINT FAILED (cron/ggw)
Mar 26 13:01:00 tembo CROND[1970]: (root) CMD (run-parts /etc/cron.hourly)
Mar 26 14:01:00 tembo CROND[1981]: (root) CMD (run-parts /etc/cron.hourly)

should show a cron for setiathome each hour at the 7 minute mark.

Relevant avc:
Mar 26 12:02:03 tembo kernel: audit(1080320523.176:0): avc:  denied  {
search } for  pid=1932 exe=/usr/bin/crontab dev= ino=1
scontext=ggw:staff_r:staff_crontab_t tcontext=system_u:object_r:proc_t
tclass=dir
Mar 26 12:02:10 tembo kernel: audit(1080320530.236:0): avc:  denied  {
search } for  pid=1933 exe=/usr/bin/crontab dev= ino=1
scontext=ggw:staff_r:staff_crontab_t tcontext=system_u:object_r:proc_t
tclass=dir
(no other avc's with cron in the text)
Comment 3 G.Wolfe Woodbury 2004-03-27 03:22:11 EST
ls -Z for /var/spool/cron/ggw:
-rw-r--r--+ root     ggw      ggw:object_r:staff_cron_spool_t  ggw
Comment 4 G.Wolfe Woodbury 2004-04-03 01:57:16 EST
1.9.1 and policy.16 see to have solved this problem, now running ok
under test2
Comment 5 Daniel Walsh 2004-04-03 01:59:43 EST
Please close out the bugs when you verify they are fixed.

Thanks

Dan
Comment 6 G.Wolfe Woodbury 2004-04-03 13:03:38 EST
Need to reopen this one, I was running in permissive mode.
enabling enforcing mode re-kindled the errors
Comment 7 G.Wolfe Woodbury 2004-04-06 20:15:03 EDT
Running in enforcing mode, with policy-1.9.2-12 in enforcing mode,
crond reports:

/bin/sh: line 1: cd: /home/ggw/SETI: No such file or directory

for the following crontab file.  Without enforcing mode on (permissive
or disabled) the commands run normally:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontab.in installed on Sun Apr  4 03:49:11 2004)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#mm hh da mo wk cmd
7   *   *  *  * (cd ~/SETI; ./setiathome -nice 19 > /dev/null 2>
/dev/null)
Comment 8 G.Wolfe Woodbury 2004-04-06 20:19:20 EDT
AVCs for cron at time of failure....

Apr  6 20:07:00 tembo kernel: audit(1081296420.558:0): avc:  denied  {
getattr } for  pid=2118 exe=/bin/bash path=/home dev=hda6 ino=2
scontext=ggw:user_r:user_crond_t
tcontext=system_u:object_r:home_root_t tclass=dir
Apr  6 20:07:00 tembo kernel: audit(1081296420.565:0): avc:  denied  {
search } for  pid=2120 exe=/bin/bash name=ggw dev=hda6 ino=682753
scontext=ggw:user_r:user_crond_t
tcontext=ggw:object_r:staff_home_dir_t tclass=dir
Apr  6 20:07:00 tembo kernel: audit(1081296420.566:0): avc:  denied  {
search } for  pid=2120 exe=/bin/bash name=ggw dev=hda6 ino=682753
scontext=ggw:user_r:user_crond_t
tcontext=ggw:object_r:staff_home_dir_t tclass=dir
Apr  6 20:07:00 tembo kernel: audit(1081296420.567:0): avc:  denied  {
search } for  pid=2120 exe=/bin/bash name=ggw dev=hda6 ino=682753
scontext=ggw:user_r:user_crond_t
tcontext=ggw:object_r:staff_home_dir_t tclass=dir
Comment 9 G.Wolfe Woodbury 2004-04-06 20:23:39 EDT
Additionally...

In enforcing mode, user cannot crontab -l their crontab.  AVC message:

Apr  6 20:19:47 tembo kernel: audit(1081297187.327:0): avc:  denied  {
read } for  pid=2148 exe=/usr/bin/crontab name=ggw dev=hda5 ino=147494
scontext=ggw:sysadm_r:sysadm_crontab_t tcontext=ggw:object_r:file_t
tclass=file
Apr  6 20:19:47 tembo kernel: audit(1081297187.327:0): avc:  denied  {
getattr } for  pid=2148 exe=/usr/bin/crontab path=/var/spool/cron/ggw
dev=hda5 ino=147494 scontext=ggw:sysadm_r:sysadm_crontab_t
tcontext=ggw:object_r:file_t tclass=file
Comment 10 Daniel Walsh 2004-04-06 21:16:12 EDT
In one example you have a user_t trying to run a job on a
staff_home_dir_t?

The next avc messages show crontab trying to access file_t. 

Then you have a file_t trying to be accessed.  Do you have /initrd
mounted?

What is the file context of /var/spool/cron/ggw?



Comment 11 G.Wolfe Woodbury 2004-04-06 22:11:54 EDT
[root@tembo root]# cd /var/spool/cron/
[root@tembo cron]# ll -Za
drwx------+ root     root     system_u:object_r:cron_spool_t   .
drwxr-xr-x  root     root     system_u:object_r:var_spool_t    ..
-rw-------+ root     ggw      ggw:object_r:file_t              ggw
[root@tembo cron]#

I will erase the cron/ggw entry and redo the crontab crontab.in
command from user context to see what changes.

[root@tembo cron]# ll -Za
drwx------+ root     root     system_u:object_r:cron_spool_t   .
drwxr-xr-x  root     root     system_u:object_r:var_spool_t    ..
-rw-------+ root     ggw      ggw:object_r:staff_cron_spool_t  ggw
[root@tembo cron]#


We'll see soon if that fixes the problem.  This may be caused by
having done the crontab before editing
/etc/security/selinux/src/policy/users to make ggw a privleged user.
Comment 12 G.Wolfe Woodbury 2004-04-06 22:21:42 EDT
There are several problems with my user setup now.  SSH is having
problems and can't access ~/.Xauthority again....
 
Going to re-install system from development tree, rebuilding /home.
Should I install ggw as a privleged user in .../policy/users before
adding him with system-config-users?
Comment 13 Daniel Walsh 2004-04-06 22:24:46 EDT
We have done some work with .Xauthority in the lates gdm and policy
files.  You should add the user before putting him in policy.  They
you need to relabel his home dir.

Dan
Comment 14 Leonard den Ottolander 2004-05-11 04:18:31 EDT
With policy 1.11.3-3 I have no problem running user crontabs.

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