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?
BTW, could we make cron job process in the same domain as the user's login shell, as what screen has done?
Thanks!
Best regards,
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110201/0b38923a/attachment.html
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
http://www.tresys.com | 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-----