From: Chris PeBenito <pebenito@ieee.org>
To: russell@coker.com.au
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH cron 2/2] user_crontab_t etc
Date: Wed, 9 Jan 2019 18:57:45 -0500 [thread overview]
Message-ID: <8f56a5ac-d4d8-ccc4-ca6a-4876ac1e6aeb@ieee.org> (raw)
In-Reply-To: <6320875.l7dpP3Uglz@xev>
On 1/7/19 10:38 PM, Russell Coker wrote:
> On Tuesday, 8 January 2019 10:47:27 AM AEDT Chris PeBenito wrote:
>> On 1/6/19 10:10 PM, Russell Coker wrote:
>>> This patch adds a $1_crontab_t domain and makes it a compile option for
>>
>> What is the goal for reintroducing a crontab domain per-user-domain?
>
> To make it more difficult for a user from one domain to take over access to
> another domain via cron.
>
> The context of the crontab program determines the type of the cron spool file
> which then determines the permitted context of the cron job.
>
>>> having a $1_cronjob_t domain.
>>>
>>> I anticipate that even if this patch is accepted later on there will be
>>> some changes required. Please review this not for inclusion immediately
>>> but for changes necessary. However the previous patch is good to go if
>>> you like the concept.
>>
>> I'm not keen on this. The current policy is intended to make it easy to
>> decide if you want to use a *_cronjob_t domain or simply transition to
>> the user's domain by tweaking the default_contexts.
>
> Which means that everyone who doesn't have a need for *_cronjob_t domains gets
> all the extra policy.
Since most people don't know how to recompile the distro policy, they're
going to be stuck with whichever way it is compiled by the distro. I
think the way that it is currently implemented is a fair tradeoff for
the vast majority of users.
--
Chris PeBenito
prev parent reply other threads:[~2019-01-10 0:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 3:10 [PATCH cron 2/2] user_crontab_t etc Russell Coker
2019-01-07 23:47 ` Chris PeBenito
2019-01-08 3:38 ` Russell Coker
2019-01-09 23:57 ` Chris PeBenito [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f56a5ac-d4d8-ccc4-ca6a-4876ac1e6aeb@ieee.org \
--to=pebenito@ieee.org \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).