AW: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context"

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harald Beugler-Bell wrote:
> I got a similar problem when trying to run cron as root. It looks like selinux is unable to get the correct user context of the crond process
> 
> crond[5587]: (*system*) NULL security context for user ()
> crond[5587]: CRON (root) ERROR: failed to change SELinux context
> crond[5587]: CRON (root) ERROR: cannot set security context
> 
> The file context of the cron file is set according to default context:
> $ ls -lZ /etc/cron.d/testing-cron
> -rw-r--r--  root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron
> 
> $ ps -efZ | grep crond
> staff_u:system_r:crond_t:s0     root     14922     1  0 00:19 ?        00:00:00 /usr/sbin/crond start
> 
> $ /usr/sbin/semanage login -l | egrep "root|system"
> 
> root                      root                      s0-s0:c0.c1023
> 
> system_u                  system_u                  s0-s0:c0.c1023
> 
> bash-3.1# cat /etc/redhat-release
> 
> Red Hat Enterprise Linux Server release 5 (Tikanga)
> vixie-cron-4.1-66.1.el5
> libselinux-1.33.4-2.el5
> libselinux-python-1.33.4-2.el5
> selinux-policy-strict-2.4.6-79.el5
> selinux-policy-2.4.6-79.el5
> 
> any help is welcome.
> 
> thanks
> Hari
> 
> ----- Ursprüngliche Mail ----
> Von: Aleksander Adamowski <aleksander.adamowski.fedora at altkom.pl>
> An: fedora-selinux-list at redhat.com
> Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr
> Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context"
> 
> Stephen Smalley pisze:
>> On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote:
>>   
>>> crond[27249]: (apache) Unauthorized SELinux context, but SELinux in 
>>> permissive mode, continuing (cron/apache)
>>> crond[29358]: (apache) NULL security context for user, but SELinux
>  in 
>>> permissive mode, continuing ()
>>>     
>> Sounds like it just stayed in crond's context since it failed the
>  check
>> and the system was permissive.  Naturally, in enforcing mode, it
>  would
>> have not executed the job at all.
>>
>> crond computes a context for the user's cron job in the usual manner,
>> then applies a entrypoint permission check between that context and
>  the
>> file context on the crontab file (which gets picked up from a
>> combination of its creator and the parent directory).  If that check
>> fails, then crond refuses to execute the crontab commands in that
>> process context.  The check is intended to prevent injection of
>  commands
>> from one context into another via crontab, unless authorized by
>  policy
>> of course.
>>   
> That's reasonable.
>> I'd have expected it to try to run the cron job in user_u:user_r:
>> user_crond_t:s0 since apache wouldn't have a specific entry in
>  seusers.
>> So it would have wanted the crontab file to have user_cron_spool_t on
>> it, which would have happened if a user_t process created it.  If
>> instead an admin created it and it got sysadm_cron_spool_t or
>> staff_cron_spool_t, that might explain it.  So you could relabel it
>  or
>> allow that permission.  First though check the current label on the
>> crontab file.
>>   
> Yes, you're right. That was precisely the cause.
> I've used "crontab -e -u apache" as root.
> The files in /var/spool/cron got sysadm_cron_spool_t type (the full 
> context was root:object_r:sysadm_cron_spool_t).
> 
> After running "fixfiles relabel /var/spool/cron/", the apache crontab 
> got system_u:object_r:user_cron_spool_t.
> 
> Now cron runs fine and doesn't log anything suspicious.
> 
> IMHO crontab should be modified to relabel crontab files that are
>  edited 
> using the "-u" option, but this is a question to Dan - should I file a 
> new bug to bugzilla.redhat.com on this?
> 
Please update to the U1 policy.

I think you should be able to get this from RHN or you can grab it off of
http://people.redhat.com/dwalsh/SELinux/RHEL5

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHVCxErlYvE4MpobMRAhI4AKDNDDa5Nmz0D1hzlneVDMwrCoV6jwCfWCwd
lrYMtBD3xAYpoQ8CFlH8sWM=
=H/J2
-----END PGP SIGNATURE-----