On 9/03/2016, 9:13 PM, "Miroslav Grepl" <mgrepl@xxxxxxxxxx> 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
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
