Bug 765359 (GLUSTER-3627) - Local user's can abuse gluster
Summary: Local user's can abuse gluster
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-3627
Product: GlusterFS
Classification: Community
Component: glusterd
Version: 3.2.3
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Kaushal
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-25 07:03 UTC by David
Modified: 2015-12-01 16:45 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-06-20 06:07:31 UTC


Attachments (Terms of Use)

Description David 2011-09-25 07:03:39 UTC
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 04:01:31 UTC
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 06:08:13 UTC
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 06:14:33 UTC
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 06:32:29 UTC
(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 06:07:31 UTC
In the current releases, the default setting for glusterd is rpc-auth-allow-insecure off. So this shouldn't be an issue anymore.


Note You need to log in before you can comment on or make changes to this bug.