There is no rspec for permissive defined type

Hello:

Currently, this module always manages the selinux package. Can we add an override so we can manage it externally?

given the major differences between 0.2.6 and master, I'd like to ask if we can cut a new release/tag (maybe 0.3.0 given those differences) so that setting both mode and type is possible.

Thanks in advance!

In Fedora 23, after the switch to python3, policycoreutils-python has generally been renamed to policycoreutils-python3. Also, most of the utilities (including the semanage command) have moved to policycoreutils-python-utils, which is probably the better package name to target.

(Yes, they're named inconsistently. I have no good explanation, this is just what it is. 😉 )

On every puppet run my custom modules go through the entire build process

Operating System: Centos 6
Facter Version: 3.0.2

before puppet run: semodule -l | grep localscan
localscan_local 1.0

Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for web1s.us-east.aws.chesapeakebay.net
Info: Applying configuration version '1443211431'
Notice: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-checkloaded]/returns: executed successfully
Info: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-checkloaded]: Scheduling refresh of Exec[localscan_local-buildmod]
Notice: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-buildmod]: Triggered 'refresh' from 1 events
Info: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-buildmod]: Scheduling refresh of Exec[localscan_local-buildpp]
Notice: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-buildpp]: Triggered 'refresh' from 1 events
Info: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-buildpp]: Scheduling refresh of Exec[localscan_local-install]
Notice: /Stage[main]/Cis_selinux::Localscan/Selinux::Module[localscan_local]/Exec[localscan_local-install]: Triggered 'refresh' from 1 events
....

I bumbed in to an issue that another selinux module provides policycoreutils-python by using ensure_packages() function. However, as this module is not using the function, in some cases ensure_packages() version is fired first and manifests/package.pp:24 will emit an error about the duplicate declaration.

I was able to work around the problem by defining selinux::manage_package: false, but should we also use ensure_packages() in this module to fix the issue without workaround?

Hi,
I am puzzling with an issue that the order of file-context entries matters, where the last has precedence.
Because environments are constant in flux it happened that contexts are added in the 'wrong' order. For example, I added an fcontext for /data/log/mysql before /data/log. The effect is that the /data/log/mysql directory is getting the wrong context.
If I manually change the ordering, the context is applied correctly.

The puzzle is how do I puppet-fix this correct. Is am thinking in the direction of an Exec[] which (reverse) sorts the file /etc/selinux/targeted/contexts/files/file_contexts.local. However, this feels dirty and wrong. Any sugestions?

Regarding a comment from Pull Request #73

It appears RedHat decided to split selinux into the selinux-policy and selinux-policy-devel packages for RHEL 7, and put /usr/share/selinux/devel/Makefile in the devel package. I assume this would also affect CentOS 7 and recent versions of Fedora as well.

The .te file gets created but no .mod or .pp file in /usr/share/selinux.

I didn't notice it until recently because the .mod and .pp files were already there, but I think the addition of the prefix caused it to attempt to install the module under a new name and then start giving puppet errors.

RHEL 6 seams to have the Makefile in selinux-policy and as best I can tell there is no selinux-policy-devel for RHEL 6.

Thoughts on the best way to fix this?

When upgrading to 0.3.0 from 0.2.3 on my CentOS 7.2 server, I had this error:

Failed to call refresh: make -f /usr/share/selinux/devel/Makefile local_mypol.pp returned 2 instead of one of [0]

The /usr/share/selinux/devel/Makefile directory is created by package selinux-policy-devel which is not installed on my server. The module seems to require it so maybe it should be added as a dependancy ?

::module needs /usr/share/selinux/devel/Makefile which is in the selinux-policy.delel package (RHEL7).

add following line:
package { 'selinux-policy-devel': ensure => installed, }

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: puppet-3.8.7cern1-1.ai6.noarch
• Ruby: ruby-1.8.7.374-4.el6_6.x86_64
• Distribution: RedHat6 (clone, ScientificLinuxCern6)
• Module version: 0.5.0

How to reproduce (e.g Puppet code you use)

