Code Monkey home page Code Monkey logo

selinux_policy's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

selinux_policy's Issues

resource 'execute[selinux-fcontext-redis_conf_t-add]'

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

STDERR: find: paths must precede expression: 2>/dev/null

Cookbook version

2.3.2, 2.3.3

Chef-client version

14.10.9

Platform Details

CentOS 7

Scenario:

selinux_policy_fcontext '/var/www/vhosts/application/var(/.*)?' do
  secontext 'httpd_sys_rw_content_t'
end

Steps to Reproduce:

This cookbook is used with Packer and chef-solo provider to build an Amazon Machine Image (AMI).

Expected Result:

The cookbook should converge with no issues, as it did up until very recently.

Actual Result:

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?

No resource or method named `shell_out!' for `Chef::Provider::SelinuxPolicyFcontext ""

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:

  1. OS: Centos6.6
  2. Chef client: 11.18.6
  3. selinux is enforcing and targeted.
  4. semanage setsebool and getsebool all work when called from the shell

Any ideas?

Better check for which folder to relabel possible?

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).

setsebool - No such file or directory

Cookbook version

2.1.0

Chef-client version

14.2

Platform Details

RHEL 7

Scenario:

I have the following resource to enable support for NGINX

selinux_policy_boolean 'httpd_can_network_connect' do
  value true
end

Expected Result:

This works every time.

Actual Result:

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

directory_source of selinux_policy_module does seem to work…

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:

  • Error executing action run on resource 'execute[semodule-install-postfixvas]'
  • Error executing action install on resource 'selinux_policy_module[postfixvas]'
    as the run of /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)
    But there are:
[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)

semanage login - new mapping

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!

selinux_policy_boolean not persistent by default

Cookbook version

2.3.4

Chef-client version

13.6.4

Platform Details

Centos 7

Scenario:

Setting a boolean with selinux_policy_boolean is not persistent by default.

Steps to Reproduce:

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

Expected Result:

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).

Actual Result:

If the machine is reboot selinux boolean settings are lost.

Thanks in advance for your time.

RHEL 8 support?

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']

Remove .rubocop.yml with Dangerfile

πŸ—£οΈ Foreword

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.

πŸ‘» Brief Description

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.

Run restorecon unconditionally

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?

Continuous Integration Testing

One for the ChefConf hack day if you're around.

  • Travis (has selinux disabled by default)
  • CircleCI?
  • Another?

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.

[BUG] CentOS 7.x find 4.5.11 has a fd leak in -execdir - Too many open files

Cookbook Version

2.0.1+

Chef-client version

12.x -> 14.x

Platform Details

CentOS 7.x Current

Scenario:

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

Steps to Reproduce:

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

Expected Result:

restorecon works

Actual Result:

[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)

In Chef 13 this will become an error: Option port must be a kind of [Integer]!

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

Amazon linux

This doesn't appear to run on Amazon Linux, which essentially is another RHEL/Centos.

------------

Unknown distro, cannot determine required package names
Cookbook Trace:

/var/chef/cache/cookbooks/selinux_policy/resources/install.rb:30:in `block in class_from_file'
Resource Declaration:

In /var/chef/cache/cookbooks/selinux_policy/recipes/install.rb

1: selinux_policy_install 'install'
Compiled Resource:

Declared in /var/chef/cache/cookbooks/selinux_policy/recipes/install.rb:1:in `from_file'

selinux_policy_install("install") do
action [:install]
default_guard_interpreter :default
declared_type :selinux_policy_install
cookbook_name "selinux_policy"
recipe_name "install"
end

System Info:

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

semodule-install not idempotent

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

ArgumentError with version 2.2.0

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

Update Changelog

πŸ—£οΈ Foreword

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.

πŸ‘» Brief Description

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.

ERROR: incompatible character encodings: UTF-8 and ASCII-8BIT

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

sh: semanage: command not found

Cookbook version

latest

Chef-client version

14.2

Platform Details

RHEL 7.5

Scenario:

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.

Steps to Reproduce:

Use chef-client 14.2, run from cron (we use sudo seems to inherit env and run just fine that way).

Expected Result:

Chef client to run cleanly

Actual Result:

  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'

