client: The systemd `keybase.mount` should not use the root directory

I just installed the linux client and noticed that there is a fuse mount in /

$ ls -ld keybase
dr-x------ 1 root root 0 Dec 23 14:37 keybase/

$ mount | grep keybase
/dev/fuse on /keybase type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

$ tree keybase/
keybase/
├── private
│   └── gdahlm
├── public
│   └── gdahlm
└── team

This behavior Violates the well established Filesystem Hierarchy Standard

The Root Filesystem Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

It breaks if a host happens to have multiple authenticated users

jenkins@host:~$ ls /keybase 
ls: cannot access '/keybase': Permission denied

As this directory is in an improper location it may:

• Be overly constrained by base apparmor profiles.
• Run unconstrained, limiting the protections provided by these systems.
• Potentially run in an un-encrypted root partition.
• Fail to even run on systems where security is a concern which run a read-only root.

$ file `which run_keybase`
/usr/bin/run_keybase: Bourne-Again shell script, ASCII text executable

Note in the /usr/bin/run_keybase there is no option relocate this fuse mountpoint, yet it would be easy to leverage the XDG methods you are using to auto locate this fuse mount from application and your code.

start_background() {
  export KEYBASE_RUN_MODE="${KEYBASE_RUN_MODE:-prod}"
  export KEYBASE_DEBUG=1
  logdir="${XDG_CACHE_HOME:-$HOME/.cache}/keybase"
  mkdir -p "$logdir"

  echo Launching keybase service...
  # We set the --auto-forked flag here so that updated clients that try to
  # restart this service will know to re-fork it themselves. That's all it does.
  keybase -d --log-file="$logdir/keybase.service.log" service --auto-forked &>> "$logdir/keybase.start.log" &
  echo Mounting /keybase...
  kbfsfuse -debug -log-to-file /keybase &>> "$logdir/keybase.start.log" &
  echo Launching Keybase GUI...
  /opt/keybase/Keybase &>> "$logdir/Keybase.app.log" &
  write_startup_token "background"
}

Most likely this content probably should be located under the $XDG_RUNTIME_DIR

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime >files and other file objects (such as sockets, named pipes, …) should be stored. The directory MUST be >owned by the user, and he MUST be the only one having read and write access to it. Its Unix access >mode MUST be 0700.

Note: that there is a far more serious issue with this method and the systemd keybase.mount method that instantly caused me to remove this software, and avoid using it with a client.

$ systemctl stop keybase.moun
$ ls -ld /keybase/
drwxrwxrwx 2 root root 4096 Dec 23 14:37 /keybase/

When the service is stopped it leaves a directory, that will be referenced for security and encryption in a system level directory with a 0777 mode!!

By just following the long existing file system standards the risks of a huge security hole like this would be partially mitigated by other controls. But because best practices of the FHS and XDG standards are ignored the keybase team will take on all responsibilities for hardening and auditing.