Hi list,
We have a client who wants a service account’s crontab to run a ruby script in /var/www; this isn’t permitted by default and I have no idea what this script does but from past experience suspect it will generate an array of misleading AVCs if I go down the route of allowing crontab_t to read httpdcontent attribute (ie. httpd_sys_rw_content_t, etc.) files and directories. Could someone please explain the rationale behind the policy design for user crontab confinement and how I should handle this situation?
Thanks, Doug
On 03/08/2016 03:40 AM, Douglas Brown wrote:
Hi list,
Hi Doug,
We have a client who wants a service account’s crontab to run a ruby script in /var/www; this isn’t permitted by default and I have no idea what this script does
which is important and it is a reason why we confine crontabs. We want to contain possible security issues in crontabs.
but from past experience suspect it will generate an array of misleading AVCs if I go down the route of allowing crontab_t to read httpdcontent attribute (ie. httpd_sys_rw_content_t, etc.) files and directories. Could someone please explain the rationale behind the policy design for user crontab confinement and how I should handle this situation?
What is your OS? What AVC are you getting?
Thanks, Doug
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
On 9/03/2016, 9:13 PM, "Miroslav Grepl" mgrepl@redhat.com wrote:
On 03/08/2016 03:40 AM, Douglas Brown wrote:
Hi list,
Hi Doug,
We have a client who wants a service account’s crontab to run a ruby script in /var/www; this isn’t permitted by default and I have no idea what this script does
which is important and it is a reason why we confine crontabs. We want to contain possible security issues in crontabs.
Definitely, but unlike application domains, the cron domain may hypothetically need to do just about anything. It’s a difficult issue. While I agree it makes sense for the default policy to confine cron in the way it does, I also need to figure out a way to enable our many varied users to use cron unhindered.
There’s two approaches I’m thinking about. The simplest is unconfined_domain(crontab_t) then let posix DAC take care of access controls - simple but undesirable (especially considering this would also apply to users confined with guest_t or similar). The other approach might be something along the lines of allow crontab_t to { manage_file_perms exec_file_perms } of non_security_file_type and add domain transition when crontab_t executes non_security_file_type - but that’s messy and will invariably be insufficient in some cases.
The ideal approach would be for crontab_t to transition to the respective user’s default domain to execute their crontab, but how to do that in practice?
but from past experience suspect it will generate an array of misleading AVCs if I go down the route of allowing crontab_t to read httpdcontent attribute (ie. httpd_sys_rw_content_t, etc.) files and directories. Could someone please explain the rationale behind the policy design for user crontab confinement and how I should handle this situation?
What is your OS?
RHEL 6.7
What AVC are you getting?
None, I’m assuming it hit dontaudit rules. I can turn them off, put the crontab_t domain in permissive, run the cronjob, generate all the AVCs then work towards a local policy, but that approach is unsustainable with a fleet our size.
What do you reckon, crontab_t unconfined, or is there some way to get a user’s crontab to execute in their domain?
Thanks for your help.
Cheers, Doug
On 03/10/2016 01:50 AM, Douglas Brown wrote:
On 9/03/2016, 9:13 PM, "Miroslav Grepl" mgrepl@redhat.com wrote:
On 03/08/2016 03:40 AM, Douglas Brown wrote:
Hi list,
Hi Doug,
We have a client who wants a service account’s crontab to run a ruby script in /var/www; this isn’t permitted by default and I have no idea what this script does
which is important and it is a reason why we confine crontabs. We want to contain possible security issues in crontabs.
Definitely, but unlike application domains, the cron domain may hypothetically need to do just about anything. It’s a difficult issue. While I agree it makes sense for the default policy to confine cron in the way it does, I also need to figure out a way to enable our many varied users to use cron unhindered.
There’s two approaches I’m thinking about. The simplest is unconfined_domain(crontab_t) then let posix DAC take care of access controls - simple but undesirable (especially considering this would also apply to users confined with guest_t or similar). The other approach might be something along the lines of allow crontab_t to { manage_file_perms exec_file_perms } of non_security_file_type and add domain transition when crontab_t executes non_security_file_type - but that’s messy and will invariably be insufficient in some cases.
The ideal approach would be for crontab_t to transition to the respective user’s default domain to execute their crontab, but how to do that in practice?
Would be nice to see AVCs. How are your crontabs labeled? There is a transition from crond_t to unconfined_cronjob_t domain.
but from past experience suspect it will generate an array of misleading AVCs if I go down the route of allowing crontab_t to read httpdcontent attribute (ie. httpd_sys_rw_content_t, etc.) files and directories. Could someone please explain the rationale behind the policy design for user crontab confinement and how I should handle this situation?
What is your OS?
RHEL 6.7
What AVC are you getting?
None, I’m assuming it hit dontaudit rules. I can turn them off, put the crontab_t domain in permissive, run the cronjob, generate all the AVCs then work towards a local policy, but that approach is unsustainable with a fleet our size.
What do you reckon, crontab_t unconfined, or is there some way to get a user’s crontab to execute in their domain?
Thanks for your help.
Cheers, Doug
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
selinux@lists.fedoraproject.org
-
Douglas Brown -
Miroslav Grepl