Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Local user's can abuse gluster|
|Product:||[Community] GlusterFS||Reporter:||David <db.pub.mail+gluster>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||3.2.3||CC:||aavati, amarts, gluster-bugs, jdarcy, kdhananj, kparthas|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-06-20 02:07:31 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description David 2011-09-25 03:03:39 EDT
Ok so I understand that gluster has a few limited authentication mechanisms and that there is a more secure back-end in the works but for now there is only ip/host based auth. This bug is concerned with the gluster (cli) operation on the host itself. While the cli.c source file usually will only run as root, I patched it (in two places - the first initial geteuid check and the location of the log file(if I was a non-root user)) so that it would run as any user. Then I just fired up a gluster prompt like this: -------- root@mybox #su nobody $ bash nobody@mybox:/tmp$ gluster volume info Volume Name: SIF Type: Distribute Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: 10.0.22.183:/tmp gluster> volume log filename SIF /etc/passwd3 log filename : successful -------- Then I checked to see if /etc/passwd3 was created, it was indeed. (basically any local user who recompiled gluster can play with it - which is probably what one might expected). I consider this to be a security issue because even in file-systems like NFS, local (non-root) users are _not_ (normally) allowed to do this.
Comment 1 Amar Tumballi 2011-09-26 00:01:31 EDT
Its a good idea to remove the feature of giving a 'filename' for the log filename option (which is changed already in master), instead only allow directories in which we can create the log files.
Comment 2 David 2011-09-26 02:08:13 EDT
Actually, that's not the issue here. Perhaps I wasn't clear enough. The title of the bug is "Local user's can abuse gluster" and I gave an example of abusing one of the many gluster CLI commands (as the nobody user). The actual issue here is that "Local user's can abuse gluster" (non-root users) ... and they really shouldn't be able to abuse it :p Remember _any_ local user can delete _any_ gluster volume available (from what I can tell) (and create a new one).
Comment 3 Amar Tumballi 2011-09-26 02:14:33 EDT
That can be solved by having an option in 'glusterd.vol', 'option rpc-auth-allow-insecure off'. That way, glusterd doesn't allow any connection from user programs. Please check if that is enough.
Comment 4 David 2011-09-26 02:32:29 EDT
(In reply to comment #3) > That can be solved by having an option in 'glusterd.vol', 'option > rpc-auth-allow-insecure off'. That way, glusterd doesn't allow any connection > from user programs. Please check if that is enough. It seem to fix the (patched) cli access from the nobody user. Why isn't that setting 'off' by default?
Comment 5 Kaushal 2013-06-20 02:07:31 EDT
In the current releases, the default setting for glusterd is rpc-auth-allow-insecure off. So this shouldn't be an issue anymore.