Stephen Smalley wrote:
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.
My concern was not that the kernel would need to access my userspace
object class/perm definitions but that through creating a new flask.h I
would change the definitions of pre-existing object classes. For
instance, my current flask.h has:
#define SECCLASS_FILE 6
If after I generated a new flask.h this somehow changed to:
#define SECCLASS_FILE 7
I would think this could cause an issue with the kernel if it uses the
SECCLASS_FILE define in code built with the original flask.h. Is this
possible or are the pre-existing kernel object class defines guarenteed
to be consistent accross policy builds which have new object class
definitions?
|
