SELinux support in the near future!!!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux