From: harrytaurus2002@hotmail.com (HarryCiao) Date: Wed, 2 Feb 2011 00:54:33 +0000 Subject: [refpolicy] cron patches and remaining questions In-Reply-To: <4D482A79.6030306@tresys.com> References: , <4D482A79.6030306@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > 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 > 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