On Fri, 2008-10-17 at 16:18 +0200, Andy Warner wrote: > > > Stephen Smalley wrote: > > On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: > > > > > Stephen Smalley wrote: > > > > > > > On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > > > > > > > > > > > > > On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > > > > > > > > > > > > > > > When adding new object classes and permissions to SELinux policy is it > > > > > > necessary to re-create flask.h and av_permissions.h header files so > > > > > > that a user-space object manager can access the associated defines? If > > > > > > so, would someone give me some pointers as to how these are > > > > > > generated? > > > > > > > > > > > > > > > > > You should use the dynamic class/permission lookup facilities for any > > > > > new code. man selinux_set_mapping > > > > > > > > > > XSELinux and SE-PostgreSQL are already using it I believe. > > > > > > > > > > > > > I can't find any evidence that my version of libselinux contains the > > > selinux_set_mapping function. I am using CentOS 5.1 with libselinux > > > version 1.33.4. I have been learning RHEL 5 tends to be a bit behind > > > the times with regards to SELinux functionality. Does libselinux > > > 1.33.4 not have the dynamic class/permission lookup facilities? If it > > > does not, any advice on how to add object classes / permissions to > > > policy ? Moving to Fedora is a possibility, maybe it's worth > > > considering as this would not be the first issue we have had with an > > > outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux > > > TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does > > > not have the database related object classes /permissions in the base > > > policy where the most recent Fedora does, hence my need to add the > > > object classes /permissions in RHEL 5. > > > > > > > To use the object class/perm discovery support, you'd need to use a > > modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). > > > > Note that regardless of whether you use object class/permission > > discovery support, you have to add the classes and permissions to the > > policy flask definitions and rebuild your policy. The object class/perm > > discovery support just changes how the object manager obtains the values > > - whether they are hardcoded into it or dynamically looked up at object > > manager startup. But the policy itself still needs to be taught about > > them. > > > > As Ted said, the old way to teach libselinux about new classes/perms is > > described in: > > http://selinuxproject.org/page/Adding_New_Permissions > > > > After updating the policy/flask files, you run make in the flask > > subdirectory (different Makefile than the policy build one) and it will > > regenerate the header files that are used by libselinux and by the > > kernel. Then you can install the libselinux ones into a libselinux > > source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then > > rebuild your libselinux. > > > > > When I install our product on a fresh machine in addition to the > actual product and the new policy files, will I also need to install a > new version of the libselinux libraries? Yes (when using the old way). > I assume that the linux kernel needs to somehow access the new object > class / permissions defines (I'm guessing there is a potential for > pre-existing defines to change through my policy rebuild), would that > be through the shared libselinux libraries? Kernel rebuild? (Mucking > with Linux itself is way out of my area of knowledge.) No, the kernel doesn't need userspace object class/perm definitions, because it never references them itself. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