selinux::fcontext { 'selinux_usr_share_nginx':
          pathname => '/usr/share/nginx',
          restorecond_recurse => true,
          context  => "httpd_tmp_t",

What are you seeing

Error: semanage fcontext -a -f a -t httpd_tmp_t /usr/share/nginx returned 1 instead of one of [0]
Error: /Stage[main]/Eos::Servers/Selinux::Fcontext[selinux_usr_share_nginx]/Exec[add_httpd_tmp_t_/usr/share/nginx_type_a]/returns: change from notrun to 0 failed: semanage fcontext -a -f a -t httpd_tmp_t /usr/share/nginx returned 1 instead of one of [0]
Notice: /Stage[main]/Eos::Servers/Selinux::Fcontext[selinux_usr_share_nginx]/Exec[restorecond add_httpd_tmp_t_/usr/share/nginx_type_a]: Dependency Exec[add_httpd_tmp_t_/usr/share/nginx_type_a] has failures: true

I.e "semanage" is run with "-f a" (for "all" files?) - this option is not recognized in the version shipped with RHEL6 (policycoreutils-python-2.0.83-29.el6.x86_64). "man semanage" there is a bit vague and says

       -f, --ftype
              File Type.   This is used with fcontext.  Requires a file type as shown in the mode field by ls, e.g. use -d to match only directories or -- to match only regular files.

What behaviour did you expect instead

Unless the desired filetype is explicitly given to the module, would expect it to be left off from the "semanage" command line.

In config.pp you are checking for the value of the fact selinux_current_mode to see if a 'notice' that a reboot is required to fully disable selinux is logged. As of facter 2.2, that core fact no longer exists.
We're running 2015.2 and the equivalent fact in facter 3.1 is os.selinux.current_mode.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: Puppet v3.8.7
• Ruby: ruby 2.0.0p598 (2014-11-13) [x86_64-linux]
• Distribution: CentOS 7.2
• Module version: 0.4.1

How to reproduce (e.g Puppet code you use)

ensure_resource('selinux::port', { 'foo', { context => 'syslogd_port_t', protocol => 'tcp6', port => 8514 }}
ensure_resource('selinux::port', { 'foo', { context => 'syslogd_port_t', port => 8514 }}

What are you seeing

Errors from semanage command:

ValueError: Protocol udp or tcp is required
proto option is needed for add

What behaviour did you expect instead

I'd expect manifest to catch these.

Any additional information you'd like to impart

rpm -qf /usr/sbin/semanage
policycoreutils-python-2.2.5-20.el7.x86_64

semanage port interface is the same in RedHat 6.8 policycoreutils-python-2.0.83-29.el6.x86_64.

/usr/sbin/semanage: Protocol udp or tcp is required

I'm setting up a basic rule, e.g. giving Varnish the fowner capability. I've created a module with the following:

selinux::module { 'varnish_ownership':
    source   => 'puppet:///modules/varnish/selinux/varnish_ownership.te',
}

on the first run it installs it just fine:

Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/File[/usr/share/selinux/varnish_ownership.te]/ensure: defined content as '{md5}3f9c1e202f1630d82169b7c426577700'
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/File[/usr/share/selinux/varnish_ownership.te]: Scheduling refresh of Exec[varnish_ownership-buildmod]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-checkloaded]/returns: executed successfully
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-checkloaded]: Scheduling refresh of Exec[varnish_ownership-buildmod]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildmod]: Triggered 'refresh' from 2 events
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildmod]: Scheduling refresh of Exec[varnish_ownership-buildpp]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildpp]: Triggered 'refresh' from 1 events
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildpp]: Scheduling refresh of Exec[varnish_ownership-install]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-install]: Triggered 'refresh' from 1 events
Notice: /File[/usr/share/selinux/varnish_ownership.mod]/seluser: seluser changed 'unconfined_u' to 'system_u'
Notice: /File[/usr/share/selinux/varnish_ownership.pp]/seluser: seluser changed 'unconfined_u' to 'system_u'

...which is great, however on subsequent runs, it seems to be re-building and re-installing it even though the "checkloaded" exec returns successfully:

Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-checkloaded]/returns: executed successfully
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-checkloaded]: Scheduling refresh of Exec[varnish_ownership-buildmod]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildmod]: Triggered 'refresh' from 1 events
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildmod]: Scheduling refresh of Exec[varnish_ownership-buildpp]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildpp]: Triggered 'refresh' from 1 events
Info: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-buildpp]: Scheduling refresh of Exec[varnish_ownership-install]
Notice: /Stage[main]/varnish/Selinux::Module[varnish_ownership]/Exec[varnish_ownership-install]: Triggered 'refresh' from 1 events

