devel-su and SSHD (developer mode remote connection) on Sailfish

[Feathers McGraw]

I don't like leaving SSHD running on my phone, because it leaves the phone vulnerable to brute-force password attacks against SSH when on mobile networks and public wifi. I'd never leave a server like that, so I'm definitely not going to do that on my phone.

I've been frustrated a few times to find that nemo's PW is reset when the GUI option to enable or disable remote access is toggled. Even if you don't enter anything in the new PW box or click "generate", enabling or disabling SSHD will wipe the existing PW. Grr!

I did some experimenting... this is with SSHD enabled:

[root@Jolla nemo]# cat /etc/passwd | egrep '\<(root|nemo)\>'
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
nemo:x:100000:100000::/home/nemo:/bin/bash

[root@Jolla nemo]# cat /etc/shadow | egrep '\<(root|nemo)\>'
root:!*:16571:0:99999:7:::
nemo:topsecretpasswordhash:::

After turning remote access off in the GUI:

[root@Jolla nemo]# cat /etc/passwd | egrep '\<(root|nemo)\>'
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
nemo:x:100000:100000::/home/nemo:/bin/bash

[root@Jolla nemo]# cat /etc/shadow | egrep '\<(root|nemo)\>'
root:!*:16571:0:99999:7:::
nemo::16816:0:99999:7:::


So:

like most (all?) modern linux distros, the password hashes are stored in /etc/shadow, and the non-sensitive info is stored in /etc/passwd
devel-su authenticates with nemo's password, not the root password ("set a password for SSH and root access" should be clearer IMO)
root password is never set by Jolla utilities
disabling SSHD clears nemo's password as well as disabling SSH


The whole thing is quite irritating really, because you can't easily control the two settings independently of each other in the GUI, AND the device is very insecure - it would literally take someone 30s to get root access.

I've been trying to think of a decent way to separate the two, but I don't think there's an obvious perfect solution. Here's my thoughts on workarounds with the current setup:

You can set a password for nemo using the utility passwd, which will enable you to use devel-su in fingerterm without SSHD, but enabling SSHD in the GUI will still clobber your PW.

I guess you can also manually change SSHD to allow publickey authentication only, but I'm not sure if the GUI setting will clobber this too. This also doesn't solve the problem that someone can pick up your device and root it in 30s.

If I could go back in time and whisper in the Jolla devs' ears as they were designing the system, here's how I'd suggest setting it up:


On first boot (or first time enabling developer mode), the user is asked to set a root PW. Scary warning not to forget this or you won't be able to reset it without factory resetting the device.
Devel-su asks for root PW, not nemo's PW.
No way to change root PW if you forget it without doing a factory reset of the device (wipes data).
Remote connection does pretty much the same thing it does now, i.e. sets nemo's password (which isn't used for anything apart from SSH) and enables/disables SSHD. Technical users could require publickey authentication if they wanted by changing /etc/ssh/sshd_config, in which case the GUI changing nemo's password wouldn't make a difference to anything.


Two questions for the rest of you:

What do you think is the best way to handle the current setup on Sailfish?
If you could start fresh and do whatever you wanted, how would you approach root access and SSHD?


Hopefully I'm not the only one irritated by this ;)

[mced]

Hopefully I'm not the only one irritated by this ;)

It seems you are :)

Point I: Yeah, this SSHD/password GUI config is kind of surrealist.

II: If I wanted to enable/disable SSHD, probably I would try systemctl start/stop sshd.

III: My 3G provider, Yoigo (Telia Sonera) gives IPs behind a CGNAT. So the SSH daemon is not accesible to the whole world. Of course, there are these WhatsApp teenagers behind the same CGNAT as me, but I don't expect them to know what SSH means.

IV: The same thing with public wifi's at restaurants, transport and the like.

V: Get root access in 30 seconds? Could you post a link to this bug?

VI: I don't know why, but I'm unable to set RSA key authentication on my Jolla. I've got three of four Debian machines, my Raspbian RPi and an OpenWRT router, all of them sharing their respective RSA keys: they work flawlessly. But when it's time to log into my Jolla this way, "Permission denied (publickey)".

[jellyroll]

This works all different compared to the Maemo system.

[Feathers McGraw]

III: My 3G provider, Yoigo (Telia Sonera) gives IPs behind a CGNAT. So the SSH daemon is not accesible to the whole world. Of course, there are these WhatsApp teenagers behind the same CGNAT as me, but I don't expect them to know what SSH means.

IV: The same thing with public wifi's at restaurants, transport and the like.

I'm really surprised to hear someone on this forum make an argument like this. Do you always rely on other peoples' incompetence for the security of your systems?

V: Get root access in 30 seconds? Could you post a link to this bug?


