<div dir="ltr"><div>Hi all,</div><div><br></div><div>Currently, setting SELinux context over a FUSE mount point is not</div><div>possible since (kernel)FUSE does not support it. There are three</div><div>things that I will try to explain in the perspective of GlusterFS and</div><div>SELinux and where we stand in accomplishing these tasks.</div><div><br></div><div>1) First thing is to make possible for SELinux to check sub-filesystems</div><div>(fuse.glusterfs). At the moment, SELinux only can check if a filesystem</div><div>supports SELinux based on the base filesystem. Since, by default FUSE</div><div>does not support SELinux, sub-filesystems are not able do it as well. A</div><div>Gluster mount identifies itself as "fuse.glusterfs"(<mainfs>.<subfs>).</div><div><br></div><div>Current status : An experimental patch for the kernel has been attached to</div><div><a href="https://bugzilla.redhat.com/1272868">https://bugzilla.redhat.com/1272868</a>. May be few improvements to the</div><div>patch can make it work.</div><div><br></div><div>2) We can inform FUSE that the glusterfs sub-file system supports SELinux.</div><div>Mount options can be passed on to the FUSE(kernel) when mounting takes</div><div>place. Some options are user-space process specific and can get filtered out,</div><div>whereas others are passed to FUSE. SELinux mount options are added in</div><div>/sbin/mount.glusterfs and this is currently supported in GlusterFS.</div><div>One can do</div><div>mount -t glusterfs <HOSTNAME>:VOLNAME> -o context="<selinux context>"</div><div><mt pt> and pass(set) the SELinux context.</div><div><br></div><div>3) When FUSE(kernel) patch gets merged, we will be</div><div>allowed(able) to set the context from the FUSE mount point which in turn will</div><div>be reflected in the backend(bricks) as well. For Glusterfs bricks, we will have</div><div>type as "glusterd_brick_t". Brick processes may only read/write contents in the</div><div>brick directories that have type 'glusterd_brick_t' which will be enforced by</div><div>SELinux policy. The client can do a chcon command(chcon <option> context <file>)</div><div>and can change the security context or a Restorecon command. So, when a client</div><div>sets/reads a 'security.selinux' extended attribute(simply through ls -Z) over</div><div>a FUSE mount point, the brick process needs to convert the request to a</div><div>'trusted.glusterfs.selinux' xattr. In the brick side, security.selinux xattr</div><div>is used by the SELinux to prevent unauthorized access to the contents in the</div><div>brick directories.</div><div><br></div><div>How could this be done?</div><div><br></div><div>We are designing a SELinux translator on the server side which would convert</div><div>security.selinux xattr to trusted.glusterfs.selinux. In the setxattr call</div><div>this is done and we do the vice-versa for the getxattr call, thereby the user</div><div>could also set his security contexts over the mount point and making brick</div><div>process secure as well. This is partially implemented here[1] which handles</div><div>getxattr and setxattr fops. Another thing to note here is that, the translator</div><div>should also be able to inherit security context from it's parent whenever a new</div><div>directory(or file) is created or linked. So, we have to handle other</div><div>fops like mknod, link, symlink, rename and a few more. We also have issues</div><div>whenever an add-brick or remove-brick is done(we should take care to set right</div><div>contexts in the brick directories). This is already handled in a patch which</div><div>implements SELinux helper hook-scripts[2]. The translator will be enabled</div><div>by default and there will be an volume set option to disable the translator.</div><div>Also, by default if no context is set, it would take the default context</div><div>assigned to it by SELinux. Where exactly should the translator be placed in</div><div>the server side(Below Marker, may be?).</div><div><br></div><div>[1] <a href="http://review.gluster.org/#/c/13762/">http://review.gluster.org/#/c/13762/</a></div><div><br></div><div>[2] <a href="http://review.gluster.org/#/c/6630/">http://review.gluster.org/#/c/6630/</a></div><div><br></div><div>Comments on this would be helpful and highly appreciated. Let Niels and me know</div><div>how things can be improved and handled. Thanks Jiffin and Ashiq for helping out.</div><div>Here[3] is a design doc of how things hang together.</div><div><br></div><div>[3] <a href="http://review.gluster.org/#/c/13789/">http://review.gluster.org/#/c/13789/</a></div><div><br></div><div>Thanks for reading :-)</div><div><br></div><div><br></div><div>--</div><div>Thanks & Regards,</div><div>Niels & Manikandan.</div>
</div>