Is this the intended behaviour? Everything works in the end, so it's not a deal-breaker, but it slows down the puppet agent significantly.

This is running on a CentOS 7.0 VM with Puppet v3.6.2.

Thanks!

Is it possible to tag a new release for Github and Forge?

Thanks! 👍

I now get this error on puppet: 3.8.5

Could not retrieve catalog from remote server: Error 400 on SERVER:
The parameter 'mode' is declared more than once in the parameter list at 
/etc/puppet/environments/xxx/modules/selinux/manifests/init.pp:33:3 on node xxxxxx

Is there a reason $mode is declared twice here:
https://github.com/jfryman/puppet-selinux/blob/v0.3.0/manifests/init.pp#L33

Hi,

It seems there is no hiera support despite the create_resources declaration in the init.pp manifest.

1. The following Hiera entry is not seen by the module:

selinux_booleans:
  'httpd_can_network_relay' : {}

1. However, adding the following code in the init.pp (which is just a hiera_hash declaration) makes it visible again:

$selinux_boolean_list = hiera('selinux_booleans', undef)
if $selinux_booleans_list {
    create_resources ( 'selinux::boolean', hiera_hash('selinux_booleans') )
}

The first declaration is just a simple
And you also can add some default parameters....

I am running Puppet v 4.5.2 on CentOS7.

Are you aware about this? Do you need a PR?

Regards,
Rudy

Tried a "working" config out on a new host, and got an interesting error. It tries to run restorecon against a path that doesn't exist (yet). The idea of restorecon would be to "fix" existing files, so we should check for the existence of the path before trying to run restorecon against it. Perhaps something like:

[ -e "${filepath}" ]

It would be great to get a new release of the module. I prefer to use forge modules whenever possible and the current release still contains #80 which makes it unusable.

Hi, I am using your module from puppetforge to deploy a simple selinux policy.te file to many nodes like so:

  selinux::module { 'puppetlocal':
    ensure => present,
    source => 'puppet:///modules/site/selinux/puppetlocal.te',
  }

All agents where this is applied fail with:

'undef' from left of operand of 'in' expression is not a string at <modulepath>/selinux/manifests/module.pp:38

I am not using any references or resources from your module anywhere else for these nodes manifests. I am not following why there needs to be a global param defined to set the selinux policy. Shouldn't this be a module param? Can you provide any advice?

Thanks!

Affected Puppet, Ruby, OS and module versions/distributions

• Module version: 0.5.1-rc0

How to reproduce (e.g Puppet code you use)

add a selinux::module resource

What are you seeing

the resource creates/manages a file in /usr/share/selinux. According FSH standard /usr is Secondary hierarchy for read-only user data;.

In /usr (excluding /usr/local) I only expect files managed by the systems package manager.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure

What behaviour did you expect instead

The puppet managed file should be placed somewhere in /var. Maybe in some folder in puppets $vardir or whatever best practice is.

references

• Depends on #178 (Redesign selinux::module parameters)

