Using audit2allow, I was able to create a policy module for selinux: audit2allow -i /var/log/audit/audit.log -M mysqld (creates mysqld.pp and mysqld.te) I want to distribute this to all my puppet clients. I can easily put this file in /etc/selinux/targeted/modules/active/modules But even after reboot, although I can see the module listed: semodule -l ... it doesn''t seem to actually work, it continues to deny. I know the policy module works, so I''m trying to figure out what step I''m missing here. Has anyone done this yet? johnn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnny Tan wrote:> Using audit2allow, I was able to create a policy module for > selinux: > > audit2allow -i /var/log/audit/audit.log -M mysqld > (creates mysqld.pp and mysqld.te) > > I want to distribute this to all my puppet clients. > > I can easily put this file in > /etc/selinux/targeted/modules/active/modules > > But even after reboot, although I can see the module listed: > semodule -l > > ... it doesn''t seem to actually work, it continues to deny. > I know the policy module works, so I''m trying to figure out > what step I''m missing here. > > > Has anyone done this yet?What version/distro of Linux are you using? With regards to installing the module, we run the following commands to take a .te file and generate and install the resulting module: /usr/bin/checkmodule -M -m -o foo.mod foo.te /usr/bin/semodule_package -o foo.pp -m foo.mod /usr/sbin/semodule -i foo.pp We are using CentOS5 and what we are doing is creating a .te file with the output from audit2allow and we have an exec clause that runs a script which will compile the .mod and .pp file, then install the .pp file and cleanup the .mod/.pp files. The exec clause has a subscribe option so it will only get run again if the .te file is updated. What we need to do to improve things is add some calls to semanage to add more granular access as needed. Right now for example, we have one MySQL server talk to a remote server through an SSH tunnel. As such, it is not using TCP port 3306, which is covered by the targeted policy. Using a .te file, we have a line like this: allow mysqld_t port_t:tcp_socket name_connect; which allows the mysqld daemon to connect to any TCP port. Really, this is more open than we want to allow. We need to change to using .te files to add missing capabilities but using semanage to modify privs for things like ports, users and file contexts.> johnn > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >- -- David Goldsmith -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWzce417vU8/9QfkRAl7AAJ9TresmZVM4auhGp7k3f8v3jrJy8gCfdclk s9j8I1yJwCP1eB5HY0XpeGg=9C4z -----END PGP SIGNATURE-----
David Goldsmith wrote:> What version/distro of Linux are you using?Also CentOS 5.1 with latest stable puppet.> With regards to installing the module, we run the following commands to > take a .te file and generate and install the resulting module: > > /usr/bin/checkmodule -M -m -o foo.mod foo.te > /usr/bin/semodule_package -o foo.pp -m foo.mod > /usr/sbin/semodule -i foo.pp > > > We are using CentOS5 and what we are doing is creating a .te file with > the output from audit2allowIf you use the -M option to audit2allow, do you still need to do the checkmodule and semodule_package steps? It seems to work for me to just do "audit2allow -M foo" (which creates both .te and .pp files) and then "semodule -i foo.pp" if I''m installing manually.> and we have an exec clause that runs a > script which will compile the .mod and .pp file, then install the .pp > file and cleanup the .mod/.pp files. The exec clause has a subscribe > option so it will only get run again if the .te file is updated.This sounds like it might work... haven''t used the exec command, but will look into it. I thought there might have been a native way to do this. Like somehow restart selinux or re-load its policy stuff.> allow mysqld_t port_t:tcp_socket name_connect; > > which allows the mysqld daemon to connect to any TCP port. Really, this > is more open than we want to allow.Good point... never thought of that. I''ll have to look further into semanage as well. Thanks for the tips. johnn
Hi Johnny: I am NOT an SELinux guru. Nor a puppet one for that matter.> If you use the -M option to audit2allow, do you still need > to do the checkmodule and semodule_package steps? It seems > to work for me to just do "audit2allow -M foo" (which > creates both .te and .pp files) and then "semodule -i > foo.pp" if I''m installing manually.You don''t need to use the checkmodule or semodule_package steps if you are compiling your policies via the audit2allow -M method. That''s how I initially started distributing policies via puppet. However, I ran into many cases where my first audit2allow policy would allow read access to a file, and then SELinux would spit out more audit logs because now write access was needed. When I got around to manually updating the .te files (instead of creating a completely new .pp file for write access to the same file), I used the checkmodule and semodule_package commands to create the new .pp files for distribution. David seems to be saying his puppet module monitors the .te files for changes, and his exec calls go through the checkmodule and semodule_package steps automatically. I''ve been doing those by hand and letting puppet simply distribute the .pp files. I think I prefer David''s method.>> and we have an exec clause that runs a >> script which will compile the .mod and .pp file, then install the .pp >> file and cleanup the .mod/.pp files. The exec clause has a subscribe >> option so it will only get run again if the .te file is updated. > > This sounds like it might work... haven''t used the exec > command, but will look into it. I thought there might have > been a native way to do this. Like somehow restart selinux > or re-load its policy stuff.There has been talk of working on native selinux support, but to my knowledge it doesn''t yet exist. I''d imagine it would get complicated quite fast.> Good point... never thought of that. I''ll have to look > further into semanage as well. Thanks for the tips.I''ve attached my (very basic) selinux module if you want to see something that works for me on RHEL5 just to distribute .pp policies and let me move on to other issues. If you develop something better, especially with semanage, I''m sure plenty of us would love to hear about it. Good luck, Boone _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Boone Bradley wrote:> Hi Johnny: > > I am NOT an SELinux guru. Nor a puppet one for that matter.Ditto :).> David seems to be saying his puppet module monitors the .te files for > changes, and his exec calls go through the checkmodule and > semodule_package steps automatically. I''ve been doing those by hand and > letting puppet simply distribute the .pp files. I think I prefer > David''s method.Ah, got it. Makes perfect sense! I like this model also. David: Would you be willing to share your selinux module?> I''ve attached my (very basic) selinux module if you want to see > something that works for me on RHEL5 just to distribute .pp policies and > let me move on to other issues. If you develop something better, > especially with semanage, I''m sure plenty of us would love to hear about > it.Boone: This was extremely helpful, thanks! I''m going to re-work it to follow David''s model (unless he sends his first), but it gave me an immediate example of how to use exec. Much appreciated. johnn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johnny Tan wrote:> Boone Bradley wrote: >> Hi Johnny: >> >> I am NOT an SELinux guru. Nor a puppet one for that matter. > > Ditto :). > > >> David seems to be saying his puppet module monitors the .te files for >> changes, and his exec calls go through the checkmodule and >> semodule_package steps automatically. I''ve been doing those by hand and >> letting puppet simply distribute the .pp files. I think I prefer >> David''s method. > > Ah, got it. Makes perfect sense! I like this model also. > > David: Would you be willing to share your selinux module?Attached. We are in the process of doing a full roll-out of a new datacenter with the goal of using Puppet for everything. We are trying to develop puppet modules that are free of site-specific info and then putting all of our site-specific configs under a local class. This will enable us to provide modules we develop back to the community without needing to sanitize them. I have included our selinux module and a slice of our local module showing how the selinux module is called for selinux changes needed by some of our PHP stuff. - -- David Goldsmith -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHX1tU417vU8/9QfkRAn7IAKCIFOvjbIn/oSZO8iUZOJ8K16YdGACgluJd GcR9emmVa/VRIMuailtDQxM=qcFb -----END PGP SIGNATURE----- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
David Goldsmith wrote:> Attached. We are in the process of doing a full roll-out of a new > datacenter with the goal of using Puppet for everything. We are trying > to develop puppet modules that are free of site-specific info and then > putting all of our site-specific configs under a local class. This will > enable us to provide modules we develop back to the community without > needing to sanitize them.So, even for your regular packages like, say, mysql -- you have a mysql module which is just the package(s) and service, then in the local module, you have a mysql section which references the my.cnf, mysqld.te, etc.?> I have included our selinux module and a slice of our local module > showing how the selinux module is called for selinux changes needed by > some of our PHP stuff.Really good, valuable example -- thanks for sharing it! I''ve already adapted it for my own use. Hopefully, I''ll have some to share too (soon), as we are also rolling out an entire colo of puppeted machines. johnn
On Dec 12, 2007 4:48 PM, Johnny Tan <linuxweb@gmail.com> wrote:> So, even for your regular packages like, say, mysql -- you > have a mysql module which is just the package(s) and > service, then in the local module, you have a mysql section > which references the my.cnf, mysqld.te, etc.?Pretty much, that is what we''re doing. MySQL in particular has: package for client systems. packages for server systems. mysql user and group. the aforementioned selinux stuff specific for mysql. service for mysql. defined type for mysql config file, my.cnf. We have similar for pretty much all the different services we''re using - DNS, SMTP, NTP, Apache, etc. We wanted to keep our configuration simple for ease of maintenance. If it isn''t obvious, I work with David :-).> Really good, valuable example -- thanks for sharing it! I''ve > already adapted it for my own use. Hopefully, I''ll have some > to share too (soon), as we are also rolling out an entire > colo of puppeted machines.I just finished updating our users module to behave differently and will be posting that soon. It is really just a modification of the virt_all_users stuff in the Puppet Best Practices, with some modifications to better handle users that might have a different group on certain servers.
Joshua Timberman wrote:> On Dec 12, 2007 4:48 PM, Johnny Tan <linuxweb@gmail.com> wrote: >> So, even for your regular packages like, say, mysql -- you >> have a mysql module which is just the package(s) and >> service, then in the local module, you have a mysql section >> which references the my.cnf, mysqld.te, etc.? > > Pretty much, that is what we''re doing. MySQL in particular has: > > package for client systems. > packages for server systems. > mysql user and group. > the aforementioned selinux stuff specific for mysql. > service for mysql. > defined type for mysql config file, my.cnf.What I was specifically trying to find out was do you guys separate the above into two modules, like you did for selinux module? I.e., mysql module would have: > package for client systems. > packages for server systems. > mysql user and group. > service for mysql. While your local module, in the mysql section, would have: > the aforementioned selinux stuff specific for mysql. > defined type for mysql config file, my.cnf. The way David phrased it, it sounded like you guys separated out all the local stuff. So I was trying to see another example of this besides the selinux one he posted. One last thing, in the local module that David posted, the selinux.pp has this line: class local::selinux { What does the :: mean? Is it simply a way to separate two words -- i.e., you could''ve said local_selinux, or is there some other meaning? johnn
On Dec 14, 2007 9:08 AM, Johnny Tan <linuxweb@gmail.com> wrote:> What I was specifically trying to find out was do you guys > separate the above into two modules, like you did for > selinux module? > > I.e., mysql module would have: > While your local module, in the mysql section, would have: > > The way David phrased it, it sounded like you guys separated > out all the local stuff. So I was trying to see another > example of this besides the selinux one he posted.The mysql module has: class mysql { class mytop { } class client inherits mysql { } class server inherits mysql { } } define mysql::config ( ) { } The "local" module with our site/company specific configuration calls the mysql::config defined type with our specific settings. This way we can provide a tarball of modules/mysql/* that doesn''t have our site information in it. The selinux stuff for mysql is under class mysql::server at the moment as separate exec and file types.> One last thing, in the local module that David posted, the > selinux.pp has this line: > class local::selinux { > > What does the :: mean? Is it simply a way to separate two > words -- i.e., you could''ve said local_selinux, or is there > some other meaning?This is a class namespacing syntax. This way, we could have an "selinux" subclass for several different modules. mysql::selinux apache::selinux local::selinux That keeps each particular ''selinux'' subclass within the scope of the parent class. We do this with client and server subclasses as well. mysql mysql::client mysql::server ntp ntp::client ntp::server ... etc Though typically, the base class name, mysql or ntp above, is used on clients, depending on the module. Hope that is clear as mud :-). -joshua