shellout to find is traversing /proc

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.

fcontext is painfully slow

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.

Update builds to be parallel

πŸ—£οΈ Foreword

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.

πŸ‘» Brief Description

As part of our build process we should build each possible operating system separately

  1. Ensure you have dokken setup and working:
  2. dokken: aliased to KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen
  3. run dokken list, you should see a list of builds with dokken as the provider
  4. download: https://github.com/sous-chefs/repo-management/blob/master/scripts/circleci_maker.rb and make this executable
  5. run: dokken list -j | ./circleci_maker.rb > .circleci/config.yml

Issue sprouted from sous-chefs/meta/issues/112. If not applicable then issue should be closed.

selinux_policy_module installation disallowed if selinux is disabled

πŸ‘» Brief Description

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.

πŸ₯ž Cookbook version

2.4.3

πŸ‘©β€πŸ³ Chef-Infra Version

Chef Infra Client: 16.16.13

🎩 Platform details

Oracle Enterprise Linux 6/7

Steps To Reproduce

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.

πŸš“ Expected behavior

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.

Notifies new_resource causes issues

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.

copy an selinux context

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

Expected behavior when port is defined as part of a range

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

SE Port Management Fails on CentOS 8

πŸ‘» Brief Description

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.

πŸ₯ž Cookbook version

selinux_policy 2.3.4

πŸ‘©β€πŸ³ Chef-Infra Version

Chef Infra Client: 15.6.10

🎩 Platform details

$ 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

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.

πŸš“ Expected behavior

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

πŸš“ Actual behavior

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

βž• Additional context

There's two potential things here as a result of moving to CentOS 8:

  1. There is --protocol flag for the semanage command the library helpers are trying to use, so we're erroring out there.
  2. When troubleshooting, if I drop the --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!

Run latest cookstyle

πŸ—£οΈ Foreword

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.

πŸ‘» Brief Description

Chef have released updated cookstyle rules, we should therefore run the auto fix against the cookbook

  1. Ensure you are on the latest stable chef-workstation
  2. Run cookstyle -a

Issue sprouted from sous-chefs/meta/issues/111. If not applicable then issue should be closed.

selinux_policy_port Error

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

CentOS 8 Stream: selinux_policy_fcontext: Chef::Exceptions::InvalidCookbookVersion '8' does not match 'x.y.z' or 'x.y'

πŸ‘» Brief Description

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.

πŸ₯ž Cookbook version

  • selinux_policy (2.4.3)

πŸ‘©β€πŸ³ Chef-Infra Version

Chef Infra Client, version 17.9.42

🎩 Platform details

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

Steps to reproduce the behavior:

Primary process using a native CentOS 8 Stream install:

  1. Install CentOS 8 Stream on a node from dvd
  2. Bootstrap with Chef
  3. Attempt to use a coobkook that modifies a single directory using selinux_policy_fcontext
  4. Observe failure (see below)

Alternative process using a CentOS 8 to CentOS 8 Stream conversion:

  1. Install CentOS 8 (non-Stream) node
  2. Bootstrap with Chef
  3. Execute cookbook with selinux_policy_fcontext and observe success
  4. Convert CentOS 8 to CentOS 8 Stream with
dnf --disablerepo '*' --enablerepo=extras swap centos-linux-repos centos-stream-repos
dnf distro-sync
  1. Attempt to use a coobook that modifies a single directory using selinux_policy_fcontext
  2. Observe failure (see below)

πŸš“ Expected behavior

  • On Centos 8, RHEL 8, etc, it should modify the SELinux file context of a directory and proceed without error.

βž• Additional context

This error is observed when deploying the same cookbook on:

  • CentOS 8.5.2111 node converted to CentOS 8 Stream
  • CentOS 8.0.1905 node converted to CentOS 8 Stream
  • CentOS 8 Stream installed using CentOS-Stream-8-x86_64-20220202-dvd1.iso
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'

Refactor cookbook to use files, instead of 'content' blocks for semodule building

@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.

Clarification on `allow_disabled` resource property

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.

Helpers should be in a cookbook-specific 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.

Dependency on yum is too strict

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.

selinux_policy_port doesn't correctly detect if existing mappings exist

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.