Client: Error with login in with keybase as root user

[ghost]

Keybase GUI Version: 1.0.16-20160809160037+24badd1
The GUI does not load to allow login when using 'root' user. No terminal commands can be used either ie 'kaybase login' says not admin. Made a non user account and fixed error but still annoying to switch users.

[cjb]

Sorry for the annoyance, but running any kind of networked application software as root is dangerous -- it's not uncommon for applications to refuse to launch as root.

[zander]

If you login in your graphical desktop as root, you are doing it wrong and you should expect lots of things to break on a regular basis.

[ghost]

I am running Kali linux right now, and it is built to only have one user (root).

On Sunday, August 14, 2016 6:53 AM, TomZ <[email protected]> wrote:

If you login in your graphical desktop as root, you are doing it wrong and you should expect lots of things to break on a regular basis.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[soulshake]

$ cat keybase 
#!/bin/bash

docker run -ti \
    -v $HOME/.config/keybase:/root/.config/keybase \
    -v $HOME/.cache/keybase:/root/.cache/keybase \
    -v $HOME/.gnupg:/root/.gnupg \
    soulshake/keybase "$@"

$ ./keybase cert
Oops, you are trying to run as an admin user (Uid: 0). This isn't supported.

I'm running the keybase CLI in a Docker container. I don't know of a valid reason to have to create a non-root user in this scenario. Perhaps there could be a (ALLOW_ROOT_USER-ish) workaround?

[cjb]

I'm running the keybase CLI in a Docker container. I don't know of a valid reason to have to create a non-root user in this scenario.

There is a valid reason. You're assuming that Docker is secure against "container breakout" (going from root inside the container to root outside the container), but it historically hasn't been. I'd guess that escalating from root inside the container to root outside the container is currently easier than escalating from a user on a host to root on that host.

[rivy]

I'm necro-ing this... but it is still an open issue and it's affecting my use for some VMs configurations.

IMO, the users of keybase should be allowed to evaluate their risk and choose their security settings.

And, there are definitely several use cases (some mentioned above) for the use of keybase from a root account.

I'm happy to create a PR allowing root usage, but the expressed sentiment of the contributors seems to be "against". So, instead, this is a patch which allows root execution when the environment variable KEYBASE_ALLOW_ROOT is set to a non-zero value ...

diff --git a/go/keybase/main.go b/go/keybase/main.go                                                                    
index efe7da2..23d6134 100644                                                                                           
--- a/go/keybase/main.go                                                                                                
+++ b/go/keybase/main.go                                                                                                
@@ -101,9 +101,13 @@ func warnNonProd(log logger.Logger, e *libkb.Env) {                                                
 }                                                                                                                      

 func checkSystemUser(log logger.Logger) {                                                                              
-       if isAdminUser, match, _ := libkb.IsSystemAdminUser(); isAdminUser {                                            
-               log.Errorf("Oops, you are trying to run as an admin user (%s). This isn't supported.", match)           
-               keybaseExit(int(keybase1.ExitCode_NOTOK))                                                               
+        env_allow_root := os.Expand("${KEYBASE_ALLOW_ROOT}", os.Getenv);                                               
+        allow_root := (env_allow_root != "") && (env_allow_root != "0");                                               
+        if ! allow_root {                                                                                              
+               if isAdminUser, match, _ := libkb.IsSystemAdminUser(); isAdminUser {                                    
+                       log.Errorf("Oops, you are trying to run as an admin user (%s). This isn't supported.", match)   
+                       keybaseExit(int(keybase1.ExitCode_NOTOK))                                                       
+               }                                                                                                       
        }                                                                                                               
 }                                                                                                                      

[linux-modder]

Again, if you wish to break your own system, it will NOT be openly condoned or allowed by the project. Secondarily, Assuming the aforementioned case of container-breakout even on your localhost if the root account is p0wned so are the keys and thus any chance of expressing validity of the keys or the host(s) containing them. This also risks and would in many gpg/keybase users this also populates the set of keys some of which _may_ be in the strong set, this is a VERY bad thing.

[rivy]

This doesn't "break" anything. It simply allows execution of the keybase executable by the root account. It is a legitimate use case, whether "condoned" / "allowed" or not. Additionally, running the keybase daemon as root is mentioned by @strib as a workaround for another issue.

I welcome explanation of actual security problems or alternative ways of transferring secure information (such as VPN credentials) for use by root.

I don't, otherwise, understand what you are arguing.

[zander]

It is a legitimate use case

is it, though?

Root is different in one specific way. Any and all checks for file-system permissions are disabled. So you can't even protect a file by making it chmod 000. Root can read, write and delete such a file.

While everyone is free to do it on their own system, running a service as root is not normal operation and many gnu and other tools forbid running as root.

We are talking about open source, though. Apply the patch at home, compile it and run it and be happy. Nobody will stop you. Just as people like linux-modder have the ability to disagree with you, you can disagree with us and just do what you want on your own computer.

Thanks for sharing the patch, always appreciated.

[rivy]

Fair point, but, again, accessing secure information (eg, credentials) from root is a compelling use case, especially in semi-automated / transient / disposable VMs.

I'm new to this project and haven't looked deeply into the design of keybase ... I'm just trying to use it. But wouldn't it be better to design keybase to run it's daemon service in a permission restricted manner (hopefully solving your concerns), and allow client use of that service from any account (root or not)?

Or do you have another way of sharing secure information to a root account?

[bootstraponline]

Implemented in https://github.com/keybase/client/pull/11500

KEYBASE_ALLOW_ROOT=1

I think this issue can be closed.

[educatedwarrior]

Good. I know well what I want to do. I'm glad you guys added this option.