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

[Aleksander Adamowski]

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