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@xxxxxxxxx>
An: fedora-selinux-list@xxxxxxxxxx
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?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.org.pl
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
