Hi there,
I've been battling with this, but don't seem to have much luck. I've
added a default file context for the crontabs in /var/spool/crontab, but
this doesn't seem to be honoured. I've also added rules to allow
crontab to transition to the user_t type, but it's not choosing to do
so. I also get permission denied when attempting to set the context
with the -s option to crontab. I'm really confused about this. Here
are my rules so far.
================================================================
module cronusertr 1.0;
require {
type crond_t;
type user_crontab_t;
type nfs_t;
type user_t;
class file { getattr read write execute unlink create lock
relabelfrom relabelto rename entrypoint };
class dir { add_name remove_name reparent search rmdir };
class process { transition };
};
allow crond_t nfs_t:file {getattr read write execute unlink create lock
relabelfrom relabelto rename entrypoint };
allow crond_t nfs_t:dir { add_name remove_name reparent search rmdir };
allow crond_t user_t:file { getattr read write execute unlink create
lock relabelfrom relabelto rename entrypoint };
allow crond_t user_t:process { transition };
allow user_crontab_t user_t:file { getattr read write unlink create lock
rename entrypoint };
allow user_crontab_t user_t:process { transition };
================================================================
Could someone please let me know if I'm on completely the wrong track?
I think I must be, as I'm getting absolutely nowhere seemingly.
Cheers. Tom.
Stephen Smalley wrote:
On Tue, 2009-12-15 at 16:04 +0000, Tom Boland wrote:
Hi Stephen,
Thanks for the reply, and sorry for the spoon feed request here, but I'm
a bit confused about these contexts. If you're saying that I can have
cron run jobs in the users context with the RHEL5 strict policy, or that
I can emulate this behaviour by adding allow rules?
I've tried altering /etc/selinux/strict/contexts/default_contexts:
system_r:crond_t:s0 user_r:user_crond_t:s0 staff_r:staff_crond_t:s0
sysadm_r:sysadm_crond_t:s0 system_r:system_crond_t:s0
mailman_r:user_crond_t:s0
is now
system_r:crond_t:s0 user_r:user_t:s0 staff_r:staff_crond_t:s0
sysadm_r:sysadm_crond_t:s0 system_r:system_crond_t:s0
mailman_r:user_crond_t:s0
But this seems to be causing labelling problems with crontab -e still
creating the users crontab file in the user_crond_t context. Was I
missing the point of what you were saying here?
I also don't have anything other than root in the contexts/users
folder. All my users are in LDAP, and I'm happy with the way they work
apart from the cron thing.
You will need to add allow rules to your policy to permit the
transitions, as the stock RHEL5 strict policy wouldn't support that.
Also check /var/log/cron for any errors.
Many thanks for any assistance.
Cheers. Tom.
Stephen Smalley wrote:
On Fri, 2009-12-11 at 14:43 +0000, Tom Boland wrote:
[resending to correct address!]
Greetings,
I am investigating using RedHats strict selinux policy. Please accept
my apologies if this isn't the correct place, but I'm hoping someone can
help me clarify one or two things. Basically, crond seems to run, but
when attempting to run a job for an unprivileged user with their home
folder on an NFS partition, pretty much every action that can interact
with the home directory is denied. The users themselves do not have the
same problem via ssh, as I have the 'use_nfs_home_dirs' boolean set to 1:
*cat /selinux/booleans/use_nfs_home_dirs
1 1
*
I'm using the setroubleshoot daemon to try and diagnose the problem in
permissive mode, and I have messages such as this when trying to use a
job that simply touches a file in the users home directory: *
Dec 11 12:21:01 ssh setroubleshoot: SELinux prevented touch from reading
and writing files stored on a NFS filesytem. For complete SELinux
messages. run sealert -l d445d52e-57bb-4ca6-a2ad-48cbd62f7e03
=======
Raw Audit Messages
host=ssh.livedns.co.uk type=AVC msg=audit(1260534061.381:4716): avc:
denied { write } for pid=11342 comm="touch" name="user" dev=0:16
ino=64192517 scontext=user_u:user_r:user_crond_t:s0
tcontext=system_u:object_r:nfs_t:s0 tclass=dir
host=ssh.livedns.co.uk type=AVC msg=audit(1260534061.381:4716): avc:
denied { add_name } for pid=11342 comm="touch" name="afile"
scontext=user_u:user_r:user_crond_t:s0
tcontext=system_u:object_r:nfs_t:s0 tclass=dir
host=ssh.livedns.co.uk type=AVC msg=audit(1260534061.381:4716): avc:
denied { create } for pid=11342 comm="touch" name="afile"
scontext=user_u:user_r:user_crond_t:s0 tcontext=user_u:object_r:nfs_t:s0
tclass=file
host=ssh.livedns.co.uk type=SYSCALL msg=audit(1260534061.381:4716):
arch=c000003e syscall=2 success=yes exit=0 a0=7fffa80e7f0a a1=941 a2=1b6
a3=3d0d35210c items=2 ppid=11341 pid=11342 auid=217858 uid=217858
gid=500 euid=217858 suid=217858 fsuid=217858 egid=500 sgid=500 fsgid=500
tty=(none) ses=1129 comm="touch" exe="/bin/touch"
subj=user_u:user_r:user_crond_t:s0 key=(null)
host=ssh.livedns.co.uk type=CWD msg=audit(1260534061.381:4716):
cwd="/home/fhlinux142/e/eschelon.co.uk/user"
host=ssh.livedns.co.uk type=PATH msg=audit(1260534061.381:4716): item=0
name="/home/webserver/site/user/" inode=64192517 dev=00:16 mode=040701
ouid=217858 ogid=500 rdev=00:00 obj=system_u:object_r:nfs_t:s0
host=ssh.livedns.co.uk type=PATH msg=audit(1260534061.381:4716): item=1
name="**/home/webserver/site/user/**afile" inode=64194402 dev=00:16
mode=0100644 ouid=217858 ogid=500 rdev=00:00 obj=system_u:object_r:nfs_t:s0*
I haven't pasted everything from sealert, i thought the raw logs would
be enough. I've used audit2allow to get a basic skeletal policy for
crond+nfs and added a bit to it, which is like:
*module crondreadnfs 1.0;
require {
type user_crond_t;
type nfs_t;
class dir { read write add_name create getattr search };
class file { read write create getattr };
}
require {
type crond_t;
type nfs_t;
class dir { read write add_name create getattr search };
class file { read write create getattr };
}
#============= user_crond_t ==============
allow user_crond_t nfs_t:dir { read write add_name create getattr search };
allow user_crond_t nfs_t:file { read write create getattr };
allow crond_t nfs_t:dir {read write add_name create getattr search };
allow crond_t nfs_t:file { read write create getattr };
*
But I'm actually a bit confused as to why it's necessary. I thought
cron would be running jobs _as_ the user, and under the users context?
Is there something else wrong? SSH is fine with the use_nfs_home_dirs
boolean, so why not cron? If there's a way for this to work without
having to explicitly allow every single operation that cron is allowed
to attempt, and to just run jobs with the access that the user who's
cronjob it is has, I would be most appreciative!!
Many thanks. Tom.
See http://marc.info/?l=selinux&m=121094043113003&w=2
That has subsequently changed since RHEL5 so that user cron jobs just
run in the user's own domain, I believe. But you could change your
policy likewise if that is the behavior you want.
Modify the system_r:crond_t:s0 entry in
your /etc/selinux/targeted/contexts/default_contexts file and in
your /etc/selinux/targeted/contexts/users/* files, and add allow rules
as needed.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
