SELinux should be completely supported on a Gluster Volume. Clients that access contents on a Gluster Volume should be able to get and set the SELinux context. This needs to be done in such a way, that the brick processes can keep running with their restricted context.
- Manikandan Selvaganesh
- Niels de Vos
At the moment it is not possible to set an SELinux context over a FUSE mount. This is because FUSE (in the kernel) does not support SELinux.
- SELinux not supported with FUSE client
- SELinux translator to support setting SELinux contexts on files in a glusterfs volume
Brick processes may only read/write contents in the brick directories that have
SELinux type glusterd_brick_t. This means that when a client sets/reads a
security.selinux extended attribute over a mountpoint, the brick process
needs to convert the request to a trusted.glusterfs.selinux xattr. The
security.selinux xattr on the brick is used by the kernel on the storage server
to prevent unauthorized access to the contents in the brick directories. A
conversion security.selinux <-> trusted.glusterfs.selinux will be done a
new SELinux translator.
In order to support SELinux clients, all bricks need to have the SELinux translator in their graph. It is important to set the correct context for new files/directories/..., the translator will make sure that the context is inherited from the parent directory. This also means that the SELinux translator is loaded on systems that do not support SELinux natively, like NetBSD.
Users that store contents on Gluster Volumes want to have support for SELinux. This means that applications (like a web-server) may only access contents with the correct SELinux labels. Access to unrelated contents on the Gluster Volume should be prevented by the client when SELinux is in enforcing mode.
The permission check can not be done on the server-side, because the client does not pass the context of the running application over the network.
None.
FUSE clients (after kernel changes have been merged) will be able to get/set the SELinux context on contents.
NFS-Ganesha can use glfs_setxattr() and the like for implementing
Labelled-NFS.
Once the feature is active, the brick processes may not access files that have
a different type than glusterd_brick_t. Environments that have contents of
the bricks with a different target security context type, will not be allowed
to access the contents. This means that upgrades from previous version need to
make sure that the contents of the bricks get re-labelled correctly. A command
like this is needed for all bricks (assuming /bricks/volume/b1 is displayed
as a brick path in gluster volume info):
# chcon -t glusterd_brick_t /bricks/volume/b1
If the filesystem used for the bricks supports SELinux labels, the type of the
target security context of the contents on the bricks will be set to
glusterd_brick_t. The brick processes will not be allowed to access files
with a different type.
A new trusted.glusterfs.selinux extended attribute will be added. This
attribute is converted to/from security.selinux on the client-side.
A new features/selinux xlator will need to be inserted in the graph on the
server-side.
Once a new volume is created, the directories for the bricks should get the
glusterd_brick_t target security context type in case SELinux on the storage
server is available. This will be handled by a hook-script in the create/post
event.
glfs_setxattr(..., "security.selinux", ...) will not change the
security.selinux xattr on the bricks. Instead trusted.glusterfs.selinux
will contain the value that gets passed.
It will be possible to disable the conversion by setting the selinux.enabled
volume option to false.
FUSE clients will only be able to set the SELinux context when the Linux kernel supports sub-filesystems (bug 1272868).
The documentation with the volume options needs to explain the
selinux.enabled option.
In development, design has been discussed in the email thread below.