It looks like we have nslcd in the contrib section. I tried creating an ebuild for nslcd in my overlay but it's not working :( dev strict # semodule -b base.pp -i $(ls *.pp | grep -v base.pp) libsepol.permission_copy_callback: Module nagios depends on permission use in class db_table, not satisfied (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! dev strict # semodule -i nslcd.pp libsepol.permission_copy_callback: Module nslcd depends on permission epollwakeup in class capability2, not satisfied (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! I'd appreciate tips for dealing with these errors so I can help write some policies.
my ebuild is in http://git.overlays.gentoo.org/gitweb/?p=dev/prometheanfire.git
Created attachment 318200 [details] audit log for starting the daemon
First check if the policy you have loaded is of at least the same version as the one that you have built for nslcd. Your overlay suggests BASEPOL="2.20120215-r13" so your base policy should already be at rev13 (and also loaded). The command to load the entire policy you gave failed on nagios: """ libsepol.permission_copy_callback: Module nagios depends on permission use in class db_table, not satisfied (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! """ In this case, this sais that the nagios module has dependencies on other policy modules which eventually cause it to need the "use" privilege for db_table class. This sounds like postgresql stuff, although I can't find a direct reference to postgresql interfaces in the nagios module. So two things to look at: (1.) Does /sys/fs/selinux/class/db_table/perms list "use" as a privilege for the db_table class? (2.) If you "grep -v nagios" in the semodule command, what is the next error you get? If the "use" privilege is indeed needed, we might need to update the policy/flask/access_vectors file to support it too, but I don't even notice this on the refpolicy (development branch) so it would mean that it's a non-gentoo-related issue. I'm not sure about this then though. Regardless, we should first focus on getting "semodule -b base.pp -i $(ls *.pp | grep -v base.pp | grep -v unconfined.pp)" working properly (with or without nslcd.pp).
can't reload modules still, just made sure everything was installed as it should be (as far as I can tell).
Created attachment 318360 [details] modules and reload line
Created attachment 318368 [details] nslcd patch to allow connect to ldap
Seems logical that nslcd can connect to LDAPs, since it is his main functionality. You might want to look at the commit history for nslcd.te to find out if there was some discussion on it before, since I would find it strange that this isn't part of the existing policy.
submitted patch upstream
It'll also be in rev15
in hardened-dev overlay
In main tree, ~arched
stabilized
