From: pebenito@ieee.org (Chris PeBenito) Date: Thu, 20 Apr 2017 18:35:42 -0400 Subject: [refpolicy] [PATCH] user_crontab_t etc In-Reply-To: <201704192116.50569.russell@coker.com.au> References: <20170419102235.2e5egmcyvz4binkz@athena.coker.com.au> <201704192116.50569.russell@coker.com.au> Message-ID: <84a8fa2a-c19d-3d04-acf9-bb1f64d4feef@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 04/19/2017 07:16 AM, Russell Coker via refpolicy wrote: > On Wed, 19 Apr 2017 08:48:01 PM Christian G?ttsche wrote: >> fwiw, I am using a complete rewritten version of cron, where all user >> cronjobs run in the user domain itself. > > My policy does that too. Every cron job runs in the same domain as the > process that ran crontab(1). The only domain specific for running cron jobs is > system_cronjob_t. > >> I think it is more secure and manageable as running all user crontabs >> in a generic crontab_t domain or use sperate $1_cronjob_t ones. >> Another point I dislike about the upstream cron policy is the power of >> system_cronjob_t: I prefer cronjobs to transition into appropriate >> domains for the specific task. > > Sounds good. Let's see if we can find some suitable compromise with Chris and > remove the duplication. >> https://github.com/cgzones/debian-package-refpolicy/blob/management/debian/ >> patches/0403-cron-check-module.patch >> >> 2017-04-19 12:22 GMT+02:00 Russell Coker via refpolicy >> >> : >>> Firstly this patch applies to today's Git tree and is not dependent on >>> the login patch which is still being debated. >>> >>> This patch uses user_crontab_t, sysadm_crontab_t etc domains, as we used >>> to do but which was removed some time in the past. >>> >>> Chris, are you willing to consider restoring this functionality? If not >>> what do you think would be the best way of catering for different needs >>> in this regard? Should I try to make a patch with ifdef >>> role_crontab_domain or something? I think I am mostly fine, conceptually, with the changes, but I'll restate just in case: My preference is to have the default to run cronjobs in the user's domain. While this is not the typical choice (i.e. not the most strict), this is expected behavior for uninitiated users ("my cronjobs can do whatever I can.") I'm definitely open to shrinking system_cronjob_t by doing appropriate transitions. I'd like to keep cronjob_t for advanced users that want to limit cronjobs. Preferably, it would use tunables to switch between cronjobs in userdomains and cronjobs in cronjob_t. Should that not be tenable, we can see what a build option (ifdef) would look like to see if it's not too gnarly to keep. -- Chris PeBenito