We are using your SELinux module as a dependency for our new [https://forge.puppetlabs.com/mojolingo/openshift](OpenShift module). As such, would you consider making a release of this module available on Puppet Forge so other users can resolve dependencies automatically? I'm happy to help do the packaging if desired.

So I ended up having some production selinux issues, and I started to use the "module" installer that is in this puppet... module. Ugh, terminology.

Anyway, the way it's implemented now, it checks /usr/share/selinux for files and, if present, doesn't seem to do anything. However, it's entirely possible to un-install a module and then that gets this guy out of sync.

For example:

puppet apply foo-module-install.pp
semodule -r foo-module
puppet apply foo-module-install.pp

On the second run, the module won't be reinstalled, as best I can tell.

Some check with semodule -l and a grep probably needs to happen, I guess? But that might get hard.

Amazon Linux is not detected and unfortunately doesn't work by default. A bit of hacking around and it works fine.

osfamily => Linux
operatingsystem => Amazon

Are the facts.

I am seeing the following error:

err /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns change from notrun to 0 failed: semanage port -a -t ssh_port_t -p tcp 1022 returned 1 instead of one of [0]
err Puppet  semanage port -a -t ssh_port_t -p tcp 1022 returned 1 instead of one of [0]
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns ValueError: Could not commit semanage transaction
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns libsemanage.semanage_reload_policy: load_policy returned error code 2.
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns /sbin/load_policy: Can't load policy: No such file or directory
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.29: No such file or directory
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.29, searching for an older version.
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns libsemanage.semanage_reload_policy: load_policy returned error code 2.
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns /sbin/load_policy: Can't load policy: No such file or directory
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.29: No such file or directory
notice  /Stage[main]/Lark::Profile::Ssh/Selinux::Port[allow-ssh-port-selinux]/Exec[add_ssh_port_t_1022]/returns SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.29, searching for an older version.

With the following puppet code (snippet):

  # SELinux Stuff                                                               
  # semanage port -a -t $type -p $port                                          
  # We may need to add some "conditionals" around this in the future            
  if hiera('selinux_enabled', false) {                                          
    selinux::port { 'allow-ssh-port-selinux':                                   
      context  => 'ssh_port_t',                                                 
      protocol => 'tcp',                                                        
      port     => $port,                                                        
    }
  }                                                                     

I only get the error the first time it runs, but it does succeed. I haven't really dug into the code yet, but I am seeing this consistently enough (every time recently) that I thought I should report it. :)

NOTE: I am building a CentOS 7 VM (droplet) at Digital Ocean.

Hi,

Although it is not a technical issue, I do not understand why the module in the forge is not updated regularly.
We miss some fixes if we want to get this module through the forge.

Regards

PS: same concern with other voxpopuli modules

As of 0.4.0 the fcontext parameter pathname is passed directly to grep in order to detect if the path is already defined as a context. Unfortunately, this detection fails if the pathname contains square brackets used in the path expression itself. Because these grep-interpreted characters are not escaped, they will be treated as actual pattern modifiers by grep rather than as literal characters.

An example is my pathname /var/lib/trac/projects/[^/]+(/.*)? which should be escaped prior to using as parameter to grep as /var/lib/trac/projects/\[^/\]+(/.*)?.

Lots of users use r10k with git rather than the forge, which is more difficult without release tags. Might you be willing to add a tag for the latest forge release, 0.2.5?

Thanks!

`selinux_custom_policy.rb:8: syntax error, unexpected ':', expecting kEND
confine kernel: 'Linux', osfamily: 'RedHat', ...
^

selinux_custom_policy.rb:8: syntax error, unexpected ',', expecting kEND
confine kernel: 'Linux', osfamily: 'RedHat', operating...
^

selinux_custom_policy.rb:8: syntax error, unexpected ',', expecting kEND
...: 'Linux', osfamily: 'RedHat', operatingsystemmajrelease: '7...
^

selinux_custom_policy.rb:8: syntax error, unexpected ',', expecting kEND
...peratingsystemmajrelease: '7', selinux: ['true', true]
^`

We get this when running this on:
OS: Centos 6.6
Ruby: 1.8.7
Facter 2.4.4
Puppet: 3.7.5
puppet-selinux: 0.3.0

I did some quick checks and it appears that the confine syntax may be wrong (at least for our version of ruby etc).. looking at the puppet docs it should be something like

confine :kernel => 'Linux'

In CentOS 7.3 it seems that the .pp file for a selinux module must be the same as the module name.
The whole prefixing scheme of the file name means that the default example no longer works.

Looks like its been raised before, we we're seeing modules try to reinstall each run.

Only way I could fix it was by setting $prefix = ''

Out modules do not have names with 'local_' prefixing in the .te

Hows this meant to work?

Just testing an upgrade of the puppet-agent on CentOS 7.

Very basic statement in my profile:

class { 'selinux':
  mode => 'permissive',
}

Getting the following error message running puppet agent -t:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, Valid types are targeted, minimum, and mls.  Received:  at /etc/puppetlabs/code/environments/puppet_agent_fixes/modules/selinux/manifests/init.pp:52:3 on node <myhostname.fqdn>

Was working fine under puppet 4.4.2 (open source).

The default prefix local_ is prefixed to module name

selmodule { "${prefix}${name}":

but this default is unintuitive. For example in the provided example

selinux::module{ 'apache':
  ensure => 'present',
  source => 'puppet:///modules/selinux/apache.te',
}

the module name inside apache.te must be

module local_apache 1.0;

so that next run finds the module from semodule --list.

If one provides a name

module apache 1.0;

in the file, then the module will be installed with name apache and selmodule tries to search for local_apache. As it doesn't find the module, it will reinstall the module on every run.

If the idea is to prefix module files in selmoduledir, we should change

selmodule { "${prefix}${name}":
  ensure       => $ensure,
  selmoduledir => $sx_mod_dir,
  syncversion  => $syncversion,
}

to

selmodule { "${name}":
  ensure       => $ensure,
  selmodulepath => "${sx_mod_dir}/${prefix}${name}",
  syncversion  => $syncversion,
}

in module.pp

@jfryman Can I ask what this line is for exactly?

https://github.com/jfryman/puppet-selinux/blob/master/spec/classes/selinux_package_spec.rb#L32
30 seems to do similar test.. so I'm trying to figure out the context it's run in.

I am getting an error when it tries to run restorecon against the path. It should probably not run restorecon against paths like this: /web/[^/]+/\.ssh(/.*)?

Notice: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]/returns: executed successfully
Info: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]: Scheduling refresh of Exec[restorecond add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]
Notice: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[restorecond add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]/returns: sh: -c: line 0: syntax error near unexpected token `('
Notice: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[restorecond add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]/returns: sh: -c: line 0: `restorecon /web/[^/]+/\.ssh(/.*)?'
Error: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[restorecond add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]: Failed to call refresh: restorecon /web/[^/]+/\.ssh(/.*)? returned 1 instead of one of [0]
Error: /Stage[main]/Webapp/Selinux::Fcontext[/web/[^/]+/\.ssh(/.*)?]/Exec[restorecond add_ssh_home_t_/web/[^/]+/\.ssh(/.*)?]: restorecon /web/[^/]+/\.ssh(/.*)? returned 1 instead of one of [0]

