From: Daniel Burgener <dburgener@linux.microsoft.com>
To: Russell Coker <russell@coker.com.au>, selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] puppet
Date: Mon, 14 Feb 2022 10:53:11 -0500 [thread overview]
Message-ID: <764d53e9-75d3-dc01-82e0-3b889265e582@linux.microsoft.com> (raw)
In-Reply-To: <YgjaswEDRfB5r2Mi@xev.coker.com.au>
On 2/13/2022 5:17 AM, Russell Coker wrote:
> This patch goes most of the way towards making puppet usable. It got puppet
> working for me to the stage where I decided I don't want to use puppet.
>
> I think it's worthy of inclusion.
>
> Signed-off-by: Russell Coker <russell@coker.com.au>
>
> Index: refpolicy-2.20210203/policy/modules/admin/puppet.fc
> ===================================================================
> --- refpolicy-2.20210203.orig/policy/modules/admin/puppet.fc
> +++ refpolicy-2.20210203/policy/modules/admin/puppet.fc
> @@ -11,6 +11,7 @@
> /usr/sbin/puppetd -- gen_context(system_u:object_r:puppet_exec_t,s0)
> /usr/sbin/puppetmasterd -- gen_context(system_u:object_r:puppetmaster_exec_t,s0)
>
> +/var/cache/puppet(/.*)? gen_context(system_u:object_r:puppet_cache_t,s0)
> /var/lib/puppet(/.*)? gen_context(system_u:object_r:puppet_var_lib_t,s0)
>
> /var/log/puppet(/.*)? gen_context(system_u:object_r:puppet_log_t,s0)
> Index: refpolicy-2.20210203/policy/modules/admin/puppet.te
> ===================================================================
> --- refpolicy-2.20210203.orig/policy/modules/admin/puppet.te
> +++ refpolicy-2.20210203/policy/modules/admin/puppet.te
> @@ -36,6 +36,9 @@ init_daemon_runtime_file(puppet_runtime_
> type puppet_tmp_t;
> files_tmp_file(puppet_tmp_t)
>
> +type puppet_cache_t;
> +files_type(puppet_cache_t)
> +
It looks to me like there are no rules added here. If I understand
everything right, under the current puppet policy, /var/cache/puppet/*
was labeled var_t, and I see that the current policy has
files_rw_var_files(puppet_t) in an optional block on line 185. That
makes me suspect that this line could be changed to rw puppet_cache_t.
That would likely keep this patch from reducing puppet functionality in
scenarios where it needs the cache, and also avoid the (presumably
excessive) var_t access it has now.
I'm no puppet expert, so maybe this is all off base, but it feels weird
to add this type, but add no rules for it and it seems like puppet
should probably be able to use its cache files.
-Daniel
> type puppet_var_lib_t;
> files_type(puppet_var_lib_t)
>
> @@ -96,6 +99,7 @@ kernel_read_kernel_sysctls(puppet_t)
> kernel_read_net_sysctls(puppet_t)
> kernel_read_network_state(puppet_t)
>
> +corecmd_bin_entry_type(puppet_t)
> corecmd_exec_bin(puppet_t)
> corecmd_exec_shell(puppet_t)
> corecmd_read_all_executables(puppet_t)
> @@ -267,6 +271,7 @@ allow puppetmaster_t puppet_etc_t:lnk_fi
> allow puppetmaster_t puppet_log_t:dir setattr_dir_perms;
> append_files_pattern(puppetmaster_t, puppet_log_t, puppet_log_t)
> create_files_pattern(puppetmaster_t, puppet_log_t, puppet_log_t)
> +read_files_pattern(puppetmaster_t, puppet_log_t, puppet_log_t)
> setattr_files_pattern(puppetmaster_t, puppet_log_t, puppet_log_t)
> logging_log_filetrans(puppetmaster_t, puppet_log_t, { file dir })
>
> @@ -287,6 +292,7 @@ kernel_read_system_state(puppetmaster_t)
> kernel_read_crypto_sysctls(puppetmaster_t)
> kernel_read_kernel_sysctls(puppetmaster_t)
>
> +corecmd_bin_entry_type(puppetmaster_t)
> corecmd_exec_bin(puppetmaster_t)
> corecmd_exec_shell(puppetmaster_t)
>
prev parent reply other threads:[~2022-02-14 15:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-13 10:17 [PATCH] puppet Russell Coker
2022-02-14 15:53 ` Daniel Burgener [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=764d53e9-75d3-dc01-82e0-3b889265e582@linux.microsoft.com \
--to=dburgener@linux.microsoft.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).