From: russell@coker.com.au (Russell Coker) Date: Wed, 19 Apr 2017 21:16:50 +1000 Subject: [refpolicy] [PATCH] user_crontab_t etc In-Reply-To: References: <20170419102235.2e5egmcyvz4binkz@athena.coker.com.au> Message-ID: <201704192116.50569.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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? > > > > Index: refpolicy-2.20170417/policy/modules/contrib/cron.if > > -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/