pick up a jolla
enable developer mode
toggle remote connection and set whatever password you like, without having to know the current password
open fingerterm
use devel-su with the password you just set to run commands as root


You shouldn't be able to set the password required for root access like that, it's stupid. On a normal system, if you log in as a user in the sudo group, you need to know either that user's password or the root password to run commands as root (depending on how sudo is configured). If you want to change your own password, you need to know the current password.

VI: I don't know why, but I'm unable to set RSA key authentication on my Jolla. I've got three of four Debian machines, my Raspbian RPi and an OpenWRT router, all of them sharing their respective RSA keys: they work flawlessly. But when it's time to log into my Jolla this way, "Permission denied (publickey)".

Works fine here:

sam@T440s:~$ ssh-copy-id nemo@192.168.1.227
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
nemo@192.168.1.227's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'nemo@192.168.1.227'"
and check to make sure that only the key(s) you wanted were added.

sam@T440s:~$ ssh nemo@192.168.1.227
Enter passphrase for key '/home/sam/.ssh/id_rsa':
Last login: Sun Feb 14 20:22:17 2016 from 192.168.1.112
,---
| SailfishOS 2.0.1.7 (Taalojärvi) (armv7hl)
'---


I don't think I had to enable publickey authentication, pretty sure the default configuration allows it.

[jellyroll]

I do remember that the MeeGo/Harmattan used to have the same settings for ssh and developer mode. It's nice to see the password being reset all time while using a device lock code and one acces ip.

[pichlo]

pick up a jolla
enable developer mode
toggle remote connection and set whatever password you like, without having to know the current password
open fingerterm
use devel-su with the password you just set to run commands as root


If you were as security conscious as your posts suggest, you would have a step between 1 and 2:
guess the unlock code

Why worry about the root access anyway? All the important stuff is in the user land: your files, your contacts, your login creds to various services... About the only thing that knowing the root password gives you are the access to other users' data and the possibility to install stuff, both irrelevant on Jolla.

[Feathers McGraw]

If you were as security conscious as your posts suggest, you would have a step between 1 and 2:
guess the unlock code

Jolla should ship sensible and secure defaults. It's not unreasonable to expect some privilege separation between nemo and root, and that shouldn't depend on having a lock code (I do use one by the way, but it's beside the point).

Why worry about the root access anyway? All the important stuff is in the user land: your files, your contacts, your login creds to various services...

I don't disagree (in fact I've made that point before, so much stuff on SFOS runs as nemo including systemd). There are still some things you can do without root though, in particular it's much more difficult to hide your tracks without root. An attacker with root privileges can clean up after themselves. It doesn't make any sense to throw away that security boundary unnecessarily.

the possibility to install stuff...irrelevant on Jolla.

Why is it irrelevant on Jolla? Do you mean because you can install software without root with pkcon? I pointed this out before, and someone noted that you can't add a repo without root. The damage you can do without root is limited and relies on malicious software in trusted repos, or the existence of apps in those repos that could be exploited to gain root.

I don't understand why people are trying to pass this off as unimportant. I'm not just hating on SFOS, what I'm saying is that Jolla seem to have hacked this part of the system together and have overlooked the fact that it leaves a hole in the system's security unnecessarily.

[pasko]

Hi.
My n9 has the following firewall rule for ssh connections:
-A INPUT -i gprs0 -p tcp -m tcp --dport 22 -j DROPThis silently drops all incoming connections to the gprs0 interface. OTOH I'm only in WiFi when I'm at home. (Controlled environment)
I don't have a Jolla (yet) , but if it has a firewall this solution is fairly simple in my opinion.
Regards.

[jellyroll]

I don't like leaving SSHD running on my phone, because it leaves the phone vulnerable to brute-force password attacks against SSH when on mobile networks and public wifi. I'd never leave a server like that, so I'm definitely not going to do that on my phone

You can try to compile Kippo[1] I use it on my N900 sometimes with a script like this. nohup sh /script.sh > /dev/null 2>&1 &

#!/bin/sh
tail -fn0 /var/log/auth.log | \
while read line ; do
echo "$line" | grep "Failed password"
if [ $? = 0 ]
then

iptables -A PREROUTING -t nat -i wlan0 -p tcp --dport 22220 -j REDIRECT --to-port 2222

iptables -A PREROUTING -t nat -i gprs0 -p tcp --dport 22220 -j REDIRECT --to-port 2222

/etc/init.d/ssh stop

dbus-send --type=method_call --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications.SystemNoteDialog string:"Visitors." uint32:0 string:"OK"

mplayer /home/user/Alert.mp3

fi
done


[1] https://github.com/micheloosterhof/cowrie
http://turbochaos.blogspot.nl/2013/05/attacking-kippo.html

[Feathers McGraw]

