[Gluster-users] SELinux support in the near future!!!

[Manikandan Selvaganesh]

Hi all,

Currently, setting SELinux context over a FUSE mount point is not
possible since (kernel)FUSE does not support it. There are three
things that I will try to explain in the perspective of GlusterFS and
SELinux and where we stand in accomplishing these tasks.

1) First thing is to make possible for SELinux to check sub-filesystems
(fuse.glusterfs). At the moment, SELinux only can check if a filesystem
supports SELinux based on the base filesystem. Since, by default FUSE
does not support SELinux, sub-filesystems are not able do it as well. A
Gluster mount identifies itself as "fuse.glusterfs"(<mainfs>.<subfs>).

Current status : An experimental patch for the kernel has been attached to
https://bugzilla.redhat.com/1272868. May be few improvements to the
patch can make it work.

2) We can inform FUSE that the glusterfs sub-file system supports SELinux.
Mount options can be passed on to the FUSE(kernel) when mounting takes
place. Some options are user-space process specific and can get filtered
out,
whereas others are passed to FUSE. SELinux mount options are added in
/sbin/mount.glusterfs and this is currently supported in GlusterFS.
One can do
mount -t glusterfs <HOSTNAME>:VOLNAME> -o context="<selinux context>"
<mt pt> and pass(set) the SELinux context.

3) When FUSE(kernel) patch gets merged, we will be
allowed(able) to set the context from the FUSE mount point which in turn
will
be reflected in the backend(bricks) as well. For Glusterfs bricks, we will
have
type as "glusterd_brick_t". Brick processes may only read/write contents in
the
brick directories that have type 'glusterd_brick_t' which will be enforced
by
SELinux policy. The client can do a chcon command(chcon <option> context
<file>)
and can change the security context or a Restorecon command. So, when a
client
sets/reads a 'security.selinux' extended attribute(simply through ls -Z)
over
a FUSE mount point, the brick process needs to convert the request to a
'trusted.glusterfs.selinux' xattr. In the brick side, security.selinux xattr
is used by the SELinux to prevent unauthorized access to the contents in the
brick directories.

How could this be done?

We are designing a SELinux translator on the server side which would convert
security.selinux xattr to trusted.glusterfs.selinux. In the setxattr call
this is done and we do the vice-versa for the getxattr call, thereby the
user
could also set his security contexts over the mount point and making brick
process secure as well. This is partially implemented here[1] which handles
getxattr and setxattr fops. Another thing to note here is that, the
translator
should also be able to inherit security context from it's parent whenever a
new
directory(or file) is created or linked. So, we have to handle other
fops like mknod, link, symlink, rename and a few more. We also have issues
whenever an add-brick or remove-brick is done(we should take care to set
right
contexts in the brick directories). This is already handled in a patch which
implements SELinux helper hook-scripts[2]. The translator will be enabled
by default and there will be an volume set option to disable the translator.
Also, by default if no context is set, it would take the default context
assigned to it by SELinux. Where exactly should the translator be placed in
the server side(Below Marker, may be?).

[1] http://review.gluster.org/#/c/13762/

[2] http://review.gluster.org/#/c/6630/

Comments on this would be helpful and highly appreciated. Let Niels and me
know
how things can be improved and handled. Thanks Jiffin and Ashiq for helping
out.
Here[3] is a design doc of how things hang together.

[3] http://review.gluster.org/#/c/13789/

Thanks for reading :-)


--
Thanks & Regards,
Niels & Manikandan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160321/189a9c40/attachment.html>