Revision history [back]
 | 1 | initial version | posted 2018-02-04 15:39:13 +0200  |
[security issue] sshd daemon gets activated
The security concept by minimizing the attack surface should be widely known. While evaluating SFOSX I noticed that the "Settings -> Devel-Tools" allows enabling the SSH access. Enabling and disabling it shows that the SSH daemon is activated and deactivated as expected. But when the device reboots the systemd configuration enables the SSH daemon again. That exposes the service to public access. This stays contrary to the UI configuration (that shows a disabled service). The account is still disabled but thats not the point. As we all known software have bugs, also the SSH daemon!
Solution (Jolla): This bug should be addressed by additionally disabling the systemd unit (sshd) and not just stopping it (this is not persistent between reboots), when using the UI interface (Settings -> Devel-Tools -> RemoteAccess) .
While waiting for such solution; the user should after rebooting the device enabling, (wait some seconds) and disabling the remote-access to be sure that it is disabled (solution without CLI).
| | 2 | retagged |
[security issue] sshd daemon gets activated
The security concept by minimizing the attack surface should be widely known. While evaluating SFOSX I noticed that the "Settings -> Devel-Tools" allows enabling the SSH access. Enabling and disabling it shows that the SSH daemon is activated and deactivated as expected. But when the device reboots the systemd configuration enables the SSH daemon again. That exposes the service to public access. This stays contrary to the UI configuration (that shows a disabled service). The account is still disabled but thats not the point. As we all known software have bugs, also the SSH daemon!
Solution (Jolla): This bug should be addressed by additionally disabling the systemd unit (sshd) and not just stopping it (this is not persistent between reboots), when using the UI interface (Settings -> Devel-Tools -> RemoteAccess) .
While waiting for such solution; the user should after rebooting the device enabling, (wait some seconds) and disabling the remote-access to be sure that it is disabled (solution without CLI).