You can try to compile Kippo[1]

That's pretty cool :) my first reaction was to install fail2ban, but it doesn't support journad's binary logging (yet). I guess tweaking the journald settings so it also writes authentication messages to a text log is one solution to that problem.

[pichlo]

Jolla should ship sensible and secure defaults.

No dispute over that!

An attacker with root privileges can clean up after themselves. It doesn't make any sense to throw away that security boundary unnecessarily.
<snip>
I pointed this out before, and someone noted that you can't add a repo without root.

Yes, both good points.

But I am a bit confused now. In a post just above (https://talk.maemo.org/showthread.php?p=1498791#post1498791), you listed a procedure assuming a physical access to the device. If you have that, you can add and remove repos at will, as a user, using just GUI tools (Warehouse or simply tick the "allow untrusted sources" box in Settings). You do not need the root password at all.

The damage you can do without root is limited and relies on malicious software in trusted repos, or the existence of apps in those repos that could be exploited to gain root.

Or planting a malicious app yourself and running pkcon install-local. That also works without root and allows you to really gain a root access in 30 seconds remotely, once you brute-force your way in as a user.

I don't understand why people are trying to pass this off as unimportant.

Sorry, that was a slight misunderstanding. I am not trying to pass it off as unimportant. All I am trying to say is that there is an even bigger hole gaping in the system in addition to the one you have pointed out.

What I do not understand is how can anyone try to pass Sailfish off as a secure OS. The only "security" we have ATM is through obscurity. The worst kind there is.

[juiceme]

I think most of the problems stem from the convention in current SFOS that there is just one "nemo" user account and many system services depend on the user being "nemo" to work correctly.

True multiuser capability should make the device more secure (among other benefits)

I already started to work on separating system priviliges from "nemo" priviliges, to enable multiple user accounts on the device but got a bit sidetracked some time ago so have not really had time to continue with it.

What I'd like to see in the end are following results;
system startup does not depend on user login at any level multiple user accounts that can log-in simultaneously all user accounts have their own set of privilige controls all system services needing user-related data for operation depend only on data in home of the said user (well, this is kind of obvious, really :)) all installed applications needing user data depend only on data in home of the said user (which actually works like that already) all user homes are encrypted by default

[pichlo]

@juiceme, wonderful!

I would add,

abolish any hard-coded names: on the first boot, the user chooses the user name


There is already the "choose your colour" thing on the first boot, without any explanation WTF that is for. Choosing the user name would make more sense, IMHO.

[juiceme]

@juiceme, wonderful!

I would add,

abolish any hard-coded names: on the first boot, the user chooses the user name


There is already the "choose your colour" thing on the first boot, without any explanation WTF that is for. Choosing the user name would make more sense, IMHO.

Yes, very easily doable.
Actually the username "nemo" group "nemo" (10000:10000) is arbitrary and could be changed to anything desired even now without any adverse effects. It would indeed be nice to set up the "main" user to whatever desired in the startup wizard.

All in all it is not that large a task to implement all these things; the biggest thing is to hack the GUI so that when the wayland backend starts it does not autolaunch lipstick with nemo credentials; instead it should launch up user login selector.
It needs just some heavy-handed systemd tweaking to do, plus pruning the system services dependant on "nemo" login for startup.

[Feathers McGraw]

you can add and remove repos at will, as a user, using just GUI tools (Warehouse or simply tick the "allow untrusted sources" box in Settings). You do not need the root password at all.

Or planting a malicious app yourself and running pkcon install-local. That also works without root and allows you to really gain a root access in 30 seconds remotely, once you brute-force your way in as a user.

I didn't know about pkcon install-local, that's interesting/slightly disturbing if you can use it in the way you are describing.

Having reviewed the polkit settings, I must say I don't understand why you're allowed to do some things with packagekit...

Here's a truncated version of the settings:

nemo ~ $ cat /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy | grep -v "[message|description] xml"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>



<vendor>The PackageKit Project</vendor>
<vendor_url>http://www.packagekit.org/</vendor_url>
<icon_name>package-x-generic</icon_name>

<action id="org.freedesktop.packagekit.cancel-foreign">

<description>Cancel foreign task</description>
<message>Authentication is required to cancel a task that was not started by yourself</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.package-install">

<description>Install signed package</description>
<message>Authentication is required to install a package</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.package-install-untrusted">

<description>Install untrusted local file</description>
<message>Authentication is required to install an untrusted package</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.imply">org.freedesktop.packagekit.package-install</annotate>
</action>

<action id="org.freedesktop.packagekit.system-trust-signing-key">

<description>Trust a key used for signing packages</description>
<message>Authentication is required to consider a key used for signing packages as trusted</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.package-eula-accept">

<description>Accept EULA</description>
<message>Authentication is required to accept a EULA</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.package-remove">

<description>Remove package</description>
<message>Authentication is required to remove packages</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.imply">org.freedesktop.packagekit.package-install</annotate>
</action>

<action id="org.freedesktop.packagekit.system-update">

<description>Update packages</description>
<message>Authentication is required to update packages</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.system-sources-configure">

<description>Change software source parameters</description>
<message>Authentication is required to change software source parameters</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.system-sources-refresh">

<description>Refresh system sources</description>
<message>Authentication is required to refresh the system sources</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.system-network-proxy-configure">

<description>Set network proxy</description>
<message>Authentication is required to set the network proxy used for downloading packages</message>
<icon_name>preferences-system-network-proxy</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.device-rebind">

<description>Reload a device</description>
<message>Authentication is required to reload the device with a new driver</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/pk-device-rebind</annotate>
</action>

<action id="org.freedesktop.packagekit.upgrade-system">

<description>Upgrade System</description>
<message>Authentication is required to upgrade the operating system</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.repair-system">

<description>Repair System</description>
<message>Authentication is required to repair the installed software</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>

<action id="org.freedesktop.packagekit.trigger-offline-update">

<description>Trigger offline updates</description>
<message>Authentication is required to trigger offline updates</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/libexec/pk-trigger-offline-update</annotate>
</action>

<action id="org.freedesktop.packagekit.clear-offline-update">

<description>Clear offline update message</description>
<message>Authentication is required to clear the offline updates message</message>
<icon_name>package-x-generic</icon_name>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/libexec/pk-clear-offline-update</annotate>
</action>

</policyconfig>

I just tried installing a package with pkcon via ssh to test installing a signed package, which should come under allow_inactive because I'm not logged in locally:

nemo ~ $ pkcon install harbour-flashlight
Installing
Waiting in queue
Starting
Refreshing software list
Querying
Resolving dependencies
Installing packages
Installing
Waiting in queue
Waiting for authentication
Waiting in queue
Starting
Refreshing software list
Querying
Resolving dependencies
Installing packages
Downloading packages
Installing packages
nemo ~ $ which harbour-flashlight
/usr/bin/harbour-flashlight

This action has allow_inactive no, so why did it succeed? Also, why is the output from polkit so terrible? Is it meant to be easy to parse or something?

I'm basing my understanding of allow_inactive on the Arch wiki (https://wiki.archlinux.org/index.php/Polkit):
Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. allow_any is the setting encompassing both scenarios.

Maybe it doesn't count as a "remote" session if the same user is logged in locally at the same time?

Anyway, by the same logic, I would expect those polkit settings to deny attempts to install untrusted local packages remotely, and only allow local users to install local packages after authentication.

And yet...I just tried installing by selecting an RPM in filecase it and it succeeded. :s

It seems the wheel group would have permissions to do this:


nemo ~ $ sudo cat /etc/polkit-1/localauthority.conf.d/50-localauthority.conf
# Configuration file for the PolicyKit Local Authority.
#
# DO NOT EDIT THIS FILE, it will be overwritten on update.
#
# See the pklocalauthority(8) man page for more information
# about configuring the Local Authority.
#

[Configuration]
AdminIdentities=unix-group:wheel

...but nemo isn't in it:

nemo ~ $ groups
nemo video users ssu timed oneshot system bluetooth graphics input audio camera mtp

The only other thing I could find is this:
nemo ~ $ sudo cat /etc/polkit-1/nullbackend.conf.d/50-nullbackend.conf
#
# Configuration file for the PolicyKit null backend.
#
# DO NOT EDIT THIS FILE, it will be overwritten on update.
#
# To change configuration, create another file in this directory with
# a filename that is sorted after the 50-nullback.conf and make
# sure it has the .conf extension.
#
# Only a single configuration item, Priority, is supported.
#
# See the PolicyKit documentation for more information about PolicyKit.
#

[Configuration]
Priority=-10

nemo ~ $ rpm -qf /usr/lib/polkit-1/extensions/libnullbackend.so
polkit-0.104-1.1.6.armv7hl

Could this be an extension backend written by Jolla, responsible for allowing authentication by other methods? Or is it part of nemo (which would explain why it's in polkit itself, and not some other Jolla specific package)?

Sorry, that was a slight misunderstanding. I am not trying to pass it off as unimportant. All I am trying to say is that there is an even bigger hole gaping in the system in addition to the one you have pointed out.

What I do not understand is how can anyone try to pass Sailfish off as a secure OS. The only "security" we have ATM is through obscurity. The worst kind there is.

Agreed :) what we have now may be convenient, but it seems like it was thrown together in a rush without much regard for security (would implementing the kind of things juiceme mentioned make the system a pain to use? I don't think it would.)