> Date: Tue, 1 Feb 2011 10:44:57 -0500
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss.tresys.com
> Subject: Re: cron patches and remaining questions
>
> On 01/31/11 06:20, HarryCiao wrote:
> > Hi Chris and all,
> >
> > I've run into some cron issues and come up with the attached 3 patches,
> > so far I am new to cron and cron.pp so it's likely there is a better way
> > to fix the problems, any comments are greatly welcomed!
> >
> > Aslo there are a few cron problems that have not been fixed after
> > applying these 3 patches:
> >
> > 1. on creation of /var/log/cron.log, its label is still var_log_t, the
> > type_transition rule still not take effect;
>
> I don't think cron itself is doing the logging. I think syslog is. At
> least that is how it works on my Gentoo and Rawhide machines. In light
> of this, we should look at the crond that we support (vixie cron and
> fcron are the only ones that I know of) and see if they can be
> configured to have their own log files anymore. If not, we can drop
> cron_log_t. Otherwise we should not change the logging.
>
> In light of this, the first patch is inappropriate for now. At a
> minimum, the MLS sensitivity is wrong, since crond does not run at
> system high.
>
> > 2. on creation of /var/spool/cron/root by the crontab command, its label
> > is still cron_spool_t, the type_transition rule still not take effect;
>
> I'd have to do some looking into this; its not clear to me why this
> doesn't work.
>
> Patch 2 doesn't work right because we don't want to reset the seuser
> portion of the context, as that would break UBAC systems. We could
> consider trying out some genhomedircon lines since it knows the Linux
> user names and associated seuser and we know the naming scheme of the
> cron spool files.
>
> > 3. if pam_loginuid.so is used for the session phase in crond's PAM
> > config file, then there will be PAM related issues:
> >
> > [root/sysadm_r/s0 at qemu-client ~]# grep pam_loginuid /etc/pam.d/crond
> > session required pam_loginuid.so
> > [root/sysadm_r/s0 at qemu-client ~]#
> >
> > Jan 31 09:30:01 QtCao crond[818]: Cannot make/remove an entry for the
> > specified session
> > Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: failed to open PAM
> > security session: Unknown error 4294967292
> > Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: cannot set security
> > context
> > and the related audit messages are:
> > time->Fri Jan 28 05:30:02 2011
> > type=USER_START msg=audit(1296192602.112:2919): user pid=2652 uid=0
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_open
> > acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron
> > res=failed)'
> > ----
> > time->Fri Jan 28 05:30:02 2011
> > type=USER_END msg=audit(1296192602.124:2920): user pid=2652 uid=0
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_close
> > acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron
> > res=failed)'
> >
> > How to debug this crond PAM issue?
>
> I don't see any SELinux audit messages. You could try adding
> logging_set_loginuid(crond_t), which you'll need from a SELinux policy
> perspective, but there may be non-SELinux reasons it doesn't work.
>
> I have merged the third patch.
>
Many thanks for your reply, Chirs!
I will take more time on your comments on the 2nd patch. As for the 3rd one, I still have one more question.
I have been puzzled by the question of how the cron job process domain has been decided. In vixie-cron-4.1, the crond gets the seuser name for the user of the pending crontab command by the getseuserbyname() function, then gets the context for the cron job process by the get_default_context_with_level() function, which in turn will read the contexts/users/[user] and contexts/default_contexts files.
The getdefaultcon command could serve the same purpose:
[root/sysadm_r/s0 at qemu-client contexts]# getdefaultcon staff_u system_u:system_r:crond_t:s0
staff_u:staff_r:cronjob_t:s0
[root/sysadm_r/s0 at qemu-client contexts]# getdefaultcon user_u system_u:system_r:crond_t:s0
user_u:user_r:cronjob_t:s0
[root/sysadm_r/s0 at qemu-client contexts]#
As we can see, staff_u/user_u's cron job process would be in cronjob_t domain, different than their contexts of staff_t/user_t, I am not sure, but it's possible that cronjob_t could have more priviledges than staff_t/user_t, which seems to be not desirable priviledge escalation. Is this correct?
BTW, could we make cron job process in the same domain as the user's login shell, by changing users/[user] files, say "staff_r:cronjob_t:s0" -> "staff_r:staff_t:s0" ? Would this make sense?
Thanks!
Best regards,
Harry
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110202/0207938c/attachment.html