Thank you again Sam, after following your instructions it seems to be working but there is still a security concern, the main process that starts the interpreters would be running with root user right ?. For example with python interpreter the process would be this ($ps auxwww):
*root* 203 0.0 0.2 87768 4468 ? S 15:32 0:00 *sudo -E -H -u interpreteruser bash -c* /usr/java/jdk1.8.0_131/bin/java -Dfile.encoding=UTF-8 -Dlog4j.configuration=file:///usr/zeppelin/conf/log4j.properties -Dzeppelin.log.file=/usr/zeppelin/logs/zeppelin-interpreter-python-interpreteruser-python--XX.log -cp :/usr/zeppelin/interpreter/python/*:/usr/zeppelin/lib/interpreter/*: *org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer* XX.X.X.X XXXX *interpr+* 204 1.0 4.2 4579156 87904 ? Sl 15:32 0:02 /usr/java/jdk1.8.0_131/bin/java -Dfile.encoding=UTF-8 -Dlog4j.configuration=file:///usr/zeppelin/conf/log4j.properties -Dzeppelin.log.file=/usr/zeppelin/logs/zeppelin-interpreter-python-interpreteruser-python--XX.log -cp :/usr/zeppelin/interpreter/python/*:/usr/zeppelin/lib/interpreter/*: *org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer* XX.X.X.X XXXX I would think that is another security issue of this approach.What do you think about it? 2018-05-09 12:53 GMT-05:00 Jhon Anderson Cardenas Diaz < jhonderson2...@gmail.com>: > > ---------- Forwarded message --------- > From: Sam Nicholson <sam...@ogt11.com> > Date: mié., may. 9, 2018 12:04 > Subject: Re: Zeppelin code can access FileSystem > To: <users@zeppelin.apache.org> > > > Yes, I believe that jira report was about keeping users isolated from each > other. > And with user impersonation, and the method I outlined just now, this > works well. > > AND this keeps the shell you fire up from accessing the zeppelin files. > > BUT, this is not a zeppelin problem. This is a JEE problem. Java has no > native mechanism > to set/change userID. So, while you can sudo / su -c the web application > upon startup, it cannot > change itself later. So, if it needs the filesystem for ANY reason, it'll > have to start with a userid > that has filesystem permissions. > > This is, IMO, the real problem behind the Spring breakage at Equifax. If > the app server default > userID is leaked, not only can you login, but you can MODIFY the > application filesystem if you > can get a shell. > > So, I think the Zeppelin team has done an excellent job of mitigating the > problem as best as > can be done within the JEE system. (This is true of tomcat, jetty, > whathaveyou servlet container.) > > Because, by default, Zeppelin gives you shells. R, Python, sh, all have > full UNIX abilities, as > do many other shells. > > I'm going to write up a Jira request to have the default interpreter > settings in a config file. If > one is truly paranoid, then just having the server running while one sets > the interpreter settings > seems risky. > > In short: > > Enable user impersonation > Put zeppelin users in a zeppelin group > Allow zeppelin sudo to only zeppelin group members > Ensure zeppelin group members cannot sudo without password and cannot ssh > without password > Set shell context as per-user in isolated process > Set shell.working.directory.user.home to true > > And do this for all compatible interpreters. > > Cheers! > -sam > > On Wed, May 9, 2018 at 10:17 AM, Jhon Anderson Cardenas Diaz < > jhonderson2...@gmail.com> wrote: > >> Thank you Sam. Reviewing the jira issues, I found that issue was >> previously identified in this jira ticket ZEPPELIN-1320 >> <https://issues.apache.org/jira/browse/ZEPPELIN-1320>, but i don't know >> if is my impression but it seems like they focused more on the fact that >> the processes could not access the directories of other users than on the >> problem that a process could access the zeppelin file system. Am i right ? >> >> 2018-05-08 17:46 GMT-05:00 Sam Nicholson <sam...@ogt11.com>: >> >>> And warning! >>> >>> Trying to answer the above, I've disconnected my websocket. >>> I'll figure it out and report back >>> >>> On Tue, May 8, 2018 at 6:28 PM, Sam Nicholson <sam...@ogt11.com> wrote: >>> >>>> So, >>>> >>>> I run the zeppelin process as the web user on my system. There is no >>>> other web process, so why not. >>>> >>>> Then, UNIX permissions keep it from running, accessing, deleting >>>> anything else. EXCEPT items that are world writeable. >>>> >>>> There shouldn't be any of those, other than /tmp, but still /tmp is a >>>> hotbed of nefarious activity on hacked machines. :) >>>> >>>> For example: >>>> >>>> %sh >>>> >>>> pwd >>>> ls >>>> touch bazzot >>>> ls -l bazzot >>>> rm bazzot >>>> >>>> Gives: >>>> >>>> /var/www/zeppelin >>>> derby.log >>>> figure >>>> metastore_db >>>> Rgraphics >>>> Rgraphics.zip >>>> -rw-r--r-- 1 www-data www-data 0 May 8 18:04 bazzot >>>> ls: cannot access 'bazzot': No such file or directory >>>> ExitValue: 2 >>>> >>>> For another example: >>>> >>>> %sh >>>> id >>>> cd /home/samcn2 >>>> touch bazzot >>>> ls -l bazzot >>>> rm bazzot >>>> >>>> Gives: >>>> >>>> uid=33(www-data) gid=33(www-data) groups=33(www-data) >>>> touch: cannot touch 'bazzot': Permission denied >>>> ls: cannot access 'bazzot': No such file or directory >>>> rm: cannot remove 'bazzot': No such file or directory >>>> ExitValue: 1 >>>> >>>> >>>> So, you can't access other users' files. >>>> >>>> But you CAN access the web user's files. That may be a bug. I'm going >>>> to try changing the zeppelin running user. Wait one... >>>> >>>> OK. So you can run zeppelin as some other user, the logs and the run >>>> directory must be owned by that user.. >>>> I do this with symlinks. But the websocket is failing. So no joy >>>> there... >>>> >>>> So, for now, you can set things up so that zeppelin can't access any >>>> other files from other users on the system, >>>> but zeppelin web can access the zeppelin executable. So, don't put >>>> this up for untrusted users!!! >>>> >>>> Here is my zeppelin start script: >>>> #!/bin/sh >>>> >>>> cd /var/www/zeppelin/home >>>> >>>> sudo -u zeppelin /opt/apache/zeppelin/zeppelin- >>>> 0.7.3-bin-all/bin/zeppelin-daemon.sh $* >>>> >>>> >>>> If /var/www/zeppelin/home is owned by zeppelin, as is >>>> /opt/apache/zeppelin/*, then this works with the caveat above. >>>> >>>> Cheers! >>>> -sam >>>> >>>> >>>> On Tue, May 8, 2018 at 5:48 PM, Jhon Anderson Cardenas Diaz < >>>> jhonderson2...@gmail.com> wrote: >>>> >>>>> Dear Zeppelin Community, >>>>> >>>>> Currently when a Zeppelin paragraph is executed, the code in it can >>>>> read sensitive config files, change them, including web app pages and etc. >>>>> Like in this example: >>>>> >>>>> %python >>>>> f = open("/usr/zeppelin/conf/credentials.json", "r") >>>>> f.read() >>>>> >>>>> Do you know if is there a way to configure the user used to start the >>>>> interpreters or run the paragraph's code ?, so that user can not access >>>>> the >>>>> File System where zeppelin is running, or has more restricted access. >>>>> >>>>> Thank you.. >>>>> >>>> >>>> >>> >> >