I like the idea of running restorecon (sortof), but it needs some help to not expose unescaped special characters to the shell or just not run if it has special characters or something?

~tommy

Hello,

I have the below code block in one of my classes and every time I run puppet agent it displays the following message:

Notice: /Stage[main]/my_ldap_auth::Selinux_ssh_homedir/Selinux::Module[selinux_ssh_homedir]/Selmodule[local_selinux_ssh_homedir]/ensure: created

Caller

   selinux::module { 'selinux_ssh_homedir':
     source => 'puppet:///modules/modpath/selinux_ssh_homedir.te',
     require => Package['policycoreutils-devel'],
   }

Here are some standard variables from facter.

os => {"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2.1511"}}

# facter  |grep selinux
selinux => true
selinux_config_mode => enforcing
selinux_config_policy => targeted
selinux_current_mode => enforcing
selinux_enforced => true
selinux_policyversion => 28

Any help would be appreciated.

Thanks!

the match in the port.pp to find if a port is already set may find a wrong match

if port 514 is already set and you want to add port 51 a match is found and the new port isn't added.

maybe add a 'grep -w ${port}' in the end?

Hi,

we get the error

Error: CentOS- is not supported at /tmp/vagrant-puppet/modules-f9727779af741867e6222f127e22141c/selinux/manifests/params.pp:35

on puppet provisioning in this box. (CentOS 6.6)

It seems the ${::operatingsystemmajrelease} variable are empty.

Used versions:

puppet --version
3.8.2

vagrant --version
Vagrant 1.7.2

VirtualBox: 4.3.28

Sincerly, Tommy

Could you please add a LICENSE file to the module, or at least mention the license in the README?

It would be nice if there was a way to disable an existing module, like:

semodule -d openvpn

maybe something like:

selinux::module{'openvpn':
    ensure => 'disabled',
}

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.x
• Ruby:
• Distribution: RHEL7
• Module version:

How to reproduce (e.g Puppet code you use)

