-----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@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? > 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----- -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
