From mboxrd@z Thu Jan 1 00:00:00 1970 From: domg472@gmail.com (Dominick Grift) Date: Wed, 02 Feb 2011 15:27:09 +0100 Subject: [refpolicy] Priviledge escalation for the cron job process? In-Reply-To: <4D495EB0.9040309@tresys.com> References: <4D495EB0.9040309@tresys.com> Message-ID: <4D4969BD.9030106@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/2011 02:40 PM, Christopher J. PeBenito wrote: > On 2/1/2011 8:36 AM, HarryCiao wrote: >> Hi all, >> >> 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? > > It doesn't have greater privileges, but as you say, it could. > >> BTW, could we make cron job process in the same domain as the user's >> login shell, as what screen has done? > > It has been discussed several times, and I think it should be doable > with only adding a few rules and updating default contexts. The > original purpose of a separate cronjob domain was to have fewer > privileges than the user's domain. I'm starting to think we should make > this change in refpolicy since the privilege drop of cronjob_t is > unexpected to users; however, I have to think about the exact design. > You can look at both fedora's and my implementation for inspiration if needed. i basically added a new template so that the old can still be used if prefered: http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=blob;f=policy/modules/services/cron.if;h=52f79ac9a37b2c87e913cce7cc10337697a239d4;hb=HEAD starting at line 95 (cron_notrans_role) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Jab0ACgkQMlxVo39jgT/1VQCaA3FjArusFZXcU6Cu8rEs7q1G EZkAn1IbSQ35qvRJfEnFs3Qx3jRjDbI+ =Ok8t -----END PGP SIGNATURE-----