[refpolicy] Priviledge escalation for the cron job process?

[cpebenito@tresys.com (Christopher J. PeBenito)]

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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com