sous-chefs-boneyard / selinux_policy Goto Github PK
View Code? Open in Web Editor NEWDevelopment repository for the selinux_policy cookbook
Home Page: https://supermarket.chef.io/cookbooks/selinux_policy
License: Apache License 2.0
Development repository for the selinux_policy cookbook
Home Page: https://supermarket.chef.io/cookbooks/selinux_policy
License: Apache License 2.0
Docs: https://wiki.ubuntu.com/SELinux, probably need to remove the generic 'debian' install of selinux from the recipe
From https://supermarket.chef.io/cookbooks/compat_resource#changelog
The compat_resource cookbook has been deprecated and is no longer being maintained by its authors. Use of the compat_resource cookbook is no longer recommended
I am running this on the CentOS7 version. Even when converging on a vagrant the redisio is downloading the latest cookbook version. Still i see this error. Is there any fix for this?
redisio (2.6.1)
selinux_policy (2.0.1)
Linux 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Recipe: redisio::configure
* redisio_configure[redis-servers] action run
Recipe: selinux_policy::install
* yum_package[policycoreutils-python] action install
- install version 2.2.5-20.el7 of package policycoreutils-python
* yum_package[selinux-policy-devel] action install
- install version 3.13.1-60.el7_2.9 of package selinux-policy-devel
* yum_package[setools-console] action install
- install version 3.3.7-46.el7 of package setools-console
* yum_package[make] action install (up to date)
* user[redis] action create
- create user redis
* directory[/etc/redis] action create
- create new directory /etc/redis
- change mode from '' to '0755'
- change owner from '' to 'root'
- change group from '' to 'root'
- restore selinux security context
* selinux_policy_fcontext[/etc/redis(/.*)?] action addormodify
* execute[selinux-fcontext-redis_conf_t-add] action run
================================================================================
Error executing action `run` on resource 'execute[selinux-fcontext-redis_conf_t-add]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semanage fcontext -a -f a -t redis_conf_t '/etc/redis(/.*)?' ----
STDOUT:
STDERR: ValueError: Type redis_conf_t is invalid, must be a file or device type
---- End output of /usr/sbin/semanage fcontext -a -f a -t redis_conf_t '/etc/redis(/.*)?' ----
Ran /usr/sbin/semanage fcontext -a -f a -t redis_conf_t '/etc/redis(/.*)?' returned 1
2.3.2, 2.3.3
14.10.9
CentOS 7
selinux_policy_fcontext '/var/www/vhosts/application/var(/.*)?' do
secontext 'httpd_sys_rw_content_t'
end
This cookbook is used with Packer and chef-solo provider to build an Amazon Machine Image (AMI).
The cookbook should converge with no issues, as it did up until very recently.
Reported error during Packer build:
amazon-ebs: ---- Begin output of ["find", "/var/www/vhosts/application", "-ignore_readdir_race", "-regextype", "posix-egrep", "-regex", "/var/www/vhosts/application/var(/.*)?", "-prune", "-print0", "2>/dev/null", "|", "xargs", "-0", "-I", "{}", "restorecon", "-iRv", "{}"] ----
amazon-ebs: STDOUT:
amazon-ebs: STDERR: find: paths must precede expression: 2>/dev/null
amazon-ebs: Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
amazon-ebs: ---- End output of ["find", "/var/www/vhosts/application", "-ignore_readdir_race", "-regextype", "posix-egrep", "-regex", "/var/www/vhosts/application/var(/.*)?", "-prune", "-print0", "2>/dev/null", "|", "xargs", "-0", "-I", "{}", "restorecon", "-iRv", "{}"] ----
amazon-ebs: Ran ["find", "/var/www/vhosts/application", "-ignore_readdir_race", "-regextype", "posix-egrep", "-regex", "/var/www/vhosts/application/var(/.*)?", "-prune", "-print0", "2>/dev/null", "|", "xargs", "-0", "-I", "{}", "restorecon", "-iRv", "{}"] returned 1
Please note that the issue happened without me updating the cookbook (I was using version 2.3.2 for a while, and only attempted to use 2.3.3 to see whether this behaviour would still appear). The last successful build was around 20 days ago with Chef client version 14.8.12. Will the client affect the way the cookbook is run?
Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.
On the repo, ensure that Dangerfile
matches https://github.com/sous-chefs/repo-management/blob/master/Dangerfile
Issue sprouted from sous-chefs/meta/issues/110. If not applicable then issue should be closed.
I am receiving the following error when attempting to use this cookbook:
NoMethodError
execute[selinux-fcontext-httpd_sys_script_exec_t-addormodify] (/var/chef/cache/cookbooks/selinux-policy/providers/fcontext.rb line 37) had an error: NoMethodError: No resource or method named `shell_out!' for `Chef::Provider::SelinuxPolicyFcontext ""'
This is what the compiled resource looks like in the debug log:
# Declared in /var/chef/cache/cookbooks/ep-nagios/recipes/thruk.rb:90:in `from_file'
selinux_policy_fcontext("/usr/share/thruk/fcgid_env.sh") do
action :addormodify
retries 0
retry_delay 2
guard_interpreter :default
cookbook_name "ep-nagios"
recipe_name "thruk"
secontext "httpd_sys_script_exec_t"
file_spec "/usr/share/thruk/fcgid_env.sh"
end
Here is the snippet where it is called in the recipe:
selinux_policy_fcontext '/usr/share/thruk/fcgid_env.sh' do
secontext 'httpd_sys_script_exec_t'
end
More details:
Any ideas?
This is more a question than an issue, because nothing is truly broken.
I have a fcontext for /var/lib/mysql-default(/.*)?
The relabel for this is a restorecon on /var/lib
Could the code that checks the path be rewritten so the restorecon would be done on /var/lib/mysql-default? Is there a list of special regex characters that could be trimmed from the end that should never be in folder names?
The question comes because a restorecon on /var/lib takes reaaaaally long
The fact that the condition uses the same command while not changing anything, doesn't help either. As far as I can see ATM this only means a run almost twice as long (in my case).
Amazon Linux 2 has platform_family amazon
, whereas Amazon Linux (1) reports this as rhel
This makes this recipe fail on Amz Linux 2 instances.
when 'amazon'
package ['policycoreutils-python', 'selinux-policy-devel', 'setools-console', 'make']
2.1.0
14.2
RHEL 7
I have the following resource to enable support for NGINX
selinux_policy_boolean 'httpd_can_network_connect' do
value true
end
This works every time.
It works on the first chef run, but on some later chef runs, I get this error instead:
selinux_policy_boolean[httpd_can_network_connect] (cookbook::nginx line 26) had an error: Errno::ENOENT: execute[selinux-setbool-httpd_can_network_connect-on] (/var/chef/cache/cookbooks/selinux_policy/providers/boolean.rb line 21) had an error: Errno::ENOENT: No such file or directory - setsebool
Hi,
In one of my cookbook I call the selinux_policy_module
to install a module already in .pp
format.
### Install the SELinux policies
include_recipe 'selinux_policy::default'
selinux_policy_module 'postfixvas' do
directory_source 'selinux-qas'
action :install
end
Unfortunately i get errors:
run
on resource 'execute[semodule-install-postfixvas]'install
on resource 'selinux_policy_module[postfixvas]'/usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp
command fails. Actually it seems that the .pp
file is not there! (see the complete error message at the end)[root@server001 chef-repo_QoD]# ls -al cookbooks/unix_ad4unix/files/default/selinux-qas/*.pp
-rwxrwx---. 1 544 1049089 1412 Mar 8 09:33 cookbooks/unix_ad4unix/files/default/selinux-qas/postfixvas.pp
-rwxrwx---. 1 544 1049089 1683 Mar 8 09:33 cookbooks/unix_ad4unix/files/default/selinux-qas/sshdqas.pp
The .pp file is well provided in a sub directory of files/default/
. As you will see, to ensure that the files are accessible, I put a remote_directory
resource before to test it. And with the source 'selinux-qas'
it finds the file.
### Test remote directory resource
remote_directory '/tmp' do
source 'selinux-qas'
owner 'root'
group 'root'
mode '0755'
action :create
end
I'm quite new using Chef, so it is possible that I miss something. Don't slap me too hard if this is the case! ;-)
Full output I get:
[root@server001 chef-repo_QoD]# chef-solo -c .chef/chef-solo.rb
Starting Chef Client, version 12.7.2
Compiling Cookbooks...
Converging 9 resources
Recipe: yum::default
* yum_globalconfig[/etc/yum.conf] action create
* template[/etc/yum.conf] action create (up to date)
(up to date)
Recipe: unix_repo::default
* yum_repository[rhel-updates-6] action create
* template[/etc/yum.repos.d/rhel-updates-6.repo] action create (up to date)
* execute[yum clean metadata rhel-updates-6] action nothing (skipped due to action :nothing)
* execute[yum-makecache-rhel-updates-6] action nothing (skipped due to action :nothing)
* ruby_block[yum-cache-reload-rhel-updates-6] action nothing (skipped due to action :nothing)
(up to date)
* yum_repository[system-tools-6] action create
* template[/etc/yum.repos.d/system-tools-6.repo] action create (up to date)
* execute[yum clean metadata system-tools-6] action nothing (skipped due to action :nothing)
* execute[yum-makecache-system-tools-6] action nothing (skipped due to action :nothing)
* ruby_block[yum-cache-reload-system-tools-6] action nothing (skipped due to action :nothing)
(up to date)
Recipe: unix_ad4unix::default
* yum_package[vasclnt] action install (up to date)
* yum_package[quest-sudo] action install (up to date)
* template[/etc/profile.d/qas-path.sh] action create (up to date)
* remote_directory[/tmp] action create
Recipe: <Dynamically Defined Resource>
* cookbook_file[/tmp/sshdqas.te] action create (up to date)
* cookbook_file[/tmp/postfixvas.pp] action create (up to date)
* cookbook_file[/tmp/sshdqas.pp] action create (up to date)
* cookbook_file[/tmp/postfixvas.te] action create (up to date)
(up to date)
Recipe: unix_ad4unix::default
* selinux_policy_module[sshdqas] action install
* execute[semodule-install-sshdqas] action run (skipped due to only_if)
(up to date)
* selinux_policy_module[postfixvas] action install
* execute[semodule-install-postfixvas] action run
================================================================================
Error executing action `run` on resource 'execute[semodule-install-postfixvas]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
STDOUT:
STDERR: /usr/sbin/semodule: Failed on /root/.chef/postfixvas/postfixvas.pp!
---- End output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
Ran /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp returned 1
Resource Declaration:
---------------------
# In /root/chef-repo_QoD/cookbooks/selinux_policy/providers/module.rb
62: execute "semodule-install-#{new_resource.module_name}" do
63: command "/usr/sbin/semodule -i #{filename}"
64: only_if "#{shell_boolean(new_resource.updated_by_last_action? || new_resource.force)} || ! (#{module_defined(new_resource.module_name)}) "
65: only_if {use_selinux}
66: end
67: end
Compiled Resource:
------------------
# Declared in /root/chef-repo_QoD/cookbooks/selinux_policy/providers/module.rb:62:in `block in class_from_file'
execute("semodule-install-postfixvas") do
action [:run]
retries 0
retry_delay 2
default_guard_interpreter :execute
command "/usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp"
backup 5
returns 0
declared_type :execute
cookbook_name :unix_ad4unix
only_if "false || ! (/usr/sbin/semodule -l | grep -w '^postfixvas') "
only_if { #code block }
end
================================================================================
Error executing action `install` on resource 'selinux_policy_module[postfixvas]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
execute[semodule-install-postfixvas] (/root/chef-repo_QoD/cookbooks/selinux_policy/providers/module.rb line 62) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
STDOUT:
STDERR: /usr/sbin/semodule: Failed on /root/.chef/postfixvas/postfixvas.pp!
---- End output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
Ran /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp returned 1
Resource Declaration:
---------------------
# In /root/chef-repo_QoD/cookbooks/unix_ad4unix/recipes/default.rb
41: selinux_policy_module 'postfixvas' do
42: directory_source '/tmp'
43: action :install
44: end
45: end
Compiled Resource:
------------------
# Declared in /root/chef-repo_QoD/cookbooks/unix_ad4unix/recipes/default.rb:41:in `from_file'
selinux_policy_module("postfixvas") do
action [:install]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :selinux_policy_module
cookbook_name :unix_ad4unix
recipe_name "default"
directory_source "/tmp"
module_name "postfixvas"
end
Running handlers:
[2016-03-11T18:21:20+01:00] ERROR: Running exception handlers
Running handlers complete
[2016-03-11T18:21:20+01:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 06 seconds
[2016-03-11T18:21:20+01:00] FATAL: Stacktrace dumped to /root/.chef/chef-stacktrace.out
[2016-03-11T18:21:20+01:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2016-03-11T18:21:20+01:00] ERROR: selinux_policy_module[postfixvas] (unix_ad4unix::default line 41) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[semodule-install-postfixvas] (/root/chef-repo_QoD/cookbooks/selinux_policy/providers/module.rb line 62) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
STDOUT:
STDERR: /usr/sbin/semodule: Failed on /root/.chef/postfixvas/postfixvas.pp!
---- End output of /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp ----
Ran /usr/sbin/semodule -i /root/.chef/postfixvas/postfixvas.pp returned 1
[2016-03-11T18:21:20+01:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Hi there,
Is it possible to create a new login mapping, similar to running the following command?
semanage login -a -s user_u newuser
I had a quick search through the cookbook and couldn't find a way of doing this. Apologies if its there and this is something I've missed.
Thanks!
2.3.4
13.6.4
Centos 7
Setting a boolean with selinux_policy_boolean is not persistent by default.
I had this same recipe with version 1.0.1 and I recently updated to 2.3.4 and my recipes with:
selinux_policy_boolean 'httpd_can_network_connect' do
value true
end
are not persistent anymore and I had to include the flag:
selinux_policy_boolean 'httpd_can_network_connect' do
value true
action :setpersist
end
It was expected the same behaviour as previous version and as it is explained in README.md:
Represents an SELinux boolean. You can either set it, meaning it will be changed without persistence (it will revert to default in the next reboot), or setpersist it (default action), so it'll keep it value after rebooting. Using setpersist requires an active policy (so that the new value can be saved somewhere).
If the machine is reboot selinux boolean settings are lost.
Thanks in advance for your time.
Hi! I am part of the sous-chefs community org. We saw your request for a new maintainer of this cookbook and would like to take you up on the offer.
https://github.com/sous-chefs
https://supermarket.chef.io/users/sous-chefs
Let me know if that would me possible :)
Looks like this cookbook doesn't support RHEL 8:
================================================================================
Recipe Compile Error in /tmp/kitchen/cache/cookbooks/cub_policy_common/recipes/default.rb
================================================================================
RuntimeError
------------
Unknown version of RHEL/derivative, cannot determine required package names
Cookbook Trace:
---------------
/tmp/kitchen/cache/cookbooks/selinux_policy/recipes/install.rb:13:in `from_file'
/tmp/kitchen/cache/cookbooks/cub_selinux/recipes/default.rb:7:in `from_file'
/tmp/kitchen/cache/cookbooks/cub_monitoring/recipes/nrpe.rb:16:in `from_file'
/tmp/kitchen/cache/cookbooks/cub_monitoring/recipes/nrpe_checks.rb:10:in `from_file'
/tmp/kitchen/cache/cookbooks/cub_monitoring/recipes/default.rb:16:in `from_file'
/tmp/kitchen/cache/cookbooks/cub_policy_common/recipes/default.rb:8:in `block in from_file'
/tmp/kitchen/cache/cookbooks/cub_policy_common/recipes/default.rb:7:in `each'
/tmp/kitchen/cache/cookbooks/cub_policy_common/recipes/default.rb:7:in `from_file'
Relevant File Content:
----------------------
/tmp/kitchen/cache/cookbooks/selinux_policy/recipes/install.rb:
6: case node['platform_version'].to_i
7: when 6
8: # selinux-policy-devel does not exist in RHEL6
9: pkgs = ['policycoreutils-python', 'selinux-policy', 'setools-console', 'make']
10: when 7
11: pkgs = ['policycoreutils-python', 'selinux-policy-devel', 'setools-console', 'make']
12: else
13>> raise 'Unknown version of RHEL/derivative, cannot determine required package names'
14: end
15: when 'fedora'
16: pkgs = ['policycoreutils-python', 'selinux-policy-devel', 'setools-console', 'make']
17: else
18: raise 'Unknown distro, cannot determine required package names'
19: end
20:
21: pkgs.each { |p| package p }
22:
System Info:
------------
chef_version=14.2.0
platform=redhat
platform_version=8.0
ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
program_name=/opt/chef/bin/chef-client
executable=/opt/chef/bin/chef-client
It appears to me that the correct package names for RHEL 8 are:
pkgs = ['policycoreutils-python-utils', 'selinux-policy-devel', 'setools-console', 'make']
Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.
If the only thing in the .rubocop/yml
is Dangerfile
Run the latest cookstyle
Remove .rubpopo.yml
Issue sprouted from sous-chefs/meta/issues/108. If not applicable then issue should be closed.
I'm still getting to grips with SELinux but I'm having an issue where systemd is creating a UNIX socket with the wrong context. Possibly a systemd bug but I'm not sure. In any case, files can come and go and it is a little annoying that once an fcontext is added, restorecon is never run again unless you use the modify action. This is counter-intuitive and hard to script around. I think it should be run unconditionally. What do you think?
One for the ChefConf hack day if you're around.
What we need are images that have SELinux disabled & enabled initially so it speeds up testing when it's enabled, and tests it can be enabled when we enable it.
2.0.1+
12.x -> 14.x
CentOS 7.x Current
find (GNU findutils) 4.5.11 has a filedescriptor leak in -execdir. This has been patched in 4.5.12 (http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=183115d0) but currently CentOS 7.x runs on 4.5.11 (https://pkgs.org/download/findutils).
This change is what created this bug.
4c57424
Step to repo can be found at the bottom of this post.
http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=183115d0
Easiest way to repo is create a bunch of folders and files and then run on centOS 7.x while lowering ulimits.
ulimits -n 256; chef-client
restorecon works
[2018-11-15T18:02:22+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-11-15T18:02:22+00:00] ERROR: selinux_policy_fcontext[/var/lib/kafka(/.*)?] (cf_kafka::_config line 66) had an error: Mixlib::ShellOut::ShellCommandFailed: selinux_policy_fcontext[/var/lib/kafka(/.*)?] (cf_kafka::_config line 66) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/lib/kafka(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] ----
STDOUT:
STDERR: find: Failed to save working directory in order to run a command on β00000000000000890135.logβ: Too many open files
---- End output of ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/lib/kafka(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] ----
Ran ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/lib/kafka(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] returned 1
[2018-11-15T18:02:22+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Hi Nitz,
I've noticed the following message popping up lately with chef 12.10.24
Default value "10040" is invalid for property port of resource selinux_policy_port. In Chef 13 this will become an error: Option port must be a kind of [Integer]! You passed "10040".. at 1 location:
- /tmp/kitchen/cache/cookbooks/selinux_policy/providers/port.rb:22:in `block in class_from_file'
I fixed the message by updating the port attribute in selinux_policy/resources/port.rb to a String:
#attribute :port, :kind_of => Integer, :name_attribute => true
attribute :port, :kind_of => String, :name_attribute => true
Would you be happy for me to submit a PR for this or do you prefer a different fix?
Edward
This doesn't appear to run on Amazon Linux, which essentially is another RHEL/Centos.
------------
selinux_policy_install("install") do
action [:install]
default_guard_interpreter :default
declared_type :selinux_policy_install
cookbook_name "selinux_policy"
recipe_name "install"
end
chef_version=15.5.17
platform=amazon
platform_version=2
ruby=ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
program_name=/bin/chef-client
executable=/opt/chefdk/bin/chef-client
On RHEL/CentOS, package 'selinux-policy-devel'
is required to add new policy modules.
Hi,
I'm using a wrapper for this cookbook on CentOS release 6.8 (Final) and Chef 12.11.18, and although the final configurations are working, the step "semodule-install" is being executed every time.
I have tracked the code that should be preventing this on "selinux_policy/providers/module.rb"
# deploy / upgrade module
# XXX this looks ugly AF because CentOS 6.X doesn't support extracting
# SELinux modules from the current policy, which I planned on comparing
# to my compiled file. I'll be happy to see anything else (that works).
action :install do
filename = "#{new_resource.directory}/#{new_resource.module_name}.pp"
execute "semodule-install-#{new_resource.module_name}" do
command "/usr/sbin/semodule -i #{filename}"
only_if "#{shell_boolean(new_resource.updated_by_last_action? || new_resource.force)} || ! (#{module_defined(new_resource.module_name)}) "
only_if { use_selinux }
end
end
This is part of the chef_run:
Recipe: custom_logrotate::selinux_policy
* selinux_policy_module[logrotate_audit] action deploy
* directory[/var/chef/cache/logrotate_audit] action create (up to date)
* file[/var/chef/cache/logrotate_audit/logrotate_audit.te] action create (up to date)
(up to date)
* execute[semodule-compile-logrotate_audit] action run (skipped due to not_if)
(up to date)
* execute[semodule-install-logrotate_audit] action run
- execute /usr/sbin/semodule -i /var/chef/cache/logrotate_audit/logrotate_audit.pp
You can see that even though the previous step didn't run the semodule install was executd anyway. I see the comments related to CentOS 6.X not support extracting and the "hack" should be working but it's not.
Is this related to the Chef version I'm running?
Regards
With the latest 2.2.0 release, this error comes up:
================================================================================
Error executing action `create` on resource 'directory[/var/chef/cache/dockersock]'
================================================================================
ArgumentError
-------------
wrong number of arguments (given 0, expected 1)
Cookbook Trace:
---------------
/var/chef/cache/cookbooks/selinux_policy/libraries/helpers.rb:8:in `use_selinux'
/var/chef/cache/cookbooks/selinux_policy/resources/module.rb:22:in `block (3 levels) in class_from_file'
/var/chef/cache/cookbooks/selinux_policy/resources/module.rb:14:in `block in class_from_file'
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/selinux_policy/resources/module.rb
21: directory new_resource.directory do
22: only_if { use_selinux }
23: end
24:
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/selinux_policy/resources/module.rb:21:in `block in class_from_file'
directory("/var/chef/cache/dockersock") do
action [:create]
default_guard_interpreter :default
declared_type :directory
cookbook_name "dltools"
path "/var/chef/cache/dockersock"
owner nil
group nil
mode nil
only_if { #code block }
end
Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.
Update all CHANGELOGs to follow standard defined at https://keepachangelog.com/
Issue sprouted from sous-chefs/meta/issues/101. If not applicable then issue should be closed.
Hi,
I was going to give your cookbook a try as it looked like just the thing I need however I'm struggling to get past the first step.
Chef server web ui displays the message "ERROR: incompatible character encodings: UTF-8 and ASCII-8BIT" when I attempt to view 0.6.1 or 0.6.0.
I don't know if its related but my recipe then fails to compile on chef-client run:
Recipe Compile Error in /var/chef/cache/cookbooks/vszendserver/recipes/default.rb
================================================================================
NoMethodError
-------------
No resource or method named `selinux_policy_boolean' for `Chef::Recipe "default"'
Cookbook Trace:
---------------
/var/chef/cache/cookbooks/vszendserver/recipes/default.rb:149:in `from_file'
Relevant File Content:
----------------------
/var/chef/cache/cookbooks/vszendserver/recipes/default.rb:
146: #######################
147: # Set SELinux config
148: #######################
149>> selinux_policy_boolean 'httpd_can_network_connect_db' do
150: value true
151: end
152:
153: selinux_policy_boolean 'httpd_can_network_memcache' do
154: value true
155: end
156:
157: selinux_policy_port '10083' do
158: protocol 'tcp'
I've tried various combinations of version constraints in my metadata.rb but none seem to make a difference and the dependency on selinux_policy never seems to get pulled in.
Thanks for your help
Alex
latest
14.2
RHEL 7.5
Chef client 14.2 changed the way execute works, from the release notes:
default_env Property in Execute Resource
The shell_out helper has been extended with a new option default_env to allow disabling Chef from modifying PATH and LOCALE environmental variables as it shells out. This new option defaults to true (modify the environment), preserving the previous behavior of the helper.
The execute resource has also been updated with a new property default_env that allows utilizing this the ENV sanity functionality in shell_out. The new property defaults to false, but it can be set to true in order to ensure a sane PATH and LOCALE when shelling out. If you find that binaries cannot be found when using the execute resource, default_env set to true may resolve those issues.
Use chef-client 14.2, run from cron (we use sudo seems to inherit env and run just fine that way).
Chef client to run cleanly
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '127'
---- Begin output of semanage fcontext -a -f a -t etc_t '/etc/nagios/nrpe.
cfg' ----
STDOUT:
STDERR: sh: semanage: command not found
---- End output of semanage fcontext -a -f a -t etc_t '/etc/nagios/nrpe.cf
g' ----
Ran semanage fcontext -a -f a -t etc_t '/etc/nagios/nrpe.cfg' returned 127
Cookbook Trace:
---------------
/var/chef/cache/cookbooks/selinux_policy/providers/fcontext.rb:92:in `block in class_from_file'
This is kind of crazy:
https://github.com/sous-chefs/selinux_policy/blob/master/providers/fcontext.rb#L41
You occasionally run into errors like this:
[15:08:20][Step 4/7] ---- Begin output of ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/cache/nova(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] ----
[15:08:20][Step 4/7] STDOUT:
[15:08:20][Step 4/7] STDERR: find: β/proc/11889β: No such file or directory
[15:08:20][Step 4/7] ---- End output of ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/cache/nova(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] ----
[15:08:20][Step 4/7] Ran ["find", "/", "-regextype", "posix-egrep", "-regex", "/var/cache/nova(/.*)?", "-execdir", "restorecon", "-iRv", "{}", ";"] returned 1
If you're going to shellout to find, you could determine the filesystem you need to search, and then use -xdev to avoid crossing filesystem boundaries, otherwise you could start searching large network storage, or hitting issues like this with ephemeral files in /proc.
Also using -execdir {}; forks for each file found. xargs or {}+ passes multiple arguments to the utility being invoked, thereby reducing overhead.
Each selinux_policy_fcontext resource takes a very long time to run - five to ten seconds on my system. This is of course due to the underlying semanage utility also being slow.
When adding many fcontexts, that slow down my cookbook to unacceptable levels (from 2 to about 20 minutes) - not just the first time, but on every run because testing the guards also takes a long time.
The semanage utility supports importing many fcontexts (and booleans and ports) at once (semanage -i), which is dramatically faster.
Also, testing if a context already exists could be optimized by caching the output from semanage fcontext -ln
Similar optimizations should also be possible for booleans and ports, although it is, at least for me, less critical.
Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.
As part of our build process we should build each possible operating system separately
dokken list
, you should see a list of builds with dokken as the providerdokken list -j | ./circleci_maker.rb > .circleci/config.yml
Issue sprouted from sous-chefs/meta/issues/112. If not applicable then issue should be closed.
Currently it is not possible to compile policy modules if selinux is disabled (even if it is enabled in selinux config and the server simply hasn't been rebooted yet). This is problematic because it requires booting into permissive or enforcing mode and then re-running chef-client to compile the module. Between boot and chef-client completion audit logs could be spammed with avc denials and system functionality could be impaired. I am not yet aware of a technical reason that a policy module can't be compiled while selinux is disabled.
2.4.3
Chef Infra Client: 16.16.13
Oracle Enterprise Linux 6/7
Steps to reproduce the behavior:
Invoke selinux policy module in recipe while selinux has not been set to permissive/enforcing via rebooting after updating selinux config file to permissive/enforcing.
It would be nice if there were a module property that could be passed to the use_selinux helper that would allow it to return true even when selinux is disabled. I tested this on a forked version of the cookbook and it seemed to work as expected. However I am aware that there may be some other reason this is designed in this way to not allow module compilation.
Current regex cannot handle the case where multiple ports are defined for a single type.
This is breaking whenever notifies :relabel, new_resource
executes and the :relabel
executes . Doing so causes the resource to be updated in two places, which then throws an exception.
Second compile does not cause issues
Chef output with -l debug
* selinux_policy_fcontext[/ortldata/home/\.ssh(/.*)?] action add
* execute[selinux-fcontext-ssh_home_t-add] action runEnforcing
- execute /usr/sbin/semanage fcontext -a -f a -t ssh_home_t '/ortldata/home/\.ssh(/.*)?'
* selinux_policy_fcontext[/ortldata/home/\.ssh(/.*)?] action relabel
* execute[selinux-fcontext-relabel-ssh_home_t] action run
[execute]
- execute restorecon -iR /ortldata
================================================================================
Error executing action `add` on resource 'selinux_policy_fcontext[/ortldata/home/\.ssh(/.*)?]'
================================================================================
NoMethodError
-------------
undefined method `updated' for nil:NilClass
Resource Declaration:
---------------------
# In /var/cache/chef/cookbooks/myer_merch/recipes/rpas_prep.rb
7: selinux_policy_fcontext ::File.join(node['rpas']['home_dir'], '/\.ssh(/.*)?') do
8: secontext 'ssh_home_t'
9: action :add
10: end
11: daemon_user 'rpas' do
Compiled Resource:
------------------
# Declared in /var/cache/chef/cookbooks/myer_merch/recipes/rpas_prep.rb:7:in `from_file'
selinux_policy_fcontext("/ortldata/home/\.ssh(/.*)?") do
action [:add]
updated true
updated_by_last_action true
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :selinux_policy_fcontext
cookbook_name "myer_merch"
recipe_name "rpas_prep"
secontext "ssh_home_t"
file_spec "/ortldata/home/\\.ssh(/.*)?"
file_type "a"
end
Platform:
---------
x86_64-linux
# chef-client --version
Chef: 12.16.42
chef-stacktrace.out
Generated at 2016-11-11 17:59:39 +1100
NoMethodError: undefined method `failed' for nil:NilClass
Did you mean? fail
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/data_collector.rb:210:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:43:in `call'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:43:in `block in call_subscribers'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:34:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:34:in `call_subscribers'
(eval):2:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource.rb:634:in `rescue in run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource.rb:620:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:69:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:96:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:669:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:664:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:664:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:703:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:283:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:294:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:282:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:282:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:247:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:235:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:450:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:450:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:434:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:59:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/bin/chef-client:26:in `<top (required)>'
/bin/chef-client:54:in `load'
/bin/chef-client:54:in `<main>'
>>>> Caused by NoMethodError: undefined method `updated' for nil:NilClass
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/data_collector.rb:202:in `resource_updated'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:43:in `call'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:43:in `block in call_subscribers'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:34:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/event_dispatch/dispatcher.rb:34:in `call_subscribers'
(eval):2:in `resource_updated'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider.rb:166:in `set_updated_status'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/provider.rb:148:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource.rb:622:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:69:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `each'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:97:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:103:in `iterate'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/resource_collection/resource_list.rb:92:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/2.3.0/forwardable.rb:189:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/runner.rb:96:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:669:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:664:in `catch'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:664:in `converge'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:703:in `converge_and_save'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/client.rb:283:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:294:in `block in fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:282:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:282:in `fork_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:247:in `block in run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/local_mode.rb:44:in `with_server_connectivity'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:235:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:464:in `sleep_then_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:451:in `block in interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:450:in `loop'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:450:in `interval_run_chef_client'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application/client.rb:434:in `run_application'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/lib/chef/application.rb:59:in `run'
/opt/chef/embedded/lib/ruby/gems/2.3.0/gems/chef-12.16.42/bin/chef-client:26:in `<top (required)>'
/bin/chef-client:54:in `load'
/bin/chef-client:54:in `<main>'
Moving the :relabel
execute inside the :add
does not cause an issue. I think instead you want an action_class to remove the resource definition duplication.
Hi @BackSlasher,
Is the following command to copy an selinux context something I could achieve with your cookbook?
semanage fcontext -a -e /etc/httpd /myserverroot
Thanks,
Ed
We are experiencing the following issue: when trying to define port 40933 as a syslog_port_t
, the cookbook fails because it tries to call semanage -m
(action :modify
) on a port that is only defined as part of a range. e.g:
Recipe: core::configure-papertrail
* selinux_policy_port[selinux_papertrail_port] action addormodify
* execute[selinux-port-40933-add] action run (skipped due to not_if)
(up to date)
* execute[selinux-port-40933-modify] action run
================================================================================
Error executing action `run` on resource 'execute[selinux-port-40933-modify]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semanage port -m -t syslogd_port_t -p tcp 40933 ----
STDOUT:
STDERR: ValueError: Port @tcp/40933 is not defined
---- End output of /usr/sbin/semanage port -m -t syslogd_port_t -p tcp 40933 ----
Ran /usr/sbin/semanage port -m -t syslogd_port_t -p tcp 40933 returned 1
Cookbook Trace:
---------------
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'
/var/chef/cookbooks/selinux_policy/providers/port.rb:57:in `block in class_from_file'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
/var/chef/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'
Resource Declaration:
---------------------
# In /var/chef/cookbooks/selinux_policy/providers/port.rb
45: execute "selinux-port-#{new_resource.port}-modify" do
46: command "/usr/sbin/semanage port -m -t #{new_resource.secontext} -p #{new_resource.protocol} #{new_resource.port}"
47: only_if port_defined(new_resource.protocol, new_resource.port)
48: not_if port_defined(new_resource.protocol, new_resource.port, new_resource.secontext)
49: only_if { use_selinux }
50: end
51: end
The problem appears to be due to the fact that the run_action(:add)
block exits due to its not_if
clause (because the port DOES show up in the port_defined
grep), but run_action(:modify)
DOES execute because it's not actually defined for the appropriate context (syslogd_port_t
in this case). So semanage -m
is executed, but fails because it apparently doesn't recognize the port as being actually defined because it's only part of a range:
$ seinfo --protocol=tcp --portcon=40399
portcon tcp 32768-61000 system_u:object_r:ephemeral_port_t:s0
If I manually define the port with the exact same description, it works like a charm:
$ /usr/sbin/semanage port -a -t ephemeral_port_t -p tcp 40933
$ seinfo --protocol=tcp --portcon=40933
portcon tcp 40933 system_u:object_r:ephemeral_port_t:s0
portcon tcp 32768-61000 system_u:object_r:ephemeral_port_t:s0
<rerun chef>
...
Recipe: core::configure-papertrail
* selinux_policy_port[selinux_papertrail_port] action addormodify
* execute[selinux-port-40933-add] action run (skipped due to not_if)
(up to date)
* execute[selinux-port-40933-modify] action run
- execute /usr/sbin/semanage port -m -t syslogd_port_t -p tcp 40933
...
I see there's some tests in the cookbook that have to do with port ranges, but they appear incomplete. The selinux_policy_test::range_port
cookbook appears to imply that the cookbook should fail if a port is actually modified based on a range. But that would never happen anyway, as the -m
fails before that.
What is the actual expected behavior in this case? The following patch fixes the issue for our use, in that on first run the :add
action is triggered to explicitly define the port on its own and subsequent "do the right thing" in terms of not_if
skipping the resources correctly. All it's doing is grep
-ing out port ranges from seinfo
output. I am happy to make a PR if that is the expected behavior.
diff --git a/providers/port.rb b/providers/port.rb
index 1d5139d..eb06a1b 100644
--- a/providers/port.rb
+++ b/providers/port.rb
@@ -6,7 +6,10 @@ def whyrun_supported?
end
def port_defined(protocol, port, label = nil)
- base_command = "seinfo --protocol=#{protocol} --portcon=#{port} | awk -F: '$(NF-1) !~ /reserved_port_t$/ {print $(NF-1)}'"
+ # list all matches to this protocol definition, but exclude ones where it is
+ # part of a range calling semanage -m on a port that is only defined as part
+ # of a range causes it to fail
+ base_command = "seinfo --protocol=#{protocol} --portcon=#{port} | grep -vP '[\d+]-[\d+]' | awk -F: '$(NF-1) !~ /reserved_port_t$/ {print $(NF-1)}'"
grep = if label
"grep -P '#{Regexp.escape(label)}'"
else
When trying to manage selinux ports on CentOS 8, a port that already has been assigned to a type will cause a chef-client run to fail.
selinux_policy 2.3.4
Chef Infra Client: 15.6.10
$ cat /etc/centos-release
CentOS Linux release 8.0.1905 (Core)
$ uname -a
Linux centos8host.local 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa | grep setools-console
setools-console-4.2.0-2.el8.x86_64
On-prem VMware instance.
Steps to reproduce the behavior:
Recipe use of selinux_policy_port
# Configure the SSH port in SELinux
selinux_policy_port '122' do
protocol 'tcp'
secontext 'ssh_port_t'
end
Then on a CentOS 8 machine, run chef-client
twice - once to do the original add, then again to trip the error because the port already exists when trying to re-add.
Based on CentOS 7 once Chef has run successfully once, the helper port_defined
should complete successfully and report the group like so:
$ sudo seinfo --portcon=122 --protocol=tcp | awk -F: '$(NF-1) !~ /reserved_port_t$/ && $(NF-3) !~ /[0-9]*-[0-9]*/ {print $(NF-1)}'
ssh_port_t
CentOS 7 details:
$ cat /etc/centos-release
CentOS Linux release 7.7.1908 (Core)
$ uname -a
Linux centos7host.local 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[srvadmin@mxdockt01 ~]$ rpm -qa | grep setools
setools-libs-3.3.8-4.el7.x86_64
setools-console-3.3.8-4.el7.x86_64
[srvadmin@mxdockt01 ~]$ rpm -qa | grep setools-con
setools-console-3.3.8-4.el7.x86_64
[srvadmin@mxdockt01 ~]$ rpm -qa | grep setools-consol
setools-console-3.3.8-4.el7.x86_64
The CentOS 8 chef-client run fails with the attached (too long to post) stack trace of errors.
selinux_stack_trace.txt
Most noticeable error in the output:
* execute[selinux-port-122-add] action run[2020-01-05T22:28:52+00:00] INFO: Processing execute[selinux-port-122-add] action run (/var/chef/cache/cookbooks/selinux_policy/resources/port.rb line 21)
[2020-01-05T22:28:52+00:00] INFO: Processing execute[Guard resource] action run (dynamically defined)
usage: seinfo [-h] [--version] [-x] [--flat] [-v] [--debug] [-a [ATTR]]
[-b [BOOL]] [-c [CLASS]] [-r [ROLE]] [-t [TYPE]] [-u [USER]]
[--category [CAT]] [--common [COMMON]] [--constrain [CLASS]]
[--default [CLASS]] [--fs_use [FS_TYPE]] [--genfscon [FS_TYPE]]
[--initialsid [NAME]] [--netifcon [DEVICE]] [--nodecon [ADDR]]
[--permissive [TYPE]] [--polcap [NAME]]
[--portcon [PORTNUM[-PORTNUM]]] [--sensitivity [SENS]]
[--typebounds [BOUND_TYPE]] [--validatetrans [CLASS]] [--all]
[--ioportcon] [--iomemcon] [--pcidevicecon] [--pirqcon]
[--devicetreecon]
[policy]
seinfo: error: unrecognized arguments: --protocol=tcp
There's two potential things here as a result of moving to CentOS 8:
--protocol
flag for the semanage
command the library helpers are trying to use, so we're erroring out there.--protocol
(so I may get other protocols/ports/etc), other than the padding on the output lines I can't see a format change. I'm pretty rubbish when it comes to awk
but wonder if something has changed there too on top of 1 above?If relevant, CentOS 7 => GNU Awk 4.0.2, CentOS 8 => GNU Awk 4.2.1.
Thanks!
Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.
Chef have released updated cookstyle rules, we should therefore run the auto fix against the cookbook
chef-workstation
cookstyle -a
Issue sprouted from sous-chefs/meta/issues/111. If not applicable then issue should be closed.
I get the following when trying to define a port.
================================================================================
Error executing action `addormodify` on resource 'selinux_policy_port[1514]'
================================================================================
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
execute[selinux-port-1514-add] (/tmp/kitchen/cache/cookbooks/selinux_policy/providers/port.rb line 22) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /usr/sbin/semanage port -a -t syslogd_port_t -p tcp 1514 ----
STDOUT:
STDERR: ValueError: Port tcp/1514 already defined
---- End output of /usr/sbin/semanage port -a -t syslogd_port_t -p tcp 1514 ----
Ran /usr/sbin/semanage port -a -t syslogd_port_t -p tcp 1514 returned 1
Cookbook Trace:
---------------
/tmp/kitchen/cache/cookbooks/selinux_policy/providers/port.rb:49:in `block in class_from_file'
Resource Declaration:
---------------------
# In /tmp/kitchen/cache/cookbooks/al_agents/recipes/selinux.rb
9: selinux_policy_port '1514' do
10: protocol 'tcp'
11: secontext 'syslogd_port_t'
12: end
selinux_policy_fcontext is unable to execute properly on CentOS 8 Stream. The same code works fine on RHEL 8 and CentOS 8 (non-Stream) such as CentOS 8 8.5.2111. and 8.0.1905.
Chef Infra Client, version 17.9.42
CentOS 8 Stream installed from ISO CentOS-Stream-8-x86_64-20220202-dvd1.iso
or CentOS 8 converted to CentOS 8 Stream.
# rpm -qa | grep centos
centos-gpg-keys-8-4.el8.noarch
centos-stream-release-8.6-1.el8.noarch
centos-stream-repos-8-4.el8.noarch
Steps to reproduce the behavior:
Primary process using a native CentOS 8 Stream install:
Alternative process using a CentOS 8 to CentOS 8 Stream conversion:
dnf --disablerepo '*' --enablerepo=extras swap centos-linux-repos centos-stream-repos
dnf distro-sync
This error is observed when deploying the same cookbook on:
Recipe: nginx_repo::deploy
* selinux_policy_fcontext[/repo(/.*)?] action addormodify
================================================================================
Error executing action `addormodify` on resource 'selinux_policy_fcontext[/repo(/.*)?]'
================================================================================
Chef::Exceptions::InvalidCookbookVersion
----------------------------------------
'8' does not match 'x.y.z' or 'x.y'
Cookbook Trace: (most recent call first)
----------------------------------------
/var/chef/cache/cookbooks/selinux_policy/libraries/helpers.rb:73:in `semanage_options'
/var/chef/cache/cookbooks/selinux_policy/resources/fcontext.rb:41:in `block (2 levels) in class_from_file'
/var/chef/cache/cookbooks/selinux_policy/resources/fcontext.rb:40:in `block in class_from_file'
/var/chef/cache/cookbooks/selinux_policy/resources/fcontext.rb:10:in `block in class_from_file'
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/nginx_repo/recipes/deploy.rb
97: selinux_policy_fcontext "#{http_dir}(/.*)?" do
98: secontext 'httpd_sys_content_t'
99: end
100:
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/nginx_repo/recipes/deploy.rb:97:in `block in from_file'
selinux_policy_fcontext("/repo(/.*)?") do
action [:addormodify]
default_guard_interpreter :default
declared_type :selinux_policy_fcontext
cookbook_name "nginx_repo"
recipe_name "deploy"
secontext "httpd_sys_content_t"
file_type "a"
end
System Info:
------------
chef_version=17.9.42
platform=centos
platform_version=8
ruby=ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux]
program_name=/usr/bin/chef-client
executable=/opt/chef/bin/chef-client
* service[nginx] action reload (up to date)
Running handlers:
[2022-02-03T15:24:06-07:00] ERROR: Running exception handlers
Running handlers complete
[2022-02-03T15:24:06-07:00] ERROR: Exception handlers complete
Infra Phase failed. 18 resources updated in 01 minutes 16 seconds
[2022-02-03T15:24:06-07:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2022-02-03T15:24:06-07:00] FATAL: ---------------------------------------------------------------------------------------
[2022-02-03T15:24:06-07:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2022-02-03T15:24:06-07:00] FATAL: ---------------------------------------------------------------------------------------
[2022-02-03T15:24:06-07:00] FATAL: Chef::Exceptions::InvalidCookbookVersion: selinux_policy_fcontext[/repo(/.*)?] (nginx_repo::deploy line 97) had an error: Chef::Exceptions::InvalidCookbookVersion: '8' does not match 'x.y.z' or 'x.y'
For that -f -l (of -f l for RHEL>7) is needed.
@BackSlasher this one is going to be a more significant change to how the module provider works. Right now it can only handle a single .te file, which is not enough in the case where you need to build a fully fledged semodule, including interfaces and file types.
For this I propose to re-factor the provider to support the usage of cookbook files that contain the actual .te/.fc/.if content, furthermore I will also move the actual compilation into it's own folder within the Chef.temp folder such as to exclude any accidents if anyone needs to create more than one module.
I'm seeking some clarification on the allow_disabled
property that I referenced in my closed bug report here: #152
For some background, we had an issue where we enabled selinux with a custom policy module to allow access for an application. Since the allow_disabled
property by default prevents compiling policy modules unless selinux is enabled (as in, selinux has been enabled and the server has subsequently been rebooted) our policy module was not compiled/enabled until later. This gap in time resulted in our audit logs being pummeled and subsequently forwarded to an rsyslog server and causing some network contention.
I'm curious if the behavior of the allow_disabled
property is reversed from its true intent. Is there a reason that, by default, an admin would want to forego compiling a module until after enabling selinux? Doing so would always create a scenario where applications would function poorly/unexpectedly (in the case of enforcing mode) in the time between rebooting a server to enable selinux and chef-clienting to compile the module.
I think it is bad practise to define methods directly in Chef::Provider
. You should define them in a module specific to this cookbook and then include them in the providers. It would also allow community cookbook writers to put this in their recipes.
include SELinuxPolicy::Helpers
include_recipe 'selinux_policy::install' if use_selinux
They wouldn't want to include the install recipe unconditionally. If they don't include it at all, the resources will break when SELinux is enabled but the packages are missing.
metadata.rb says that amazon linux is supported, but install recipe doesnt' have a chance to succeed on Amazon Linux
Berkshelf has had to peg my version of selinux_poilcy back to 0.92 because depending on yum ~> 3.9.0 is too strict. Remember that yum is a very widely used cookbook. Please change this to ~> 3.9.
However, I question the need for the dependency anyway. I see that it's to run yum::fedora_yum_compat
and that was added for Fedora but that has nothing specifically to do with this cookbook. If Chef doesn't work with dnf yet then that should be fixed and users who want to use Fedora in the meantime should just add this recipe to their own run lists. The yum cookbook even says as much in the README.
This recipe should be 1st on a Fedora runlist.
When a secontext has multiple ports, the not_if/only_if commands don't recognize it correctly:
/usr/sbin/semanage port -l | grep -P 'http_cache_port_t'
http_cache_port_t tcp 3128, 8080, 8118, 8123, 10001-10010
http_cache_port_t udp 3130
#When using the following resource
selinux_policy_port 8080 do
protocol 'tcp'
secontext 'http_cache_port_t'
end
#This is what the not_if looks like
/usr/sbin/semanage port -l | grep -P 'http_cache_port_t\s+tcp\s+8080'
#(no matches)
#It needs to look something like this:
/usr/sbin/semanage port -l | grep -P 'http_cache_port_t\s+tcp\s+([0-9-]+,\s+)*8080(,\s+[0-9-]+)*$'
It'll also mistakenly do partial matches:
/usr/sbin/semanage port -l | grep -P 'http_cache_port_t\s+tcp\s+312'
http_cache_port_t tcp 3128, 8080, 8118, 8123, 10001-10010
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.