The requirement on make for compiling a .te file to .pp is not really needed.
Doing
/usr/bin/checkmodule -M -m -o ${prefix}${name}.mod ${prefix}${name}.te && /usr/bin/semodule_package -o ${prefix}${name}.pp -m ${prefix}${name}.mod && rm -f ${prefix}${name}.mod
is sufficient.

This prevents make to be installed on the system, which is something that we want to avoid.

I was in need to add a port to an existing SElinux port group but semange -a fails with the error: "ValueError: Port xxx/xxx already defined". To work around this I copied the port.pp to mport.pp and simply changed the '-a' for the add options to '-m' for modify. It works as planned. Modified code below:

define selinux::mport (
$context,
$port,
$protocol = undef,
) {

include selinux

if $protocol {
validate_re($protocol, ['^tcp6?$', '^udp6?$'])
$protocol_switch="-p ${protocol} "
$port_exec_command = "add_${context}${port}${protocol}"
} else {
$protocol_switch=''
$port_exec_command = "add_${context}_${port}"
}

exec { $port_exec_command:
command => "semanage port -m -t ${context} ${protocol_switch}${port}",
unless => "semanage port -l|grep "^${context}.${protocol}.${port}"|grep -w ${port}",
path => '/bin:/sbin:/usr/bin:/usr/sbin',
require => Class['selinux::package']
}
}

Hello everyone,

I am looking for a maintainer for this module. I'm burnt. Quite hard. It has been a very long and tough 36 months for me both personally and professionally.

To that end, I would like to hand this over to someone who would like to take ownership of it.

For all of you who have used this module, thanks for your support and I hope you continue to find value from it. I hope to see some of you around.

❤️

@jfryman

When the pathname passed to selinux::fcontext is a regular expression, the unless clause in the exec typically fails because grep is interpreting the pathname regex, so you get semange churn with every puppet run.

A inelegant (but working) suggestion for the $filetype and default case might be something like:

$unless = "semanage fcontext -l | awk '(\$1 == \"${pathname}\" && \$4 ~ /:${context}:/) { ec = 1 } END { exit !ec }'"

Selinux module can contain .te, .if adn .fc files. See https://github.com/TresysTechnology/refpolicy/tree/master/policy/modules/services

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: not dependant
• Ruby: not dependant
• Distribution: not dependant
• Module version: 0.4.1

How to reproduce (e.g Puppet code you use)

Create selinux module with multiple file types and try to use selinux::module to manage it.

What behaviour did you get

So far I have not been able to manage single selinux module. Somehow te file ends up being directory.

What behaviour did you expect instead

I expect to get similar behaviour than spiette/selinux. See:
https://github.com/spiette/puppet-selinux/blob/master/manifests/module.pp

Put selinux module files into puppet module files/selinux and then enable module by:

  ::selinux::module { 'myselmodulename':
    ensure => 'present',
    source => "puppet:///modules/${module_name}/selinux",
  }

When using 'module' to install selinux module mode is set to disabled. (Probably because ::selinux-class is implicitly loaded by type module.)

Expected was that just installing a module would leave the selinux-mode as-is.

See comment on: 86e9599

As far as I can see the default SELinux mode is set to "disabled".

In the environment I am managing we are using SELinux in "enforcing" mode by default. I can achieve that with this module by either including the config below in baseclass.pp

class { selinux:
mode => 'enforcing'
}

Or, I can edit the manifests/params.pp file. I have opted for the latter, but it is a bit hackish and intrusive to your module.

What I can't seem to figure out is how to override this setting on a per host basis. There are hosts in the environement I am managing that we cannot have SELinux in enforcing mode, for various reasons.

What I am asking for is a way to set the default to enforcing in a proper manner, something that can be put in our baseclass.pp. And also a way to override the default setting on a per host basis.

I fail to understand why this module by default disables SELinux. Can an explanation perhaps be added to the documentation?

I've noticed that when using this module, the symlink at /etc/sysconfig/selinux to /etc/selinux/config is removed and replaced with a copy of the file. This means that the actual config file is never changed.

CentOS 6.3.

Hello:

It looks like puppet has support for selmodule and selboolean types.

https://docs.puppetlabs.com/references/latest/type.html#selboolean

https://docs.puppetlabs.com/references/latest/type.html#selmodule

Should we modify the existing classes for these to take advantage of the built-in types?