CentOS 5.4 nfs home directories + cron

CentOS 5.4 nfs home directories + cron

[Tom Boland]

[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.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5.4 nfs home directories + cron

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5.4 nfs home directories + cron

[Tom Boland]

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.

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5.4 nfs home directories + cron

[Stephen Smalley]

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.
> >
> >   
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] CentOS 5.4 nfs home directories + cron

[Stephen Smalley]

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.
> >
> >   
-- 
Stephen Smalley
National Security Agency

Re: CentOS 5.4 nfs home directories + cron

[Tom Boland]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5.4 nfs home directories + cron

[Stephen Smalley]

On Mon, 2009-12-21 at 15:11 +0000, Tom Boland wrote:
> 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.

Any errors in /var/log/cron?
Any AVC messages in /var/log/audit/audit.log or /var/log/messages?

> ================================================================
> 
> 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 };

The above rule should be unnecessary - no files (other than /proc/pid
entries for a process that is running in user_t) should be labeled with
user_t.

> allow crond_t user_t:process { transition };
> allow user_crontab_t user_t:file { getattr read write unlink create lock 
> rename entrypoint };

Likewise.

> allow user_crontab_t user_t:process { transition };

This shouldn't be needed either.
> 
> ================================================================
> 
> 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.

Let's review:
crond_t is transitioning to user_crond_t under the CentOS 5.4 strict
policy but you want it to transition to user_t.  Yes?

So you need to allow the transition on the type pair, which you seem to
have done, and you need to update your default_contexts entry for crond,
which you seem to have done.  But you also likely need to amend the
policy/constraints file in the strict policy.  I'd have to see your
current one - look at your selinux-policy .src.rpm.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] CentOS 5.4 nfs home directories + cron

[Stephen Smalley]

On Mon, 2009-12-21 at 15:11 +0000, Tom Boland wrote:
> 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.

Any errors in /var/log/cron?
Any AVC messages in /var/log/audit/audit.log or /var/log/messages?

> ================================================================
> 
> 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 };

The above rule should be unnecessary - no files (other than /proc/pid
entries for a process that is running in user_t) should be labeled with
user_t.

> allow crond_t user_t:process { transition };
> allow user_crontab_t user_t:file { getattr read write unlink create lock 
> rename entrypoint };

Likewise.

> allow user_crontab_t user_t:process { transition };

This shouldn't be needed either.
> 
> ================================================================
> 
> 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.

Let's review:
crond_t is transitioning to user_crond_t under the CentOS 5.4 strict
policy but you want it to transition to user_t.  Yes?

So you need to allow the transition on the type pair, which you seem to
have done, and you need to update your default_contexts entry for crond,
which you seem to have done.  But you also likely need to amend the
policy/constraints file in the strict policy.  I'd have to see your
current one - look at your selinux-policy .src.rpm.

-- 
Stephen Smalley
National Security Agency